[Libreoffice-commits] core.git: 2 commits - connectivity/source
Lionel Elie Mamane
lionel at mamane.lu
Wed Aug 20 09:36:22 PDT 2014
connectivity/source/commontools/DateConversion.cxx | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
New commits:
commit 3ddfcd70dccd1d8312d6172014f01862cd5be1ab
Author: Lionel Elie Mamane <lionel at 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 <lionel at 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;
More information about the Libreoffice-commits
mailing list