When not using scripting, there were a number of
unresolved symbols. First aproach did not work, so this
commit is the more extensive.
Change-Id: Iaf78bde10d9a43862d58d1aa8f46b14aa075eddb
(An alternative fix could be to suppress warnings for catch blocks containing
preprocessor conditionals, but as these two places seem to be the only ones
affected, keep it simple for now.)
Change-Id: Ia83e56d1eab69bb2920ffdbbfc2182addce47963
Reviewed-on: https://gerrit.libreoffice.org/47331
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
This way, it is possible to have all the strings translated in dialogs even
when different users use different languages. [It was already possible
to have different languages previously, but not everything in the dialog has
switched - like the buttons at the bottom of the dialogs etc.]
Change-Id: I29a5ae6d31a370eec60397884200b684ec1bf5b9
Reviewed-on: https://gerrit.libreoffice.org/46417
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
Tested-by: Michael Meeks <michael.meeks@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/46979
Tested-by: Jenkins <ci@libreoffice.org>
... with cppu::BaseMutex, because a member cannot ensure the life
cycle guarantees expected by WeakComponentImplHelper.
Change-Id: Iaa10c699abf69882d917487740db241ba1455e1c
Which effectively is what GetObject() internally also does to
determine whether to set an error, so resetting an error here is
moot (or might even hide a nested error?).
Change-Id: I8736d16e386d1833126965538f96aaa1fd73dfd6
Regression from
commit 7ca950ec744b7af1d15724ec2abc296573a641e4
Date: Wed Aug 23 19:25:02 2017 +0200
no need to use ERRCODE_RES_MASK here
the relevant usage sites already call GetRest() before comparing
which exactly is the reason that it didn't work anymore.
Old StringArray ItemList resources stored only 16-bit values,
hence ERRCODE_RES_MASK was used to mask the ErrCode values in the
resource for which code had to mask ERRCODE_RES_MASK as well to
compare values. Now the full ErrCode is stored, so code must not
use GetRest() on a value to compare against, or use GetRest() on
both values (which theoretically could lead to ambiguities, but
probably doesn't in resources that are restricted to one module).
Change-Id: I835e47424bb008bc680dc4f8c502c9558397db36
This likely never worked as there is no SbiInstance in that step,
but worked by chance when running a module's code that was
compiled with VBA support where the VBA-only function was added as
a symbol to be resolved later during runtime and then the
SbiInstance exists and the symbol was magically resolved.
Found when trying to correct vba_tests to actually fail if all
subtests fail that then started to fail in Atn.vb because of the
Round() function being VBA-only.
Change-Id: I7d9f6e2640a73388a2a58c3d180820c6ef85abe3
Reviewed-on: https://gerrit.libreoffice.org/45425
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins <ci@libreoffice.org>
When building without scripting a couple of
functions were undeclared, to solve that
source/runtime/runtime
source/classes/sbintern
were moved so they also compile in building
without scripting
Change-Id: I908fee3caf8376d70ed286c17085d6b8a700ae75
... in case we have a runtime instance already. Only used for
scanning date literals in source so not frequently used, otherwise
we could remember a non-runtime instance formatter somewhere.
Change-Id: I1146860c4b0aa4091708c22e498a6f720d6c7a13
Reviewed-on: https://gerrit.libreoffice.org/45232
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>
In preparation to get rid of the per call locally created
SvNumberFormatter instances..
Change-Id: Ic7db3bbb655aa18e939f5722964655a20f2eadf2
Reviewed-on: https://gerrit.libreoffice.org/45227
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>
Due to the locale dependent date format used here in strings that
neither matches en-US nor en-GB (in which the tests seem to be
executed) all tests failed, and then with passCount==0 the check
was
If failCount <> 0 And passCount > 0 Then
instead of
If failCount <> 0 Or passCount = 0 Then
so the end result was OK.
Also fixed the one case that was commented with
Rem why this fails in excel?
It actually also failed for us, just that because all tests failed
(see above) it never seemed to fail..
Problem seems to be the accuracy of the underlying date+time
double for this specific calculation. Good to know it happens in
Excel as well ;-)
As a workaround, conversion to string does the necessary rounding
internally.
Change-Id: If0302b2feab9e1233d66da4eccff732f61542a69
Reviewed-on: https://gerrit.libreoffice.org/45196
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Jenkins <ci@libreoffice.org>
