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).
Context
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.