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

[Aron Budea (via logerrit)]

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

New commits:
commit e029e9e97a4c678cf9f6bf474ddc1df9bef3852d
Author:     Aron Budea <aron.budea at collabora.com>
AuthorDate: Mon Sep 16 12:39:59 2019 +0200
Commit:     Tor Lillqvist <tml at collabora.com>
CommitDate: Wed Jun 10 08:30:46 2020 +0200

    Revert "vcl: better decimal handling in NumericFormatter"
    
    This reverts commit e9a48869fe1f1e90c03d299ae419ea5b1f43de50.
    
    Further comments by tml, for the cherry-pick this branch:
    
    This fixes the problem where even in plain interactive desktop use,
    for instance entering "23" into the font size control on the Font tab
    of Calc's Format>Cells... dialog causes the value "2.3" to be entered.
    
    This also fixes corresponding problems in UI tests, like when
    test_format_cell_font_effects_tab in
    sc/qa/uitest/calc_tests/formatCells.py (part of UITest_calc_tests)
    enters "18" into the font size box. (Sadly the failure of that to work
    properly then caused UITest_calc_tests to hang, instead of producing
    some failure report. At least for me.)
    
    Change-Id: I81269296ab3ca3f071707cf22c4b59964baed863
    Reviewed-on: https://gerrit.libreoffice.org/78980
    Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice at gmail.com>
    Reviewed-by: Aron Budea <aron.budea at collabora.com>
    Reviewed-on: https://gerrit.libreoffice.org/c/core/+/95959
    Reviewed-by: Tor Lillqvist <tml at collabora.com>

diff --git a/vcl/source/control/field.cxx b/vcl/source/control/field.cxx
index 35f298ed9477..ebbd7d41c7bd 100644
--- a/vcl/source/control/field.cxx
+++ b/vcl/source/control/field.cxx
@@ -202,29 +202,6 @@ bool ImplNumericGetValue( const OUString& rStr, sal_Int64& rValue,
         aStr1.append(std::u16string_view(aStr).substr(0, nDecPos));
         aStr2.append(std::u16string_view(aStr).substr(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;
 
@@ -564,7 +541,7 @@ void NumericFormatter::ImplInit()
     mnFieldValue        = 0;
     mnLastValue         = 0;
     mnMin               = 0;
-    mnMax               = 100000000; // A user-friendly round number.
+    mnMax               = SAL_MAX_INT32;
         // a "large" value substantially smaller than SAL_MAX_INT64, to avoid
         // overflow in computations using this "dummy" value
     mnDecimalDigits     = 2;