... otherwise it assumes that only part of first string to the right of the
unchanged string part needs redrawing (which would be to the right of the
control itself)
Change-Id: I2833c1eb2026041b11d0b72431b164d2ee3befef
Reviewed-on: https://gerrit.libreoffice.org/84207
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
...with a boost::optional fallback for Xcode < 10 (as std::optional is only
available starting with Xcode 10 according to
<https://en.cppreference.com/w/cpp/compiler_support>, and our baseline for iOS
and macOS is still Xcode 9.3 according to README.md). And mechanically rewrite
all code to use o3tl::optional instead of boost::optional.
One immediate benefit is that disabling -Wmaybe-uninitialized for GCC as per
fed7c3deb3 "Slience bogus
-Werror=maybe-uninitialized" should no longer be necessary (and whose check
happened to no longer trigger for GCC 10 trunk, even though that compiler would
still emit bogus -Wmaybe-uninitialized for uses of boost::optional under
--enable-optimized, which made me ponder whether this switch from
boost::optional to std::optional would be a useful thing to do; I keep that
configure.ac check for now, though, and will only remove it in a follow up
commit).
Another longer-term benefit is that the code is now already in good shape for an
eventual switch to std::optional (a switch we would have done anyway once we no
longer need to support Xcode < 10).
Only desktop/qa/desktop_lib/test_desktop_lib.cxx heavily uses
boost::property_tree::ptree::get_child_optional returning boost::optional, so
let it keep using boost::optional for now.
After a number of preceding commits have paved the way for this change, this
commit is completely mechanical, done with
> git ls-files -z | grep -vz -e '^bin/find-unneeded-includes$' -e '^configure.ac$' -e '^desktop/qa/desktop_lib/test_desktop_lib.cxx$' -e '^dictionaries$' -e '^external/' -e '^helpcontent2$' -e '^include/IwyuFilter_include.yaml$' -e '^sc/IwyuFilter_sc.yaml$' -e '^solenv/gdb/boost/optional.py$' -e '^solenv/vs/LibreOffice.natvis$' -e '^translations$' -e '\.svg$' | xargs -0 sed -i -E -e 's|\<boost(/optional)?/optional\.hpp\>|o3tl/optional.hxx|g' -e 's/\<boost(\s*)::(\s*)(make_)?optional\>/o3tl\1::\2\3optional/g' -e 's/\<boost(\s*)::(\s*)none\>/o3tl\1::\2nullopt/g'
(before committing include/o3tl/optional.hxx, and relying on some GNU features).
It excludes some files where mention of boost::optional et al should apparently
not be changed (and the sub-repo directory stubs). It turned out that all uses
of boost::none across the code base were in combination with boost::optional, so
had all to be rewritten as o3tl::nullopt.
Change-Id: Ibfd9f4b3d5a8aee6e6eed310b988c4e5ffd8b11b
Reviewed-on: https://gerrit.libreoffice.org/84128
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...in preparation for wholesale replacement of boost::optional with
o3tl::optional (which will be a using declaration for either std::optional or
boost::optional, hence can't be forward-declared easily)
Change-Id: I031ed1812a0c939f37253f7753e358f1ad9153a3
Reviewed-on: https://gerrit.libreoffice.org/84126
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...to only use functions that are also available for std::optional (in
preparation for changing from boost::optional to std::optional):
* uses of get are replaced with operator * or operator ->
* uses of is_initialized are replaced with operator bool
* uses of reset with an argument are replace with operator =
(All of the replacements are also available for boost::optional "since forever",
so this change should not break builds against old --with-system-boost. An
alternative replacement for is_initialized would have been has_value, but that
is only available since Boost 1.68.)
Change-Id: I532687b6a5ee37dab28befb8e0eb05c22cbecf0f
Reviewed-on: https://gerrit.libreoffice.org/84124
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Using EditView::SelectCurrentWord in arbitrary selection positions
is not a correct approach. When cursor is after "_" in "=_+FUNC",
the method will select "=_+", i.e. the substring that cannot start
any Calc identifier (and actually ending *after* current cursor).
When matching identifiers like "bb.bbb" in "=bb.bb", the end result
will be "=bb.bb.bbb", etc.
So instead of trying to match words and hack around problems, let's
simply find longest match in the string starting from beginning of
the line, and ending at current cursor position. Testing trailing
parts of that string of decreasing length, the first found match is
the longest, which is what we need. This also avoids multiple calls
to expensive EditEngine methods.
Change-Id: Ia3470cc85a4ba9f9ab34cbe9db3250bf28e93350
Reviewed-on: https://gerrit.libreoffice.org/84087
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Found while looking for problems in another patch.
This will become more important with "jumbo sheets" when using the wrong
datatype can mean overflow
Change-Id: I7370ffd8a6edc33a5e613242735e4c7b9eaf830d
Reviewed-on: https://gerrit.libreoffice.org/83991
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
since they are serving the same purpose.
In the process getting rid of a duplicate ScDocument*
that was sometimes set and sometimes not, causing trouble
for me in another patch
Change-Id: I2ceeb6d6e34b62616065bf4840a87bd87d2c3844
Reviewed-on: https://gerrit.libreoffice.org/83990
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
unused since 1c2405ba44 "tdf#89387 General functor
and basic operations"
(found by upcoming loplugin:unusedmember, which identified each of the two
explicit specializations' sole member as unused)
Change-Id: I275137cc70cbe4e58a728779e7e7593c5e11224b
Reviewed-on: https://gerrit.libreoffice.org/83836
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
ooo53770-1.odt contains an invalid attribute
style:style:use-optimal-row-height, which was round-tripped as an
unknown attribute, triggering the assert in CheckValidName().
This reveals a confusing mess of SvXMLNamespaceMap::GetKeyByAttrName
functions.
The bCache flag for one of them was accidentally inverted in commit
78f0d15893 "loplugin:constantparam in xmloff/"
There are basically 2 use cases for this:
* XML element and attribute names, which are XML QName and contain at
most 1 ':'
* XML attribute values, which are namespace-prefixed and may contain
any number of ':' in the "local" part of the value
Because caching is explicitly disabled for Calc formulas, just resolve
the inconsistent bCache by always caching element and attribute names,
and never caching attribute values, so we need just 1 flag.
Change-Id: I363ea2229d0bf5c7199d61b0fee0d9f168911bfa
Reviewed-on: https://gerrit.libreoffice.org/83619
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
Added a lok callback for sending the list of functions matching the
current characters typed by the user.
Change-Id: Ia971fc55ec5eb961b4098592a8049dd0eed3ba14
Reviewed-on: https://gerrit.libreoffice.org/83750
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
...that trigger -Werror,-Wdeprecated-copy ("definition of implicit copy
{constructor, assignment operator} for ... is deprecated beause it has a
user-declared copy {assignment operator, constructor}") new in recent Clang 10
trunk (and which apparently warns about more cases then its GCC counterpart, for
which we already adapted the code in the past, see e.g. the various
"-Werror=deprecated-copy (GCC trunk towards GCC 9)" commits)
Change-Id: Ie37bd820e6c0c05c74e1a862bb1d4ead5fb7cc9c
Reviewed-on: https://gerrit.libreoffice.org/83698
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
XLS stores default column width as 16-bit unsigned integer in the range
from 0 to 255 inclusive ([MS-XLS] 2.4.89 DefColWidth), unlike in OOXML
where any floating-point value is valid. Additionally, some correction
is used, introduced in commit 555d702903
(basis of empirical formula in XclTools::GetXclDefColWidthCorrection
is unclear). So in XLS, when the default is calculated, we need to take
into account if the resulting stored value will actually represent our
calculated value. If not, then just ignore the calculated value, and
use arbitrary 8 as the default.
With that, following IsDefWidth will correctly check if passed width
is represented by the stored default or not. All widths that can't be
represented as integral count chars in DefColWidth will have fUserSet
set in corresponding ColInfo records, thus correctly keeping widths.
Change-Id: Iedcc5583c861f5b18a422a9b279c48cff729cbc5
Reviewed-on: https://gerrit.libreoffice.org/83613
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
which are part of a xlsx-shared-formula along a *row*.
If we do, any reference-updates on these cells while editing
will mess things up.
For example a shared formula "=A30+1" used for a few cells in
the first row (say, A1, B1, C1 and D1) and on deleting a row,
say row#5, the reference update operation will decrement the
row index of all tokens in A1, B1, C1 and D1. But if they
share tokens, they all end up pointing to row#26 instead of
row#29 as each cell is updated which amounts to decrementing
4 times instead of once.
However shared formulas along columns are not affected by this
bug, when tokens are shared since we use formula-groups which
only keeps one copy of token array for the entire group and
reference-update code is designed to correctly work with
formula-groups.
Change-Id: Ic0fe84d12fef18fbf21658664e2b2b86409bca27
Reviewed-on: https://gerrit.libreoffice.org/83361
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
Reviewed-by: Eike Rathke <erack@redhat.com>
...following up on 314f15bff0 "Extend
loplugin:external to warn about enums".
Cases where free functions were moved into an unnamed namespace along with a
class, to not break ADL, are in:
filter/source/svg/svgexport.cxx
sc/source/filter/excel/xelink.cxx
sc/source/filter/excel/xilink.cxx
svx/source/sdr/contact/viewobjectcontactofunocontrol.cxx
All other free functions mentioning moved classes appear to be harmless and not
give rise to (silent, even) ADL breakage. (One remaining TODO in
compilerplugins/clang/external.cxx is that derived classes are not covered by
computeAffectedTypes, even though they could also be affected by ADL-breakage---
but don't seem to be in any acutal case across the code base.)
For friend declarations using elaborate type specifiers, like
class C1 {};
class C2 { friend class C1; };
* If C2 (but not C1) is moved into an unnamed namespace, the friend declaration
must be changed to not use an elaborate type specifier (i.e., "friend C1;"; see
C++17 [namespace.memdef]/3: "If the name in a friend declaration is neither
qualified nor a template-id and the declaration is a function or an
elaborated-type-specifier, the lookup to determine whether the entity has been
previously declared shall not consider any scopes outside the innermost
enclosing namespace.")
* If C1 (but not C2) is moved into an unnamed namespace, the friend declaration
must be changed too, see <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71882>
"elaborated-type-specifier friend not looked up in unnamed namespace".
Apart from that, to keep changes simple and mostly mechanical (which should help
avoid regressions), out-of-line definitions of class members have been left in
the enclosing (named) namespace. But explicit specializations of class
templates had to be moved into the unnamed namespace to appease
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92598> "explicit specialization of
template from unnamed namespace using unqualified-id in enclosing namespace".
Also, accompanying declarations (of e.g. typedefs or static variables) that
could arguably be moved into the unnamed namespace too have been left alone.
And in some cases, mention of affected types in blacklists in other loplugins
needed to be adapted.
And sc/qa/unit/mark_test.cxx uses a hack of including other .cxx, one of which
is sc/source/core/data/segmenttree.cxx where e.g. ScFlatUInt16SegmentsImpl is
not moved into an unnamed namespace (because it is declared in
sc/inc/segmenttree.hxx), but its base ScFlatSegmentsImpl is. GCC warns about
such combinations with enabled-by-default -Wsubobject-linkage, but "The compiler
doesn’t give this warning for types defined in the main .C file, as those are
unlikely to have multiple definitions."
(<https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Warning-Options.html>) The
warned-about classes also don't have multiple definitions in the given test, so
disable the warning when including the .cxx.
Change-Id: Ib694094c0d8168be68f8fe90dfd0acbb66a3f1e4
Reviewed-on: https://gerrit.libreoffice.org/83239
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
In Calc when a cell is copied and its value is filled/pasted to different
cell(s) by using the "Enter" key when focus is on selected cells --
replace warning is not shown even if the selected cells have values of
their own inside it. The old data is simply lost. Provide a replace
warning dialog box whenever such a case is encountered.
Change-Id: I13acb424bc449e096512b5a0864ebc47a407f234
Reviewed-on: https://gerrit.libreoffice.org/83333
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
by creating a copy of ScQueryCellIterator that is specialised for this
use-case.
Takes the opening time from 50s to 8s on my machine.
Change-Id: I193a7c181a5dfed6fecf75e871729d73625d0df6
Reviewed-on: https://gerrit.libreoffice.org/83299
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
calc seems to excessively capture the mouse and grabs + floats are messy across
the different ports. But We usually have the mouse captured before calling the
menu, except if we are editing a cell, an additional capture here will ensure
the grab status is the same in both modes and that events go to the same place
in either case.
Change-Id: I213560273be1a6a398d6a1787a53d64501c473f0
Reviewed-on: https://gerrit.libreoffice.org/83130
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
Type text into the data validity dropdown cell and click elsewhere.
The warning dialog cannot be interacted with due to the active mouse
grab to its parent
Change-Id: I51702c828dee6ec88106f7d44d7e3440f2e61298
Reviewed-on: https://gerrit.libreoffice.org/83128
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
This allows creating, updating and removing infobars from macros/extensions.
It also extends the infobar with a primary and a secondary text, so there can
be a bold summary at the beginning at the infobar with a longer text following
in normal letters.
Macro sample:
------------------------------------------------------------
Sub AddInfobar
dim buttons(1) as new com.sun.star.beans.StringPair
buttons(0).first = "Close doc"
buttons(0).second = ".uno:CloseDoc"
buttons(1).first = "Paste into doc"
buttons(1).second = ".uno:Paste"
ThisComponent.getCurrentController().appendInfobar("my", "Hello world", "Things happened. What now?", com.sun.star.frame.InfobarType.INFO, buttons, true)
End Sub
Sub UpdateInfobar
ThisComponent.getCurrentController().updateInfobar("my", "WARNING","Do not read this message.", com.sun.star.frame.InfobarType.WARNING)
End Sub
Sub RemoveInfobar
ThisComponent.getCurrentController().removeInfobar("my")
End Sub
------------------------------------------------------------
Change-Id: I5d0a223525845d23ffab17acdaa431e0eb783fec
Reviewed-on: https://gerrit.libreoffice.org/29816
Reviewed-by: Serge Krot (CIB) <Serge.Krot@cib.de>
Tested-by: Serge Krot (CIB) <Serge.Krot@cib.de>
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
ctor of SvXMLExport expects a util::MeasureUnit, but getMetric() from
XGlobalSheetSettings returns a FieldUnit. The conversion was missing.
So FieldUnit::MM (=1) was treated as MeasureUnit::MM_10TH (=1). But
that one has no unit string, so the 'translate' transformation got
numbers without unit, which then were wrongly interpreted.
Change-Id: I433c7534be21655887863005f14836d2b733cf1f
Reviewed-on: https://gerrit.libreoffice.org/83004
Tested-by: Jenkins
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
