This reverts
fix endless loop error: 865b5caf6e2256e06f46a39a86d67f03408718a9
which was a partial revert of
AppendAscii cleanup: b7df3446c373a93dc5b77b495a54d873d83a91a7
AND fixes the original error in "AppendAscii cleanup".
Change-Id: Ida29af046b277170388e4945c0cdb4ec6116be98
It defines what goes into the ValueList property, what getCurrentValue() returns, and what an external value binding gets.
Change-Id: I9242d3a6040ec98c22b1d4350942dfa0e7aa6c5b
- nanosecond precision
- signed (allowed negative) year
Also: assorted improvements / bugfixes in date/time handling code.
Some factorisation of copy/pasted code.
Change-Id: I761a1b0b8731c82f19a0c37acbcf43d3c06d6cd6
Modules sal, salhelper, cppu, cppuhelper, codemaker (selectively) and odk
have kept them, in order not to break external API (the automatic using declaration
is LO-internal).
Change-Id: I588fc9e0c45b914f824f91c0376980621d730f09
Moved portions from module i18npool, all of former i18nisolang1 library
that now is i18nlangtag. Included are languagetag, isolang and mslangid.
This i18nlangtag code is now even used by module comphelper, so
disentangling i18npool and making this an own module was needed to not
create circular module dependencies.
Change-Id: Ib887c3d6dde667403fd22d382310ba5f1a9b0015
...since b4f8ab8881785db8e328fbfa84933eadb6bc5dd5 "extensions: get rid of no
longer needed stringdefine.hxx."
Change-Id: I0ab16071267fc08c9a2664be8630f617085fdaad
...which is a confusing overload with unexpectedly different semantics from the
one-parameter form. In preparation of marking it as deprecated.
Change-Id: I4f176995546ae583fc570d770647ffc315eecc75
.. to Reference<XComponentContext>
mostly in the dbaccess module, but it also affected some other
modules.
Change-Id: I09b3f6fe7a9b33498b11d98b5521b5aeeb8882be
Done with a perl regex:
s/OUString\s*\(\s*RTL_CONSTASCII_USTRINGPARAM\s*\((\s*"[^")]*?"\s*)\)\s*\)/OUString\($1\)/gms
Change-Id: Idf28320817cdcbea6d0f7ec06a9bf51bd2c3b3ec
Reviewed-on: https://gerrit.libreoffice.org/2832
Reviewed-by: Thomas Arnhold <thomas@arnhold.org>
Tested-by: Thomas Arnhold <thomas@arnhold.org>
use solenv/bin/add-modulelines script for the task
and remove all UTF bom from *.src and *.hrc files
svx/source/dialog/hdft.src
Change-Id: I745d4f0fe9b05436a142a03f8512970f91c41bd4
Using the autocorrect list of LibreOffice
extras/source/autotext/lang/en-US/acor/DocumentList.xml
Change-Id: I8b93969bc0742c2e95b8b7db3c4c37691e8d3657
Script: http://pastebin.ca/2327716
Consider the following situation:
Property Name Property Order Index
------------- --------------------
propA4 4
propB5 5
propB4 4
And the loop goes over these properties in this order.
propB4 should be before propB5, but with the old code,
propB4 would be pushed after propB5: it asks for position
4, but as positions 4 and 5 are already occupied, it gets
pushed to position 6.
Remaining difficulty: properties from different
property index ordering series will be interleaved.
This should be solved at object model level;
ideally property order index should be unique,
at least within an object.
Change-Id: Ie235a4b22155df97df139f1dc354247845626620
...solved by removing the nPos member and instead calculating the index on the
fly. The difference is that old indices were before calling std::sort in
OPropertyInfoService::getPropertyInfo() while new ones are after, but that
should probably be OK per the documentation of
com.sun.star.inspection.XObjectInspectionModel.getPropertyOrderIndex (which
appears to be the only client of that functionality).
Change-Id: Id346bb219acbdad88ec43cf46feca8c37f2c7cf4
