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(
try
{
xStubFactory
- = uno::Reference<
-
com::sun::star::ucb::XCachedDynamicResultSetStubFactory >(
- m_xSMgr->createInstance(
- rtl::OUString(RTL_CONSTASCII_USTRINGPARAM(
-
"com.sun.star.ucb.CachedDynamicResultSetStubFactory" )) ),
- uno::UNO_QUERY );
+ =
com::sun::star::ucb::CachedDynamicResultSetStubFactory.create();
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? ;)
Stephan
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
