connectivity/source/commontools/DateConversion.cxx |   16 +++++++++++++++-
 1 file changed, 15 insertions(+), 1 deletion(-)

New commits:
commit 3ddfcd70dccd1d8312d6172014f01862cd5be1ab
Author: Lionel Elie Mamane <lio...@mamane.lu>
Date:   Wed Aug 20 18:33:04 2014 +0200

    make debug builds fail hard on unexpected conditions
    
    Change-Id: I0732ce65757ee29e5ad12cb576c5b64ed0edeaee

diff --git a/connectivity/source/commontools/DateConversion.cxx 
b/connectivity/source/commontools/DateConversion.cxx
index 9798845..0e31e4f 100644
--- a/connectivity/source/commontools/DateConversion.cxx
+++ b/connectivity/source/commontools/DateConversion.cxx
@@ -261,7 +261,19 @@ void DBTypeConversion::setValue(const 
Reference<XColumnUpdate>& xVariant,
                     css::lang::Locale loc;
                     if (xFormatProps->getPropertyValue("Locale") >>= loc)
                         nStandardKey = xFormatTypes->getStandardIndex(loc);
+                    else
+                    {
+                        assert(false);
+                    }
                 }
+                else
+                {
+                    SAL_WARN("connectivity.commontools", "no format by key " 
<< nKeyToUse);
+                }
+            }
+            else
+            {
+                assert(false);
             }
             // Why use nStandardKey rather than nKeyToUse here? I'm not sure, 
but "it was always like that".
             // Previously had hardcoded 0 instead of nStandardKey, which led 
to problems with dates
commit 73ff8a29c1d546bbe2864d714ddb9c35c1d875f4
Author: Lionel Elie Mamane <lio...@mamane.lu>
Date:   Wed Aug 20 18:35:20 2014 +0200

    update comments with my new findings
    
    Change-Id: I58e07994e627ce980573812cbe56a068f66b1862

diff --git a/connectivity/source/commontools/DateConversion.cxx 
b/connectivity/source/commontools/DateConversion.cxx
index cf6fbe1..9798845 100644
--- a/connectivity/source/commontools/DateConversion.cxx
+++ b/connectivity/source/commontools/DateConversion.cxx
@@ -263,10 +263,12 @@ void DBTypeConversion::setValue(const 
Reference<XColumnUpdate>& xVariant,
                         nStandardKey = xFormatTypes->getStandardIndex(loc);
                 }
             }
-            // Why use nStandardKey rather than nKeyToUse here? Don't know, 
but "it was always like that".
+            // Why use nStandardKey rather than nKeyToUse here? I'm not sure, 
but "it was always like that".
             // Previously had hardcoded 0 instead of nStandardKey, which led 
to problems with dates
             // because of differences M/D/Y vs D/M/Y. This at least fixes 
those problems, but possibly
             // nKeyToUse is an even better choice than nStandardKey.
+            // OTOH, using nKeyToUse nullifies the special treatment for 
percent formats,
+            //       leading to "5" (in a percent format) to be understood as 
"500%" instead of "5%".
             sal_Int32 nRealUsedKey = 
xFormatter->detectNumberFormat(nStandardKey, rString);
             if (nRealUsedKey != nKeyToUse)
                 nRealUsedTypeClass = getNumberFormatType(xFormatter, 
nRealUsedKey) & ~NumberFormat::DEFINED;
_______________________________________________
Libreoffice-commits mailing list
libreoffice-comm...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-commits

Reply via email to