sw/source/filter/ascii/parasc.cxx |    6 +++++-
 vcl/source/control/field.cxx      |   25 ++++++++++++++++++++++++-
 2 files changed, 29 insertions(+), 2 deletions(-)

New commits:
commit e9a48869fe1f1e90c03d299ae419ea5b1f43de50
Author:     Ashod Nakashian <ashod.nakash...@collabora.co.uk>
AuthorDate: Mon Jun 17 23:32:04 2019 -0400
Commit:     Andras Timar <andras.ti...@collabora.com>
CommitDate: Tue Sep 3 13:44:22 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>
    (cherry picked from commit 42761c688053155ae87628e69eb4d2a28e6c78e6)
    Reviewed-on: https://gerrit.libreoffice.org/78453
    Reviewed-by: Andras Timar <andras.ti...@collabora.com>
    Tested-by: Andras Timar <andras.ti...@collabora.com>

diff --git a/vcl/source/control/field.cxx b/vcl/source/control/field.cxx
index 59220ac21258..bbbdbceb86e4 100644
--- a/vcl/source/control/field.cxx
+++ b/vcl/source/control/field.cxx
@@ -131,6 +131,29 @@ bool ImplNumericGetValue( const OUString& rStr, sal_Int64& 
rValue,
         aStr1.appendCopy(aStr, 0, nDecPos);
         aStr2.appendCopy(aStr, 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;
 
@@ -470,7 +493,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;
commit 2cd1ac593a3a47f7331d161fd113417c97313a01
Author:     Ashod Nakashian <ashod.nakash...@collabora.co.uk>
AuthorDate: Wed Jul 10 08:31:39 2019 -0400
Commit:     Andras Timar <andras.ti...@collabora.com>
CommitDate: Tue Sep 3 13:44:09 2019 +0200

    sw: fail loading when the fallback text detection fails
    
    When we document in question fails to match any known type,
    we try to open as plain text (and convert to a Writer doc).
    However we should not display non-text when we have failed
    to detect ascii or unicode contents in the file.
    
    This happens with corrupted documents, for example, where
    we end up displaying non-printable binary data.
    
    Change-Id: Iccc158a4cb6051a8b17ba01987a30a9882a27fa9
    Reviewed-on: https://gerrit.libreoffice.org/75512
    Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoff...@gmail.com>
    Reviewed-by: Jan Holesovsky <ke...@collabora.com>
    (cherry picked from commit d1f6f27e2a014aa55e2762f1209dc520fb183404)
    Reviewed-on: https://gerrit.libreoffice.org/78452
    Reviewed-by: Andras Timar <andras.ti...@collabora.com>
    Tested-by: Andras Timar <andras.ti...@collabora.com>

diff --git a/sw/source/filter/ascii/parasc.cxx 
b/sw/source/filter/ascii/parasc.cxx
index ef7faed07197..667778886a98 100644
--- a/sw/source/filter/ascii/parasc.cxx
+++ b/sw/source/filter/ascii/parasc.cxx
@@ -261,7 +261,11 @@ ErrCode SwASCIIParser::ReadChars()
         nOrig = nLen = rInput.ReadBytes(pArr.get(), ASC_BUFFLEN);
         rtl_TextEncoding eCharSet;
         LineEnd eLineEnd;
-        bool bRet = SwIoSystem::IsDetectableText(pArr.get(), nLen, &eCharSet, 
&bSwapUnicode, &eLineEnd);
+        const bool bRet
+            = SwIoSystem::IsDetectableText(pArr.get(), nLen, &eCharSet, 
&bSwapUnicode, &eLineEnd);
+        if (!bRet)
+            return ERRCODE_IO_BROKENPACKAGE;
+
         OSL_ENSURE(bRet, "Autodetect of text import without nag dialog must 
have failed");
         if (bRet && eCharSet != RTL_TEXTENCODING_DONTKNOW)
         {
_______________________________________________
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

Reply via email to