There is annoying overloading between Window::Notify and
SfxListener::Notify, and the Window one has apparently fewer
implementations, so rename that and remove lots of disambiguating
"using Notify" in multiply inheriting classes.
Change-Id: I8b597fd9e70cf2e7103b9dfa7cc666e79e7aff49
For instance, column / row label tokens don't work correctly in
grouped cells with the current implementation.
Change-Id: Idf86312ef15fbfd4382aa90ee6d131c671a80683
I left a prefix on the names "Map" so that I would not have to re-arrange
each name too much, since I can't start identifiers with digits like "100thMM"
And remove RSC_EXTRAMAPUNIT, which doesn't seem to be doing anything anymore.
Change-Id: I5187824aa87e30caf5357b51b5384b5ab919d224
Reviewed-on: https://gerrit.libreoffice.org/29096
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
...which was introduced with 3ead3ad52f9bb2f9d1d6cf8dfc73a0a25e6778ed "Gradually
typed Link" to distinguish the new, typed versions from the old, untyped ones,
but is no longer necessary since 382eb1a23c390154619c385414bdbe6f6e461173
"remove untyped Link<>" removed the old versions.
Change-Id: I494025df486a16a45861fcd8192dfe0275b1103c
The issue of 362d4f0cd4e50111edfae9d30c90602c37ed65a2 "Explicitly mark
overriding destructors as 'virtual'" appears to no longer be a problem with
MSVC 2013.
(The little change in the rewriting code of compilerplugins/clang/override.cxx
was necessary to prevent an endless loop when adding "override" to
OOO_DLLPUBLIC_CHARTTOOLS virtual ~CloseableLifeTimeManager();
in chart2/source/inc/LifeTime.hxx, getting stuck in the leading
OOO_DLLPUBLIC_CHARTTOOLS macro. Can't remember what that
isAtEndOfImmediateMacroExpansion thing was originally necessary for, anyway.)
Change-Id: I534c634504d7216b9bb632c2775c04eaf27e927e
This silences the SAL_WARN_IF like
warn:formula.core:6944:1:formula/source/core/api/FormulaCompiler.cxx:625:
OpCodeMap::putOpCode: reusing OpCode 161,
replacing '_xlfn.ORG.OPENOFFICE.ERRORTYPE' with 'ERRORTYPE'
in English map 0x1018000
that occurred during the first load of OOXML .xlsx documents since the
old bad entries were added with commit
89c4a69103b6e15e7f52401c51110b926c3ccf36
In fact the direction opcode -> string was replaced, which it should had
not. That specific mapping is only used though when loading msoxl
namespace formulas from ODF.
Also, the replacement of parameter separator and array column and row
separator worked merely by chance, depending on in which order the
entries where inserted to the hash map. Fixed along as it popped up with
the new handling.
Change-Id: I88017a8b38ccc30874c3dca7d78f0fa47a77a36f
... to clarify that these belong to PDURATION (currently DURATION in UI)
instead of DURATION (currently DURATION_ADD in UI). The confusing UI name
situation will be resolved separately.
Change-Id: I09a7bc8437be1c4c9e72f94e61c877111fb48806
RID_STRLIST_FUNCTION_NAMES_ENGLISH grew to a conglomerate of English UI names,
names used in PODF (ODF 1.0/1.1) and XFunctionAccess API names. Copy it to
independent resources so we can start to correct names in English UI, keep PODF
oddnesses and cater for API compatibility needs.
Change-Id: I7c2053d7627c4da220d8fc991158e8e7a81f0b37
The invalid expression ISOWEEKNUM(A1,0+) lead to a replacement with
ISOWEEKNUM(A1+) which of course is also wrong but loses the original
context. Just exchange the call and convert to WEEKNUM_OOO(A1,0+)
without fiddling with the parameters.
Change-Id: Id1c42d3ba084382e09c164b6c35db996f2b0197a
For other arguments convert to WEEKNUM_OOO, which now can be saved as
ORG.LIBREOFFICE.WEEKNUM_OOO.
Change-Id: I63fd3df1ec4ccaa535a1437200854d8734544a2c
MULTIRANGE, GOALSEEK, EASTERSUNDAY, CURRENT and STYLE are LibreOffice /
OpenOffice.org only and need a _xlfn.ORG.OPENOFFICE. prefix and namespace when
saved to OOXML.
Change-Id: Ie5d4eb14b1ec958f9ebec5f149d0d1d7b4dd644e
Was wrongly saved as ERRORTYPE without _xlfn. prefix and namespace.
Be able to still read ERRORTYPE.
Change-Id: Ia028fe06d930f60b4260adf589ee3190b90ea099
... as we can't rename RID_STRLIST_FUNCTION_NAMES_ENGLISH names.
Should we need yet another resource block to differentiate between
PODF/API names and actual always available English names? Ugly but
maybe. A much better approach would be if Text[en-US] would be always
available, additionally to the current localized resource.
Change-Id: If8eaf18643f4e24c811149c52efff1097a3c1596
