[Libreoffice-commits] core.git: Branch 'libreoffice-5-2' - sw/source
Stephan Bergmann
sbergman at redhat.com
Tue Jan 17 15:53:56 UTC 2017
sw/source/core/unocore/unoobj.cxx | 7 +++++++
1 file changed, 7 insertions(+)
New commits:
commit 35001a92d5e414e93e8e8bbbc3999aeb8d8efcf2
Author: Stephan Bergmann <sbergman at redhat.com>
Date: Tue Jan 17 10:03:49 2017 +0100
tdf#105212: BASIC sets Delimiter prop to integer value
LO's BASIC doesn't have first-class support for the UNO CHAR type, often uses
integer values to represent such CHAR values (cf. <https://wiki.openoffice.org/
wiki/Documentation/DevGuide/ProUNO/Basic/Mapping_of_Simple_Types>).
Since 0b07406f7147b9abbb2095d9e038b13293cb8b10 "Use C++11 char16_t for
sal_Unicode" (for non-Windows, since LO 5.1) resp.
e16fa715c43dcdf836ce8c400b6d54eae87b627d "Handle wchar_t as native C++11 type on
windows" (for Windows, since LO 5.2), C++ css::uno::Any >>=, <<=, etc. with a
sal_Unicode argument no longer silently treat the argument as sal_uInt16
instead. That means that BASIC code putting an integer value into a UNO ANY
that shall hold a value of CHAR type may no longer work. (Arguably, such code
only ever happened to work by coincidence. For example, if the ANY were
processed by Java instead of C++ code, it would never have worked.)
Luckily, the use of CHAR in the UNO API is rare (for a good reason, as a single
UTF-16 code unit is hardly ever the right choice to represent "a character").
The only documented place I could find using a CHAR property is Delimiter in the
css.text.TextSortDescriptor and css.text.TextSortDescriptor2 services. And the
only processing of such a property that I could find across the LO code base is
in the file modified here, which thus just takes a one-off special effort to
take care of this problem.
The direction from C++ to BASIC is left as-is. The value of the Delimiter
property is now reported as a CHAR value (where in the past it was---arguably
erroneously---reported as an UNSIGNED SHORT value), and BASIC is generally
capable of handling such CHAR values it receives well. For example, in the
BASIC code attached to tdf#105212,
> MsgBox("Sort: " + SortDesc(1).Name + " = " + SortDesc(1).Value)
SortDesc(1).Value will now print a (space) character instead of its numeric
value (32). Also, any other uses of individual CHAR values in the UNO API apart
from properties appear to already be handled well enough by BASIC, as the sample
code
> Sub Main
> tk = createunoservice("com.sun.star.awt.Toolkit")
> dev = tk.createScreenCompatibleDevice(100, 100)
> descs = dev.getFontDescriptors()
> msgbox("Font """ + descs(1).Name + """")
> font = dev.getFont(descs(1))
> n = font.getCharWidth(97) ' 'a'
> msgbox("Width 'a' = " + n)
> met = font.getFontMetric()
> msgbox("FirstChar = '" + met.FirstChar + "', LastChar = '" + met.LastChar + "'")
> met.LastChar = 122 ' 'z'
> msgbox("New LastChar = '" + met.LastChar + "'")
>
> trans = createunoservice("com.sun.star.i18n.Transliteration")
> c1 = trans.transliterateChar2Char(97) ' 'a'
> c2 = trans.transliterateChar2Char(c1)
> msgbox("Transliterate, '" + c1 + "' '" + c2 + "'")
> End Sub
demonstrates.
Change-Id: I2aec1ce374c024bfac61f6c832241dfeb561addc
(cherry picked from commit 1b835cdb5ef4cebeae729b1edf2a773f4a582c0f)
Reviewed-on: https://gerrit.libreoffice.org/33213
Tested-by: Jenkins <ci at libreoffice.org>
Reviewed-by: Michael Stahl <mstahl at redhat.com>
diff --git a/sw/source/core/unocore/unoobj.cxx b/sw/source/core/unocore/unoobj.cxx
index 600c393..21561bd 100644
--- a/sw/source/core/unocore/unoobj.cxx
+++ b/sw/source/core/unocore/unoobj.cxx
@@ -2687,10 +2687,17 @@ bool SwUnoCursorHelper::ConvertSortProperties(
else if ( rPropName == "Delimiter" )
{
sal_Unicode uChar;
+ sal_uInt16 nChar;
if (aValue >>= uChar)
{
rSortOpt.cDeli = uChar;
}
+ else if (aValue >>= nChar)
+ {
+ // For compatibility with BASIC, also accept an ANY containing
+ // an UNSIGNED SHORT:
+ rSortOpt.cDeli = nChar;
+ }
else
{
bRet = false;
More information about the Libreoffice-commits
mailing list