change various ResId classes that use conversion operator to OUString to
functions that return a OUString
drop various defines
drop unnecessary toString calls
Change-Id: Ibeccdf2b91a46a2ed5b4b74e6024e301a023bc92
Reviewed-on: https://gerrit.libreoffice.org/37817
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
Translates all (leftovers) found using a custom regex, in directories not
shown by /bin/find-german-comments and beginning with "a" to "c".
Change-Id: I3b0152ee78ad80a29d714cbd98bf888f31be4763
Reviewed-on: https://gerrit.libreoffice.org/37573
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>
... with proper tools::Date methods Normalize() and AddMonths().
Also prepare functionality to easily switch on rollover for StarBASIC as well,
i.e. when called by DateSerial() runtime function.
For StarBASIC, invalid date for day > daysinmonthofyear is now (or better since
a previous commit 94bb96ada421b423e9ed30526fe5a6aac95f00b9 from today) properly
detected, not just dumb 1<=day<=31.
Change-Id: Ibb44f7247726f1e1168f0e66c5ae18e073d19f08
* Input of two-digit years only possible through CDateFromIso() though to
maintain compatibility with previous behavior and also VBA mode.
* VBA mode restricted to years 1..9999
Change-Id: Ia9574c3bf136619b4831b349d263c96b162d1ed4
Theoretically tools::Date can hold five digits years and even negative,
though Basic internally accepts only 100<=year<=9999. Might be that some
date calculations may result in years out of those margins, so at least
don't truncate those.
Change-Id: I3c217cc42476ce1cf8f9046111a1281288dc5bb6
Previous implementation was over-simplified and accepted all sort of malformed
input to yield some arbitrary date, including longer and shorter and not
strictly numeric strings.
Change-Id: I2158429aeff7431f5ec5a1c9125018a5455a4730
...which had been like that ever since 78d40bcdf3b724954f29da348952153ed53bfa2d
"INTEGRATION: CWS npower10", for no apparent reason.
Change-Id: I4803d20fd81c37b55e10e4ea4ff1c5355b937161
There is lots of (Windows-only) code that relied on sal_Unicode being the same
as wchar_t, and the best change may be different in each case (and doing the
changes may be somewhat error prone). So for now add SAL_U/SAL_W scaffolding
functions to sal/types.h, remove their uses one by one again, and finally drop
those functions again.
Change-Id: I2cc791bd941d089901abb5f6fc2f05fbc49e65ea
Reviewed-on: https://gerrit.libreoffice.org/36077
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
* Allow lowercase argument. (And properly check the sal_Unicode value with
rtl::isAsciiUpperCase instead of with isalpha, which would cause UB for values
outside of unsigned char + EOF).
* Use _wgetdcwd to get a UTF-16 path in the first place (instead of erroneously
converting via createFromAscii and assuming the path only contains 7-bit ASCII
characters).
* At least with a MSVC 2015 Update 3 --enable-dbgutil build, a call like
CurDir("A")
for a non-existent drive A will cause a failure message box
Microsoft Visual C++ Runtime Library
Debug Assertion Failed!
Program: ...\instdir\program\soffice.bin
File: minkernel\crts\ucrt\src\desktopcrt\misc\getcwd.cpp
Line: 225
Expression: ("Invalid Drive", 0)
though, which appears it can't be intercepted---trying with a
_set_thread_local_invalid_parameter_handler around the call to _wgetdcwd
didn't have any effect.
Change-Id: I666f84b0695152c0f2c25de3bae100e58929594a
and related css::util::SearchOptions2
The TransliterationModules enum has it's constants spread over multiple
UNO enum/constant-collections - TransliterationModules and
TransliterationModulesExtra, which means that most code simply uses
sal_Int32.
Wrap them up into a better bundle so that only the lowest layer needs to
deal directly with the UNO constants.
Change-Id: I1edeab79fcc7817a4a97c933ef84ab7015bb849b
Reviewed-on: https://gerrit.libreoffice.org/34582
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
In OOo times, there'd originally been efforts to allow building on Windows with
MinGW. Later, in LO times, this has been shifted to an attempt of cross-
compiling for Windows on Linux. That attempt can be considered abandoned, and
the relevant code rotting.
Due to this heritage, there are now three kinds of MinGW-specific code in LO:
* Code from the original OOo native Windows effort that is no longer relevant
for the LO cross-compilation effort, but has never been removed properly.
* Code from the original OOo native Windows effort that is re-purposed for the
LO cross-compilation effort.
* Code that has been added specifially for the LO cross-compilation effort.
All three kinds of code are removed.
(An unrelated, remaining use of MinGW is for --enable-build-unowinreg, utilizing
--with-mingw-cross-compiler, MINGWCXX, and MINGWSTRIP.)
Change-Id: I49daad8669b4cbe49fa923050c4a4a6ff7dda568
Reviewed-on: https://gerrit.libreoffice.org/34127
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
This reverts commit fce604c8ae11b462113305aba080d77f8193cfea,
and fixes
tdf#105735 - xray ThisComponent no longer works
in the process.
It turns out Basic doesn't support sal_uInt64 very well, so lets rather
have a small possibility of bad timestamps instead of broken scripts.
Change-Id: Ic00485bd517a4fc61e05632001c9a5f92e05ddd6
Reviewed-on: https://gerrit.libreoffice.org/33972
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
so we can remove unnecessary calls to the OUString(literal) constructor
when calling constructors like this:
Foo(OUString("xxx"), 1)
Change-Id: I1de60ef561437c86b27dc9cb095a5deb2e103b36
Reviewed-on: https://gerrit.libreoffice.org/33698
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...(for now, from LIBO_INTERNAL_CODE only). See the mail thread starting at
<https://lists.freedesktop.org/archives/libreoffice/2017-January/076665.html>
"Dynamic Exception Specifications" for details.
Most changes have been done automatically by the rewriting loplugin:dynexcspec
(after enabling the rewriting mode, to be committed shortly). The way it only
removes exception specs from declarations if it also sees a definition, it
identified some dead declarations-w/o-definitions (that have been removed
manually) and some cases where a definition appeared in multiple include files
(which have also been cleaned up manually). There's also been cases of macro
paramters (that were used to abstract over exception specs) that have become
unused now (and been removed).
Furthermore, some code needed to be cleaned up manually
(avmedia/source/quicktime/ and connectivity/source/drivers/kab/), as I had no
configurations available that would actually build that code. Missing @throws
documentation has not been applied in such manual clean-up.
Change-Id: I3408691256c9b0c12bc5332de976743626e13960
Reviewed-on: https://gerrit.libreoffice.org/33574
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
instead of 32-bit value.
looks like this has been incorrect since
commit 9f2104e1f3a1ef8a37406b39188234df309241bc
Author: Jens-Heiner Rechtien <hr@openoffice.org>
Date: Mon Jun 19 16:46:13 2006 +0000
INTEGRATION: CWS warnings01 (1.23.26); FILE MERGED
but nobody cared, since the values would previously fit into a 32-bit
number.
Change-Id: I4c121085977b5e7ff3e33c8ad57749b925ad31b9
Reviewed-on: https://gerrit.libreoffice.org/32879
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
