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
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>
Which reduces the probability that the base class name collides with a
symbol from non-test code.
Change-Id: I7df17a76602b12da7b10cb77f6e44466676d15a3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130811
Tested-by: Jenkins
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
...instead of by listing the content somewhat redundantly in the Rdb_*.mk
files, to avoid duplication of logic for components that are only built
conditionally (and thus should only be included conditionally in the
corresponding Rdb). To achieve that, add an "rdb" parameter to
gb_ComponentTarget_ComponentTarget (and to the gb_*_set_componentfile macros
that internally call gb_ComponentTarget_ComponentTarget), which is used to make
the appropriate gb_Rdb_add_component call internally from within
gb_ComponentTarget_ComponentTarget. (As a special case,
gb_CppunitTest_set_componentfile shall not call gb_Rdb_add_component, as that
has already been done by the corresponding gb_Library_set_componentfile call, so
allow the gb_ComponentTarget_ComponentTarget "rdb" parameter to be empty to
support that special case.)
Most Rdb_*.mk files are thus mostly empty now. One exception is
i18npool/Rdb_saxparser.mk, which duplicates some of the Rdb_services content as
needed during the build in CustomTarget_i18npool/localedata.
1c9a40299d "gbuild: create services.rdb from built
components" had already tried to do something similar (in addition to other
things) under a new --enable-services-rdb-from-build option. However, that
approach had four drawbacks that this approach here addresses (and which thus
partly reverts 1c9a40299d):
1 Rdb_services shall not contain the component files of all libraries that are
built. While that commit filtered out the component files that go into
Rdb_ure/services (ure/Rdb_ure.mk), it failed to filter out the component files
that go into others like Rdb_postgresql-sdbc
(connectivity/Rdb_postgresql-sdbc.mk).
2 The code added by that commit to Makefile.gbuild codified the knowledge that
there is an Rdb_services, which is brittle.
3 The code added by that commit to solenv/gbuild/Rdb.mk codified the knowledge
(for gb_Rdb__URECOMPONENTS) that there is an Rdb_ure/services, which is brittle.
4 Introducing an --enable-services-rdb-from-build option needlessly provided
two different ways how the content of Rdb_services is assembled.
The changes done here would leave --enable-services-rdb-from-build as a
misnomer, as it no longer controls how Rdb_services is assembled. I thus
renamed it to --enable-customtarget-components, as that is apparently what it
still does now.
Change-Id: Ia5e8df4b640146c77421fcec6daa11a9cd260265
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126577
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.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>
Previously, all of the README files have been renamed to README.md
and now, the contents of these files were changed to use Markdown
format. Other than format inconsistency, some README.md files lacked
information about modules, or were out of date. By using LibreOffice
/ OpenOffice wiki and other documentation websites, these files were
updated. Now every README.md file has a title, and some description.
The top-level README.md file is changed to add links to the modules.
The result of processing the Markdown format README.md files can be
seen at: https://docs.libreoffice.org/
Change-Id: Ic3b0c3c064a2498d6a435253b041df010cd7797a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113424
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
Noel Grandin