Exponent in scientific number may use '?' as blank like in format "0.00E+?0"
This change:
- adds interpreatation of '0' and '?' in exponent
- adds "blank-exponent-digits" attribute to scientific number for import
and export to ODF
- prevents using exponent with only '?'. There must be at least one '0'
in exponent
- adds QA test of such format and test import/export/import to ODF and OOXML
- corrects one basic test
Change-Id: If52edc632a161f842270bb2fd77af535e2b978d4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154986
Tested-by: Jenkins
Reviewed-by: Laurent Balland <laurent.balland@mailo.fr>
...in include files. This is a mix of automatic rewriting in include files and
manual fixups (mostly addressing loplugin:redundantfcast) in source files that
include those.
Change-Id: I1f3cc1e67b9cabd2e9d61a4d9e9a01e587ea35cc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158337
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...which would not work, as calling constexpr SbxVariable::MakeHashCode on those
vars would no longer be constant expressions
Change-Id: Ib848a6405dc270a1a5b9a92084fa2d063ea37892
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/158134
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...now that warning about O[U]String vars that could be O[U]StringLiteral is no
longer useful
Change-Id: I389e72038171f28482049b41f6224257dd11f452
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157992
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...by moving the char8_t -> char reinterpret_cast out of any potential constexpr
paths into a new TranslateId::getId. And demonstrate constexpr'ability by
making the aCategories var in OApplicationIconControl::Fill
(dbaccess/source/ui/app/AppIconControl.cxx) constexpr. (And there might be more
such cases that could now be made constexpr.)
Change-Id: I0b4e3292faf8f6b901f9b9e934e1aa6bf0f583ff
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157862
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Instead of returning ErrCode class everywhere, return a new
class ErrrCodeMsg, which combines an ErrCode with the other
parameters that are used to control the error reporting.
I do not change everything that uses ErrCode here, I started
from SfxBaseController/SfxMedium and worked outwards.
This change serves two purposes
(1) Replace the extremely whacky ErrorInfo mechanism we were
using to smuggle information into the error handler reporting
mechanism with a very straightforward approach of just combining it
into the error class.
(2) Allow us to capture the source location that produced the error,
which makes debugging the source of a problem soooo much easier.
Change-Id: I978b8f00c9851b41a216c7ebdef2ef94251d5519
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/157440
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
This reverts commit 7fc6063914.
sberg noticed that there is a difference now:
there's a subtle difference now, in that if y was null originally, it would have thrown a (caught) exception, whereas now it will crash in the y.query<X>() call.
Change-Id: Idbb5a08d635d15b5ca63f4822eddf05fb0a5afa0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156002
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Adjusted the error message about exceeding legacy module size and
removed the code for saving image version 11. Modules using image
version 11 still can be loaded. Saving modules always result in
an image version higher than image version 11 depending on the
size of the module.
In addition, some minor performance issues (construction of the error
message and the correct list of modules) were fixed.
Change-Id: I3bde9fcc1596b63446193c836fa7b5cb06eb7d97
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149687
Tested-by: Jenkins
Reviewed-by: Andreas Heinisch <andreas.heinisch@yahoo.de>
so presumably we no longer need this suppression since:
commit d969715fa4
Date: Wed Jul 19 22:29:35 2023 +0200
Simplify a bit by removing a redundant condition
line 627 already contains: if( nMaxDigit > nDigitPos )
Change-Id: If6ff93f91f5bd20a9a03ed828d6f4e598ff4f3da
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154804
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
OUStringLiteral should be declared constexpr, to enforce
that it is initialised at compile-time and not runtime.
This seems to make a different at least on Visual Studio
Change-Id: I1698f5fa22ddb480347c2f4d444530c2e0e88d92
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153499
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
improve the check by checking for methods that exclude
using string_view, rather than checking for methods that
__can__ use string_view, which leads to exposing
some holes in our o3tl/string_view.hxx coverage.
Change-Id: Ic9dd60441c671f502692f9cd2a1bb67301c4b960
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150277
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
This properly handles null bytes that are expected
when converting between byte strings and Unicode.
It properly handles TransliterationFlags, which are
not a bitset.
In vbProperCase, it uses the correct method to
lowercase the string, working not only with ASCII.
Change-Id: I04e8cdca66ef9863a6516b15205a2a543ed97680
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/149224
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Building CppunitTest_basic_macros using VS2022 failed for me reproducibly
for some time, with
make[1]: *** [C:/lo/src/core/solenv/gbuild/LinkTarget.mk:841: C:/lo/src/build/workdir/LinkTarget/CppunitTest/test_basic_macros.dll] Error 139
It is caused by linking odbccp32, and legacy_stdio_definitions required
by the latter with current versions of UCRT.
It seems to work OK for others; but being unable to find what's different
on my system, I have this workaround, using run-time loading instead.
Change-Id: Ic4094398f7510bc281dfa96f980f29f12f09d7ba
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147626
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Julien Nabet