After reverting 2b4cd99d, editing an OLE link whose source is already
open in this LO instance produces a sharing-violation on save (the
intra-process scenario tdf#126742 was working around).
Detect the conflict at doVerb, gated to verbs targeting a visible
state so internal RUNNING transitions aren't intercepted. If the
source is loaded as another visible frame in this LO, switch to that
window (matches MSO behaviour). Otherwise probe for any .~lock or
MSO ~$ file - foreign user, hidden own frame, or stale own lock from
a crash - and show an async warning with the lock owner. In all
cases the OLE working copy is never created. Skipped in headless
mode.
Change-Id: Ic87bb6f073b0b04ec47597cc15f2c5a83cc2bffc
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/2004
Reviewed-by: Michael Stahl <michael.stahl@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/204940
Reviewed-by: Balazs Varga <balazs.varga@collabora.com>
Tested-by: Jenkins
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
...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>
Tools -> Options -> Load/Save -> Microsoft Office has config options to
decide that Word/Excel/PowerPoint formats are loaded into our doc models
(default) or handled via external OLE applications instead.
This is used in the MSO import/export filters, but in case the UI is
used to insert a new file as an embedded object, then we ignored this
setting, and the embedding type depended on if we found an import filter
for the data or not (if yes, load it; handle externally otherwise).
Fix this inconsistency by checking for the usual MSO import filter names
and respect the existing configuration in those cases, so the user can
choose to not handle these formats internally if wanted.
Change-Id: I6bce8b5467768ef3f21d97b4e0fe3f4d18d9466b
Reviewed-on: https://gerrit.libreoffice.org/77449
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins
which requires explicitly adding null in
1) SdrItemBrowserControl::SetAttributes(const SfxItemSet* pSet, const SfxItemSet* p2ndSet)
where SdrItemBrowserControl is only used by SdrItemBrowser and the only use of that is
within DBG_UTIL in SdrPaintView
2) SwCursorShell::GetContentAtPos( const Point& rPt,
within a #ifdef DBG_UTIL block in
3) SvxSearchDialog::BuildAttrText_Impl( OUString& rStr,
bool bSrchFlag ) const
where the other branch uses SvxResId
4) SfxPoolItem::dumpAsXml(xmlTextWriterPtr pWriter) const
5) XFillStyleItem::dumpAsXml(xmlTextWriterPtr pWriter) const
looks very much like all uses (outside the dumpers) are intended
to be in the ui locale
results in that INetContentTypes::GetPresentation always called with UI Locale
Change-Id: I5a110c107838b4db3c355476426d6532f2b6ce52
Reviewed-on: https://gerrit.libreoffice.org/40538
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
Embedded documents had "Untitled" name.
This patch shows "<root document> (Embedded document)"
string in the title bar.
Change-Id: I6283240415f9e0c07c4c69672732a7c14eea9f5d
Reviewed-on: https://gerrit.libreoffice.org/39835
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Fortunately there is a special ole object group with
the MS_EMBED_ACTIVATEWHENVISIBLE flag which define this
behaviour.
Problem is that both Aspect and EmbedMisc are MS specific
enums so we can't use them directly for non-MS objects. But we
can handle opengl charts the same as this ole object group.
Change-Id: I49abeffce319cbb775709a72ba198a1f76b65374
- do not use gb_UnpackedTarball_copy_header_files for boost
- adapt the optimization in concat-deps.c for new path
- use boost_headers in all LinkTargets that require it
- add explicit include paths to mysqlc, mysqlcppconn, libvisio, liborcus
Change-Id: I0c43e73ed43cc9d2e6bce8faf55e992d655a0bb9
Always link in gb_STDLIBS, except when the library explicitly opts out
with gb_LinkTarget_disable_standard_system_libs.
Change-Id: I489a99114fbfa46d0421a27cf6c7b899dc268a4a
Naming convention for gbuild methods:
- "add" is used for stuff that is logically a part of the target
(i.e. not registered at the Module, but defined in the target's makefile)
- "use" is used for stuff that is logically a different target
(i.e. it is registered at the Module, has it's own makefile, may be
in a different module than the target)
Balazs Varga