On 12/01/2014 12:29 AM, Chris Sherlock wrote:
So what about the following approach:Reference< XComponentContext > xContext = ::comphelper::getProcessComponentContext(); ::cppu::ContextEntry_Init aContextInfo[] = { ::cppu::ContextEntry_Init("testkey", uno::Any() ), } xNewContext = ::cppu::createComponentContext(aContextInfo, sizeof(aContextInfo) / sizeof (aHandlerContextInfo[0]), xContext); Then to get access to the container, I use something like this: Reference< container::XNameContainer > xNameContainer( xContext, UNO_QUERY ); Is this the right approach? Will the delegate ComponentContext work?
The "philosophy" behind the UNO component context is that a component (i.e., service or singleton) gets one passed in during creation (cf. e.g. the context argument to the UNO service constructors, implicit in UNOIDL but explicit in the C++ and Java language bindings at least) and in turn uses it to obtain any other components. This is somewhat blurred by the LO "convenience hack" of global comphelper::get/setProcessComponentContext().
That said, the above provides you with a functional xNewContext that you could "locally" use to instantiate some component with. See my other reply for a way to instead modify the existing "global" component context (what is what you actually want to do, for whatever reason, I assume).
_______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
