...which was introduced with 3ead3ad52f9bb2f9d1d6cf8dfc73a0a25e6778ed "Gradually
typed Link" to distinguish the new, typed versions from the old, untyped ones,
but is no longer necessary since 382eb1a23c390154619c385414bdbe6f6e461173
"remove untyped Link<>" removed the old versions.
Change-Id: I494025df486a16a45861fcd8192dfe0275b1103c
causes mathtype to display a warning dialog, so
try restoring them back to loaded after loading
them in order to get their preferred size
Change-Id: Idff714efa228a739f380dbae429d852a8f8c5298
Reviewed-on: https://gerrit.libreoffice.org/29234
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
sample pptx crashes down in the depths of (apparently pre-installed on
32bit Windows 10) Flash.ocx
Change-Id: I4e083d492e56e72df47b2c172d7f07f0e39b82ea
Reviewed-on: https://gerrit.libreoffice.org/29199
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
so the user update links dialog can control their generation
SdrEmbedObjectLink becomes exposed to calc so it can
detect if the link dialog needs to be used to update
ole links.
Change-Id: Id1dd7ea17342140eab9307d546528747e3a98090
Reviewed-on: https://gerrit.libreoffice.org/28879
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
The issue of 362d4f0cd4e50111edfae9d30c90602c37ed65a2 "Explicitly mark
overriding destructors as 'virtual'" appears to no longer be a problem with
MSVC 2013.
(The little change in the rewriting code of compilerplugins/clang/override.cxx
was necessary to prevent an endless loop when adding "override" to
OOO_DLLPUBLIC_CHARTTOOLS virtual ~CloseableLifeTimeManager();
in chart2/source/inc/LifeTime.hxx, getting stuck in the leading
OOO_DLLPUBLIC_CHARTTOOLS macro. Can't remember what that
isAtEndOfImmediateMacroExpansion thing was originally necessary for, anyway.)
Change-Id: I534c634504d7216b9bb632c2775c04eaf27e927e
This was triggered by
This appears to be triggered by 08cf2fd01064306eef7fdbb5b62320947c4d1089
commit 08cf2fd01064306eef7fdbb5b62320947c4d1089
Author: Thorsten Behrens <Thorsten.Behrens@CIB.de>
Date: Fri May 20 16:48:00 2016 +0200
which changed the order that things registered through
registerDispatchProviderInterceptor are used by, so swap the order of
registerDispatchProviderInterceptor calls here to sync with that
Change-Id: I047e4c7f6cb488c646df717e22c8ac91864c3938
...which (in LIBO_INTERNAL_ONLY) for Clang expands to [[clang::fallthrough]] in
preparation of enabling -Wimplicit-fallthrough. (This is only relevant for
C++11, as neither C nor old C++ has a way to annotate intended fallthroughs.)
Could use BOOST_FALLTHROUGH instead of introducing our own SAL_FALLTHROUGH, but
that would require adding back in dependencies on boost_headers to many
libraries where we carefully removed any remaining Boost dependencies only
recently. (At least make SAL_FALLTHROUGH strictly LIBO_INTERNAL_ONLY, so its
future evolution will not have any impact on the stable URE interface.) C++17
will have a proper [[fallthroug]], eventually removing the need for a macro
altogether.
Change-Id: I342a7610a107db7d7a344ea9cbddfd9714d7e9ca
Sequence.h(xx), Any.h(xx) and Type.h(xx)
and remove unused using-declarations from these files.
Add a few missing includes provided by them.
Change-Id: I6b91b6d1fdf9d0496dd546c0aab9bdcc6831a5d4
Reviewed-on: https://gerrit.libreoffice.org/23805
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
stage 2 of replacing usage of various checks for the windows platform
with the compiler-defined '_WIN32' macro
In this stage we focus on replacing usage of the WIN macro
Change-Id: Ie8a4a63198a6de96bd158ecd707dadafb9c8ea84
Reviewed-on: https://gerrit.libreoffice.org/22393
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
A ridiculously fast way of doing this is:
for i in $(pcregrep -l -M -r --include='.*[hc]xx$' \
--exclude-dir=workdir --exclude-dir=instdir '^
{3,}' .)
do
perl -0777 -i -pe 's/^
{3,}/
/gm' $i
done
Change-Id: Iebb93eccbee9e4fc5c4380474ba595858a27ac2c
Reviewed-on: https://gerrit.libreoffice.org/22224
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Chris Sherlock <chris.sherlock79@gmail.com>
create an InterfaceContainer2 class to replace InterfaceContainer.
It uses a std::vector instead of a Sequence for the mutable listener
list, which provides far better performance.
Switch all our internal use-sites to the new class.
Change-Id: I6b56cfa511ded2395faa22e68fab3b2f16c3cb88
OleEmbeddedObject::changeState() calls TryToConvertToOOo() on non-WNT
platforms, which appears highly questionable to me, added in commit
0c3d5fb0ad35ff7fc18917fc86fa58d9312fe3ae.
What this does effectively is load the embedded object, store it as ODF,
and then load it again as ODF.
For one, it doesn't work in all cases currently. If changeState() is
not called from the UI but from some filter code, then no m_xClient may
be set on the OleEmbeddedObject, hence no m_xClient will be set on the
new m_xWrappedObject. Then loading the embedded object will raise
errors due to missing BaseURL, and storing it will fail in
SfxObjectShell::SaveTo_Impl(). (It would be possible to solve that by
copying the "DefaultParentBaseURL" handling code from
OCommonEmbeddedObject.)
The only reason why the previous code in ShapeExport::WriteOLE2Shape()
was able to export the object despite the error is that it does not call
SfxBaseModel functions but directly invokes the export filter, so the
sfx2 code does not get an opportunity to check its error status.
For another, doing this only on non-WNT platforms is also hazardous.
It's probably better to leave conversion to own formats to an explicit
UI action, as the OleEmbeddedObject::doVerb(-9) magic currently does,
where it can hopefully be assumed that the caller at least established
the client connection first.
Change-Id: Ice3d8f8ceabe81b6e9025957c3eb87de9dbfe61a
