... and use it to remove a duplicate and simplify code.
Should mostly be a refactoring, which was mainly done by some
larger sed calls, except for the new API calls, which helped
shrinking some LOC. All data is also now private.
Originally two of the "replaced" "classes" had unsigned width
and height and one had signed. Noel pointed out, that during
calculations, the value might get negative temporarly, so this
now settles with signed values. Still the set size should never
be negative and this is enforced this way. Not sure that is what
Noel had in mind.
This also includes:
- rename WindowState => WindowData
- rename WindowStateMask => WindowDataMask
- rename WindowStateState => WindowState
- move WindowState and WindowDataMask to vcl/windowstate.hxx
- move WindowData(Mask) and WindowState into vcl namespace
- readability: replace or'ed WindowState enums with "meta" enums
+ add "meta" WindowState enums PosSize and PosSizeState
Change-Id: Icd16cfb498531aa7238ddbde83fcb0ed6d9e4f77
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135426
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
As reported by Julien, once the mediawiki extension is installed, the
xHandler in framework::DispatchProvider::implts_searchProtocolHandler()
points to an UNO component implemented in Java, and we crash in
dynamic_cast<>(), at least on Linux with gcc 7.5 and libstdc++.
This dynamic_cast<>() call was added in commit
c0fa456436 (tdf#149261 sdext: fix crash on
starting the presenter console for the 2nd time, 2022-05-26), to allow
the presenter console to opt out from protocol handler caching. It was
expected that the proxy object created for a Java UNO component would
simply return nullptr when we try to dynamic_cast<>() it down to a C++
interface.
Fix the problem by moving the interface to an UNO one: this side-steps
the dynamic_cast<>() crash at the price of introducing an UNO interface,
which is not meant to be part of the public UNO API (but at least it's
not published).
It may still make sense to improve the bridges/ code at some stage to
not crash in dynamic_cast<>() on generated Java proxy objects.
Change-Id: Iaac44515339e0dc15dddc3be45ef7dee7331e47a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135114
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
There is a non-obvious difference in error handling when opening the
file read/write for type-detection fails in
utl::MediaDescriptor::impl_openStreamWithURL() - if ReadOnly=false is
given, it will abort the file loading, whereas without any ReadOnly it
will fall-back to a read-only opening of the file for type detection.
At this point a StillReadWriteInteraction is used, so the user is never
notified of the failure.
(regression from commit 404c51f366)
Change-Id: I8c06fe23cc0bc0767df83f680a1a59e3700bbbbb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135045
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
This started with commit 3f768cddd2
(framework: avoid re-creating protocol handler instances all the time,
2022-05-02). In case there are 2 monitors, then one monitor shows the
slideshow, the other shows the presenter console. The presenter
console's protocol handler in
sdext::presenter::PresenterProtocolHandler::Dispatch::Dispatch() has
mpPresenterController->GetWindowManager() as an empty reference on the
2nd time the presentation starts.
The above commit started to cache protocol handler instances at a frame
level for performance reasons, and this is meant to be safe in general,
but the presenter console's window manager is re-created between
slideshow runs, so it depends on framework/ code to re-create the
protocol handler all the time, which is problematic here.
Fix the problem by introducing a framework::CacheInfo interface that
allows protocol handler implementations to signal if they want to avoid
being cached.
This should be good enough for now, but if later it turns out that there
are too many broken protocol handlers out there, then we can consider
flipping the default and only cache handlers which explicitly opt in for
this behavior. This is not done in this commit.
Change-Id: Ic159813b1b339540bc8c4e780c4d6d7d2d4d2445
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135020
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Autorecovery information was saved in every 10 minutes,
regardless of the "Save Autorecovery information every" setting.
Change-Id: I1a52da2fa5febb53c270a8db7472e9a8c0e4c426
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134642
Tested-by: Jenkins
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
file by asking password re-typing unstoppably. Instead
of this, skip recovery file saving, if the document
contains password hashes which haven't been supported
by the "calc8" filter of the recovery file (which
triggered the "Re-type password" dialog).
Solved problems:
– Asking for passwords during a non-interactive
background process.
– A single Cancel didn't close the "Re-type password" dialog
window, only pressing three times at least (according to the
value of RETRY_STORE_ON_MIGHT_FULL_DISC_USEFULL), but
waiting for the password for a while could result a
frozen "Re-type password" dialog, where only retyping or
removing the password(s) were the escape routes.
– Re-typing the password required the password (but modifying
the original document doesn't require this).
– Removing the password resulted in loss of the protection
after saving the original XLSX document.
Add a UI test to keep the "Re-type password" dialog during Save As.
Note: because of the regression reported in tdf#145757, it needs
to wait 10 min for saving the recovery file, yet, despite the
changed time in Tools->Options->Load/Save->General.
Change-Id: Icc6ee4d67048cdf15ab75ef8e2ee8f1709cdd4c2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134409
Tested-by: László Németh <nemeth@numbertext.org>
Reviewed-by: László Németh <nemeth@numbertext.org>
include/osl/mutex.hxx:196: void osl::ClearableGuard<T>::clear() [with T = comphelper::SolarMutex]: Assertion `pT' failed.
because clear() was called, then an exception was thrown and reset() was
omitted.
Change-Id: Iaa6d26e23261c2426eb3cc465b212752c4f454e5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134195
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
...when iterating over the enumerators of enum StatusBar_XML_Entry resp. enum
ToolBox_XML_Entry
Change-Id: I11904e941e98e0ffb96cf1ba4e61c91382944813
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134169
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Regression from b099da78a6f0b3e120f706714003b05d84d11e70
we didn't update linked OLE document after document reload
Change-Id: I8e52f6430f454b276cb43449c6f7a3b0e07e909f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130692
Reviewed-by: Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de>
Tested-by: Jenkins
Once you install an extension that adds its own protocol handlers (e.g.
<https://github.com/niocs/ProtocolHandlerExtension>), DispatchProvider
re-creates this protocol handler every time the custom menu gets opened
or a command gets dispatched.
This allows the dispatch provider to avoid managing the lifecycle of
those protocol handler instances, but in case the constructor of those
handlers is expensive, this leads to performance problems.
Introduce a map of handler instances in DispatchProvider to avoid
unnecessary re-creation and re-initialization: these instances get the
same XFrame anyway (the DispatchProvider is owned by the frame), so this
is meant to be safe.
No testcase for this -- the problem is only visible if you have an UNO
service registered in the global UNO service registry, but by the time
our cppunit tests run, that is already a fixed list, so this would be
hard to test from code.
Change-Id: I6d69906a795a2d5a67706002d635b6cb3091b856
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133706
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Add Office::Histories::HistoryItem::ReadOnly flag to configuration so
that a document that was opened read-only isn't opened as editable from
recent documents.
Change-Id: I6985da287d3337a53a7e41e8e500421038eedb91
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133385
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Introduced in commit 2d01ed9e8b
Author Muhammet Kara <muhammet.kara@collabora.com>
Date Mon Nov 25 21:55:31 2019 +0300
tdf#94288: Show chart props sidebar on activation
The problem was that ChartController::attachFrame, that called
SelectionChangeHandler::selectionChanged notification, did that
*prior* to setting its m_xFrame - and the notification failed
in ContextChangeEventMultiplexer::NotifyContextChange, that
checks the frame first. That prevented the proper context (with
correct application and context names) to arrive to listeners,
and the sidebar didn't update properly.
Changing the order of the calls should fix the original problem.
Change-Id: I9da8465af2ee4ed1f8eabed1c65d1c318f81a3f9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133326
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
look for call sequences that can use string_view and the new o3tl
functions in o3tl/string_view.hxx
Also add a few more wrappers to said #include file
Change-Id: I05d8752cc67a7b55b0b57e8eed803bd06bfcd9ea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132840
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
where we can convert that to
o3tl::toInt32(o3tl::getToken(
and avoid the heap allocation of a temporary string
Change-Id: Ib11c19c6e6cdc0de3e551affd3578d181e292de4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132810
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...mainly to demonstrate that its SolarMutexGuard was redundant and that
replacing it with DBG_TESTSOLARMUTEX() would be overkill
Change-Id: I82f00873cd99cb5da1b644c40ba25f8c210503cd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132112
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Regression introduced with d4257daba1 "use
comphelper::WeakComponentImplHelper in MenuBarManager" changing
- if ( rBHelper.bDisposed )
+ if ( m_bDisposed )
in MenuBarManager::Destroy, but where comphelper::WeakComponentImplHelper sets
m_bDisposed to true before calling disposing.
And Destroy is only called from disposing, so the check can just be removed.
Change-Id: I2625dff9fbb333435a0d1478b0f285c21cd3ee15
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132075
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Jenkins
It's used only for the ConfigurationWrapper singleton, so it's used
only the first time and then ignored. It also causes calls to
comphelper::getProcessComponentContext() for every single invocation
despite the value not being needed, and the calls may not be cheap
(it's ~5% CPU during ODS save because relatively frequent calls
to officecfg::Office::Common::Save::ODF::DefaultVersion::get()).
Change-Id: I02c17a1a9cb498aeef220ddd5a0bde5523cb0ffb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131056
Tested-by: Jenkins
Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
The ScHeaderFieldObj Java tests are implemented in
ScEditFieldObj_Header.
Change-Id: I45d3b17bd244090c491c85475f20bc06eb92908f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130953
Tested-by: Jenkins
Reviewed-by: Jens Carl <j.carl43@gmx.de>
Move XComponent Jave tests to C++ for ScCellFieldObj_Cell and
ScCellFieldObj_Header (formerly ScCellFieldObj).
Change-Id: Ibf293a72801720fee49acdda5a3a463e9202bb58
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130742
Tested-by: Jenkins
Reviewed-by: Jens Carl <j.carl43@gmx.de>
Jan-Marek Glogowski