Notes
(*) In SC, BULK_DATACHANGED was or'ed into the hint id. Replaced with a
dynamic_cast check.
(*) In SC, removed the hint id field from ScIndexHint, no point in
storing the hint id twice
(*) Fold the SfxStyleSheetHintId enum into the new SfxHintId enum, no
point in storing two different hint ids
(*) In some cases, multiple #define's used to map to the same SFX_HINT
value (notably the SFX_HINT_USER* values). I made all of those separate
values.
Change-Id: I990e2fb587335ebc51c9005588c6a44f768d9de5
Reviewed-on: https://gerrit.libreoffice.org/31751
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
...it internally calls Scheduler::Start, which asserts now since
c00d8271ba443c4f0acf657c226eea4824597f95 "vcl: assert solar mutex is held for
various timer / scheduler ops." Caused the assert to fire when removing an
extension via "Tools - Extension Manager... - Remove".
Change-Id: Ied0591b799af333b3a4c11af07f5f8f1657304d6
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
Move the "Enable"/"Disable" button which was customly
implemented from the ExtBoxWithBtns_Impl to the new row.
This should also solve some accessibility issues.
Also remove some unnecessary code pieces for clean-up.
Change-Id: Iec7820779110eea3411a774de8277ef238f562e7
Reviewed-on: https://gerrit.libreoffice.org/30973
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
Move the "Remove" button which was customly implemented
from the ExtBoxWithBtns_Impl to the new row. This should
also solve some accessibility issues.
Also wipe some useless code which implements custom
tab behavior.
Change-Id: I602fcf23631498145d8b9ead2936ee549caf3f0d
Reviewed-on: https://gerrit.libreoffice.org/30867
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
Moved the "Check for Updates", and "Add" buttons
to the new row, and started moving the buttons
from the ExtBoxWithBtns_Impl to the new row.
Needed to create new public methods to be able
to update button states of ExtMgrDialog from
within the ExtBoxWithBtns_Impl class.
Change-Id: Iea784d0b7237da3f8aa05862dbf1faf5acf98655
Reviewed-on: https://gerrit.libreoffice.org/30560
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
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
... except in include/rtl, include/sal, include/uno, where sal_Size is
retained for compatibility, and where callers of rtl functions pass in
pointers that are incompatible on MSVC.
Change-Id: I8344453780689f5120ba0870e44965b6d292450c
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 was changed by
commit a6efec83cee0ab447f9e6a5716aee5d2165f95c7
Date: Mon Nov 28 10:54:55 2011 -0200
Fix for bug fdo39748, Easy-hack Cleanup extension list.
so restore addPackageToList to not remove the old one before potentially
re-adding it, and instead follow the same model as
TheExtensionManager::modified to refresh the list
Change-Id: I8c3207760361dbd42e400fa9f323ca42971bbcc0
Reviewed-on: https://gerrit.libreoffice.org/28137
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
since...
commit ba81e5c6bd420b41a84ade6ccd774011a8089f7f
Date: Thu May 28 21:35:43 2015 +0100
tdf#91702 - fix stack-based MessBox allocation.
There is no special ScopedVclPtr<X>::Create or
ScopedVclPtrInstance<X>::Create just
VclPtr<X>::Create and a raw VclPtr<X>::Create()->foo
doesn't call dispose on the owned X
Change-Id: Ifacc8d5e742820701307c3c37b9b86487667d84f
move it to when the dialog is closed rather than trying to
launch it as soon as any modifications take place because
those are happening during threaded code and the restart
is always cancelled by the dialog itself leading to repeated
restart dialogs
Now at least it doesn't crash, but if we open an oxt on the command
line, a restart will reopen it, which is probably not what we want.
Maybe this restart on an extension modification is a bad idea in
the first place.
Change-Id: Ib7d6179e6703ed3353fce44c3e54f5be1c1dfa68
