fdo#46808 - [Easy Hack] Adapt UNO services to new-style
noelgrandin at gmail.com
Thu Mar 22 05:56:03 PDT 2012
That was just about to be my next question :-)
How do I decide whether to change the constructor to take
XComponentContext or XMultiComponentFactory?
On 2012-03-22 14:36, Stephan Bergmann wrote:
> On 03/22/2012 01:11 PM, Noel Grandin wrote:
>> Diff attached.
>> @@ -258,12 +259,7 @@ void SAL_CALL ResultSetImplHelper::connectToCache(
>> - = uno::Reference<
>> com::sun::star::ucb::XCachedDynamicResultSetStubFactory >(
>> - m_xSMgr->createInstance(
>> - rtl::OUString(RTL_CONSTASCII_USTRINGPARAM(
>> "com.sun.star.ucb.CachedDynamicResultSetStubFactory" )) ),
>> - uno::UNO_QUERY );
>> + =
> Note that UNO service constructors, in the C++ and Java language
> bindings, take the XComponentContext as an additional first argument.
> In your example, ResultSetImplHelper does not have a component context
> around, only an XMultiServiceFactory m_xSMgr (because it is old code,
> written before the XComponentContext/XMultiComponentFactory concept
> replaced the now-obsolete XMultiServiceFactory concept).
> As a quick fix, you can pass comphelper::getProcessComponentContext()
> (#include "comphelper/processfactory.hxx") into create(), but you
> unfortunately cannot even commit that, as it violates module
> dependencies (comphelper depends on ucbhelper, so ucbhelper cannot
> depend on comphelper). The right fix is to change the
> ResultSetImplHelper constructor and adapt all its uses accordingly.
> Did I speak about an odyssey? ;)
> LibreOffice mailing list
> LibreOffice at lists.freedesktop.org
More information about the LibreOffice