When the object is edited in the UI, the m_xClient is set to a
SfxInPlaceClient and the DocumentBaseURL is retrieved from it. But if
the object is not edited, it will be loaded during export via the API
and without a m_xClient; in this case the DocumentBaseURL must have been
set previously to be available during import.
There appears to be no way to get the URL of the document via the API
while it is being imported; SfxBaseModel's m_sURL is unfortunately only
initialized from SfxObjectShell::FinishedLoading().
During ODF import, the SvXMLEmbeddedObjectHelper creates the
embedded object, so let's make it pass in the parent's BaseURL.
The "DefaultParentBaseURL" parameter already exists but was unused
previously.
Change-Id: I3d1ed29b3a2c0e77ec606a1d09f7bc07e7860733
...than by template parameter pack (even if that requires using ServiceDecl*, as
initializer_list cannot take reference types)
Change-Id: Ia986201b52d8daedfe925f132ebc79bc2c0ba378
... that contain std::unique_ptr. With C++11 variadic templates this
apparently works for both std::vector and std::set; associative
containers like std::map have different iterators so need a different
implementation.
Change-Id: I6872445b007875c310d08fa7a8d7311075880b1d
Reviewed-on: https://gerrit.libreoffice.org/19818
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Posting of the .uno:Something commands is asynchronous. To be able to find
out when eg. .uno:Save finished, this commit introduces a callback that fires
when that happens.
To be able to receive such a notification, the appropriate postUnoCommand()
must be called with 'true' as the parameter for bNotifyWhenFinished (defaults
to 'false').
Change-Id: I254939ebc8ea5f309ae39686dcaaeddd5148b0c9
If there is a need for it, this could be extended later to work with uno
sequences and/or OUStrings as well.
Change-Id: Id0af8b1755c8e4b668720563d10a052337e1b2c9
Replace BOOST_PP macros in comphelper with variadic templates. The
client interface should not change. However, there are a few side
effects due to this change. The most important being 1) There is no
longer a maximum number of service declarations limmited by default
at 12 for unwrapArgs and component_getFactoryHelper. 2)
component_getFactoryHelper now terminates early as soon as pRet is not a
null pointer.
Change-Id: I016fd208d0e80f91d8669fff29d58b6189e946d3
Reviewed-on: https://gerrit.libreoffice.org/18891
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
Sun bug numbers without any accompanying text are completely useless.
Fixed with
git grep -lP '//\s*#\d+#\s*$'
| xargs perl -i -ne'/\/\/\s*#\d+#\s*$/d or print'
And then hand-checking the result to restore places where it deleted code.
And then some more grepping and hand-editing to kill the others.
Change-Id: Ia96ce4466db8bb8da363ebf41f0ae7f45f28bf29
Reviewed-on: https://gerrit.libreoffice.org/19023
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
PropertySetInfo_Impl in ucb/source/core/ucbstore.cxx is sheer insanity,
persisting a PropertySetInfo into the configuration => throw up
hands in despair.
Change-Id: Ic341e453571072a9ed66c6bf51e96dbe39806566
There's a very similar comphelper::PropertySetInfo, unfortunately with
an additional mnMemberId on its properties, so convert a little...
Change-Id: I2a5fc0bb0ff6d680d546192b9d09afee6348f218
The OFOPXMLHelper class causes duplicate definition link errors
due to its WeakImplHelper base class.
It turns out that the OFOPXMLHelper class itself is only used by other
exported functions in comphelper itself so just hide the
implementation detail.
Change-Id: I3ac8c561af703193cc2609e2c799b630a0d43127
Try not to export the WeakImplHelper symbols as that causes duplicate
definition errors with the class OSelfTerminateFileStream that
has the same WeakImplHelper base.
Change-Id: Id41bfed24617113de48c76ab6802b21a8892e66f
