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>
Commit 4f9f1ac333 (sw: allow viewing OLE
objects in protected sections, 2021-11-25) allowed launching OLE objects
in protected sections, and then made sure that changes done in "real"
OLE editors (on Windows) are discarded: both the native data and
preview.
Extend this mechanism to also handle common embedded objects (i.e. when
we load the data into an own document model, like Calc-in-Writer on
Linux): there we can simply load the data read-only, so there will be no
need to discard anything.
This requires some way to pass down the read-only flag from sw/ to
embeddedobj, implement XInitialization on OCommonEmbeddedObject to do
that.
Change-Id: I7b32d7514a6b0a40b4f58bed57879d292daa4ed7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125858
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
... to avoid hidden cost of multiple COW checks, because they
call getArray() internally.
This obsoletes [loplugin:sequenceloop].
Also rename toNonConstRange to asNonConstRange, to reflect that
the result is a view of the sequence, not an independent object.
TODO: also drop non-const operator[], but introduce operator[]
in SequenceRange.
Change-Id: Idd5fd7a3400fe65274d2a6343025e2ef8911635d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123518
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Inserting a large file can take a while, and we do it on the main
thread, so the UI is frozen during the operation.
Create the progressbar in cui, which is allowed to link against sfx2/
and then pass it down to embeddedobj/. Similarly for the label of the
progressbar, again because cui is allowed to link against svx/.
Change-Id: I53fec4e14df647b140647d9ff5a3a37c0aa9e72e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122825
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
- Change implementations of getSomething to use getSomethingImpl
Or where that's impossible, use getSomething_cast to unify this and
reduce number of places where we reinterpret_cast.
All static methods getting tunnel ids were renamed to getUnoTunnelId,
to comply with the convention used in <comphelper/servicehelper.hxx>.
TODO (in separate commits):
- Revise uses of getSomething to use getFromUnoTunnel
Change-Id: Ifde9e214b52e5df678de71fcc32d2199c82e85cf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122100
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
This gives UNO clients a reliable way to detect e.g.
OSpecialEmbeddedObject, where it's expected that double-clicking on the
object doesn't do anything.
Change-Id: I595453490b157b64214cd7359da1e3a3c959191d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120274
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
based on OInterfaceContainerHelper2 which is considerably
faster than the original OInterfaceContainerHelper
Change-Id: Ia8cdbc5ef877a7af3d9193e1bb2faf1595c15470
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120165
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
based on OInterfaceContainerHelper2 which is considerably
faster than the original OInterfaceContainerHelper
Change-Id: I9c8b6d0e5382018824bf7188a26343703abf2d51
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120161
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
This is needed when an out of process Java UNO client registers their
command dispatch interceptor, Windows OleInitialize() has been called
already on the main thread and then dispatching e.g. uno:Paste (which
would interact with OLE) would call OLE functions on a thread, which
would fail with RPC_E_CHANGED_MODE.
In other words, a situation similar to commit
22aa6508e0 (framework: allow dispatching a
command on the main thread, 2019-01-29), but that one was for
DispatchHelper, this one is for XDispatch implementations.
Change-Id: If5a80fe36962e014e781d2a8c156055f127e69a5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118886
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
The Windows OLE2 implementation of the embedded object interface assumes
that the same thread is used for loading and saving the embedded
objects.
This means that in case the main thread is used for loading (e.g. from
remote UNO, but with OnMainThead=true), but a
thread is used for storing (without an explicit OnMainThead=true), then
the underlying win32 API call failed and we returned a fixed size in
EmbeddedObjectRef::GetSize().
Fix the problem by explicitly checking for RPC_E_WRONG_THREAD and adding
error handling for that case.
Change-Id: Icf1e7722d33a809fa671d1505b2a0155af040c71
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115236
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
How to reproduce the problem:
1) Create an ODT file which has an OLE object, where the native data is
an OLE2 container, containing a Package stream, containing a DOCX file
2) Install some external application on Windows which registers itself
as a handler for the DOCX CSLID [ this is where writing a testcase for
this bug is challenging ].
3) Open this document via Java, using URP. Load the document with
Hidden=true and OnMainThread=true.
4) Save the document using XStorable.store().
Expected result: the native data is there.
Actual result: the native data is sometimes missing (0 bytes).
The root cause is that GetUserClassID() Win32 API call in
OleComponent::StoreOwnTmpIfNecessary() fails in some cases, and
re-trying a few times after a small sleep doesn't help.
Handle this error better by doing what
OleEmbeddedObject::SwitchOwnPersistence(XStorage, OUString) already
does: discard the old native data only if we have non-empty new native
data.
A result of the above was that an export to reqif-xhtml (sw HTML export
with FilterOptions set to xhtmlns=reqif-xhtml) wrote empty \objdata.
Change-Id: I59611601cf09597e9f7727db5bd6d7426fe17b75
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114537
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
How to reproduce the problem:
1) Create an ODT file which has an OLE object, where the native data is
an OLE2 container, containing a Package stream, containing a DOCX file.
2) Install some external application on Windows which registers itself
as a handler for the DOCX CSLID [ this is where writing a testcase for
this bug is challenging ].
3) Open this document via Java, using URP. Load the document with
Hidden=true and OnMainThread=true.
4) Dispatch .uno:UpdateAll
5) Save the document using XStorable.store()
Expected result: the native data is there.
Actual result: the native data is sometimes missing (0 bytes). Typically
happens at least once if you perform the steps 4 times in a row.
The root cause is that GetUserClassID() Win32 API fails in some cases,
and re-trying a few times after a small sleep doesn't help.
Handle this error better by detecting this situation in
OleEmbeddedObject::SwitchOwnPersistence() and reusing the old native
data, similar to how svt::EmbeddedObjectRef::GetReplacement() updates
the preview image in a transactional way (only delete the old one when
we have a one one).
Finally, detect a broken OLE2 preview during reqif export, this way the
reqif export result's embedded object is editable in Word, while
\objdata was simply empty previously.
Change-Id: I4dd34ebe6ad892a14cdcfb82acc82d9edf790fb3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113814
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
Before deactivating a linked OLE saved it and overwrote the
original, even when not saving the hosting document at all.
This is not intuitive from user perspective and may lead
to unexpected data loss (of the OLE content).
Reported case was especially about closing the hosted document
without saving in the understandable believe that that way the
changed OLE will not be changed on external medium.
Added mechanism for linked OLE to hold data in a hidden local
temp file, synching/writing back on hosting file save. Most
complicated was adapting the 'break link' case and ensuring
other cases to work, but looks good now from my POV
Change-Id: I7f63d667820b2d9725abc598a9dd7360be1f8d5a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113793
Tested-by: Armin Le Grand <Armin.Le.Grand@me.com>
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
Take m_xDocHolder->GetComponent() and xModif->setModified
inside the local try..catch expression to ensure that the
reset of the linked state below (m_bIsLink and .clear())
is executed
Change-Id: I52d49569a43fd2c23dd997c7217f7552cbdcfb82
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113722
Tested-by: Armin Le Grand <Armin.Le.Grand@me.com>
Reviewed-by: Armin Le Grand <Armin.Le.Grand@me.com>
So in SfxViewFrame::GetState_Impl in case SID_OBJECT hasVerbs is not
empty, so that the doVerb attempt with -9 fallback is attempted
Change-Id: If32c50fedbc2a269ac277061c76a63514d320bb7
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/110316
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
to make it more obvious when we are constructing heap OUStrings
code and potentially inadvertently throwing away performance.
And fix a handful of places so revealed.
Change-Id: I0cf390f78026f8a670aaab53424cd31510633051
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107923
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Juergen Funk