thanks for the reply. On Thursday 20 May 2010, Stephan Bergmann wrote: > On May 19, 2010, at 6:37 PM, denis wrote: > > using OOo SDK 3.2, the attached C++ example of a manually created bridge > > segfaults while accessing the instance of com.sun.star.frame.Desktop > > (the last line in the test-function). > > Set up that way, the UNO environment bootstrapped in your client > process will only know about the basic URE UNO types, not any > OOo-specific ones like com.sun.star.frame.XDesktop, hence the runtime > problems. (There should be an old interface-announce mail detailing > that, but I currently don't find it.)
Is this different in java? The example from the developers guide 'ConnectionAwareClient' just gets its first context from com.sun.star.comp.helper.Bootstrap.createInitialComponentContext (null) and then creates the "Connector" from that. With C++ using cppu::bootstrap_InitialComponentContext (0) I can't even create the connector. Using cppu::defaultBootstrap_InitialComponentContext() everything was fine until I switched from OO 2.4 to OO 3.x. > You should seriously consider using the "simple bootstrap" mechanism > (<http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/ProUNO/Java/Transparent_Use_of_Office_UNO_Components>) > in your client application, shielding you from the details of > bootstrapping an appropriate UNO environment. but this expects a locally running/installed office, right? I have the situation that there is either an office running locally or on another computer. And even in the former case I still need the control over which office gets startet. Now I'm still using defaultBootstrap_InitialComponentContext() and created the file myapprc besides myapp (the office installation is delivered with my application so I fortunately know the installation path): [Bootstrap] URE_BOOTSTRAP=/path/to/office/openoffice.org3/program/fundamentalrc Then I either connect to a remote office or start the locally installed office and then connect to that one. Is there anything wrong with that? Regards, Denis --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
