In sc/qa/unit/ucalc_formula.cxx, dropping the capture-default from the
lExpectedinF lambda revealed that MSVC in C++17 mode (i.e., when building
without --with-latest-c++) requires ROW_RANGE (a local const int variable from
the enclosing TestFormula::testTdf97369) to be captured, even though all uses of
that variable within the lambda body are constant expressions. That is still
true at least for the latest Visual Studio 2019 version 16.11.1. (This is not
an issue for the lExpectedinH and lExpectedinI lambdas a few lines further down,
as they, in addition to using that ROW_RANGE, also use the local const double
variables SHIFT1 and SHIFT2, whose uses are not constant expressions, so
they are implicitly captured and loplugin:unusedcapturedefault does not suggest
dropping those lambdas' capture-defaults in the first place.)
Change-Id: Iee7efb485187cbe8eba6a2d470afca4993eb1816
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120693
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Otherwise if a tip dialog is left open then its considered not to be
have be shown and new ones will constantly open on every new
document. Especially problematic in impress if you leave the first
one open and select a template to open from the template dialog then
you get two of them in the same frame.
Change-Id: I94cd34aa031e133d8c229a0de78582fda1dbdf4a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120674
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
SvxNumberFormat::nInclUpperLevels (matches text:display-levels in ODF)
bit incorrect in its name: is counts total amount of levels to display,
including current level. So value "0" seems have no sense: display 0
levels in total?
In UI you can't select less than 1 level and ODF standard (19.797)
using 1 as a default. This looks plausable.
Change-Id: I596386c7b3cc4370910cd0ff6e927e501179fbdf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120458
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
This changes its value from 56 to the proper 57.
See 9be17c52b7, which had
changed the previous 5-mm value to the incorrectly rounded
1-mm value; and cefce1a247,
which had unified the other places mentioning i19922.
Change-Id: I7186320b4c1a2a65a6f728ed8bafcbf0eb45c4cb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120441
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
If a LogicToLogic uses fixed units, we can use o3tl::convert
instead. We can also do the same for all other cases where
LogicToLogic is used, but that needs additional investigation to
determine if it is safe to do so.
Note:
MapUnit::Pixel is converted to o3tl::Length::pt because it assumed
72 PPI for a logical pixel, which corresponds with the conversion
rate of a point (72 PPI).
Today, 96 PPI is standard, which is also used for o3tl::Length:px.
Change-Id: I29126df38bfcfda74b5d83d4cb880a378aecd18b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120230
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
The results can now be downloaded as a zip file, which would
consist of the test log and all the resultant bitmap images produced
by the tests compressed as png stored in the user directory folder.
Change-Id: I8a6098a7454a621bbb9cafa7b6f2cafaa5503522
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117937
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
since it is just a wrapper over SvtCJKOptions and SvtCTLOptions.
Later I will replace those two with the equivalent officecfg calls
Change-Id: I61c5667a05f75d42643175f2c28c29d7a590b15c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119516
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
in the process, needed to expose some functionality in ConfigManager
and ConfigItem, to avoid repeating code
Change-Id: Ic0256a010070a79cd649dfd11267bec2f77e5221
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119470
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
... in WhichRangesContainer and SfxItemSet ctors. Now it's not needed
to explicitly use 'value' in WhichRangesContainer's ctor, or create an
instance for use in SfxItemSet ctor (svl::Items is already defined as
a template value of corresponding type).
Instead of
WhichRangesContainer Foo(svl::Items<1, 2>::value);
SfxItemSet Bar(rItemPool, svl::Items<1, 2>{});
now use:
WhichRangesContainer Foo(svl::Items<1, 2>);
SfxItemSet Bar(rItemPool, svl::Items<1, 2>);
Change-Id: I4681d952b6442732025e5a26768098878907a238
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119157
Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Stephan Bergmann