It sometimes crashes on windows. Switch to using the same
tearDown() logic as UnoApiTest::closeDocument, which
seems to be the most reliable variant of this kind of code.
Change-Id: I1493d6d265763b2aec4ee94f4ee66378dbe280b6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141238
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
...so that its TOOLS_WARN_EXCEPTION can be used in
comphelper/source/misc/logging.cxx in a follow-up commit. (And while at it,
rename from diangose_ex.h to the more appropriate diagnose_ex.hxx. The
comphelper module is sufficiently low-level for this immediate use case, so use
that at least for now; o3tl might be even more suitable but doesn't have a
Library until now. Also, for the immediate use case it would have sufficed to
only break DbgGetCaughtException, exceptionToString, TOOLS_WARN_EXCEPTION,
TOOLS_WARN_EXCEPTION_IF, and TOOLS_INFO_EXCEPTION out of
include/tools/diagnose_ex.h into an additional new
include/comphelper/diagnose_ex.hxx, but its probably easier overall to just move
the complete include file as is.)
Change-Id: I9f3222d4ccf1a9ac29d7eb9ba1530d53e2affaee
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138451
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
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
Xisco Fauli