vcl/source/control/field.cxx | 25 ++++++++++++++++++++++++-
1 file changed, 24 insertions(+), 1 deletion(-)
New commits:
commit 42761c688053155ae87628e69eb4d2a28e6c78e6
Author: Ashod Nakashian <ashod.nakash...@collabora.co.uk>
AuthorDate: Mon Jun 17 23:32:04 2019 -0400
Commit: Jan Holesovsky <ke...@collabora.com>
CommitDate: Mon Jul 15 11:55:30 2019 +0200
vcl: better decimal handling in NumericFormatter
When the user deletes the decimal point from
MetricBox, it ends up with the number
with the fractional portion (to the right of
the decimal point) appended to it, which is
(with two decimal points) a 100x larger value.
This makes such editing smarter. In the case
that we detect that the user deleted the
decimal point (which we know should've been
there, because we have a configured fixed
number of decimal points,) we restore it.
This makes it more intuitive, since when
the user enters digits, they get the correct
and expected result, but when they delete the
decimal point, they almost always didn't mean
to grow the number 100x. If that was the goal,
they could enter two extra digits before
the decimal point.
In addition, we set the default maximum to
a more user-friendly value of a million,
instead of int-max, which seems like a
random number to the uninitiated.
Change-Id: Ib535f06e4f111d20f35c4209ad65969dca5928e8
Reviewed-on: https://gerrit.libreoffice.org/75511
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoff...@gmail.com>
Reviewed-by: Jan Holesovsky <ke...@collabora.com>
diff --git a/vcl/source/control/field.cxx b/vcl/source/control/field.cxx
index c1dbb33417c4..8740c9749922 100644
--- a/vcl/source/control/field.cxx
+++ b/vcl/source/control/field.cxx
@@ -130,6 +130,29 @@ bool ImplNumericGetValue( const OUString& rStr, sal_Int64&
rValue,
aStr1.append(aStr.getStr(), nDecPos);
aStr2.append(aStr.getStr()+nDecPos+1);
}
+ else if (nDecDigits > 0 && aStr.getLength() > nDecDigits)
+ {
+ // We expect a decimal point and a certain number of decimal digits,
+ // but seems the user has deleted the decimal point, so we restore it.
+ // Otherwise, they end up with unexpectedly (to them) large numbers.
+
+ // Find the first digit from the right.
+ sal_Int32 nVirtualDecPos = aStr.getLength();
+ while (--nVirtualDecPos > 0)
+ {
+ if ((aStr[nVirtualDecPos] >= '0') && (aStr[nVirtualDecPos] <= '9'))
+ break;
+ }
+
+ if (nVirtualDecPos >= nDecDigits)
+ {
+ nVirtualDecPos -= nDecDigits - 1; // nVirtualDecPos is already on
a digit (so discount it).
+ aStr1.append(aStr.getStr(), nVirtualDecPos);
+ aStr2.append(aStr.getStr() + nVirtualDecPos);
+ }
+ else
+ aStr1 = aStr;
+ }
else
aStr1 = aStr;
@@ -489,7 +512,7 @@ void NumericFormatter::ImplInit()
mnFieldValue = 0;
mnLastValue = 0;
mnMin = 0;
- mnMax = SAL_MAX_INT32;
+ mnMax = 100000000; // A user-friendly round number.
// a "large" value substantially smaller than SAL_MAX_INT64, to avoid
// overflow in computations using this "dummy" value
mnDecimalDigits = 2;
_______________________________________________
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-commits
