[Libreoffice-commits] core.git: Branch 'distro/collabora/cp-6.0' - vcl/source

[Ashod Nakashian (via logerrit)]

 vcl/source/control/field.cxx |   25 ++++++++++++++++++++++++-
 1 file changed, 24 insertions(+), 1 deletion(-)

New commits:
commit 42761c688053155ae87628e69eb4d2a28e6c78e6
Author:     Ashod Nakashian <ashod.nakashian at collabora.co.uk>
AuthorDate: Mon Jun 17 23:32:04 2019 -0400
Commit:     Jan Holesovsky <kendy at 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 <jenkinscollaboraoffice at gmail.com>
    Reviewed-by: Jan Holesovsky <kendy at 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;