On 05/21/10 12:14, denis wrote:
On Thursday 20 May 2010, Stephan Bergmann wrote:
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 symptoms can be different, yes.
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.
Which office gets started can be controlled via an environment variable
or some such (modulo
<http://qa.openoffice.org/issues/show_bug.cgi?id=66050> "Java simple
bootstrap may start wrong soffice").
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?
URE_BOOTSTRAP needs to be a file URL, not a pathname. And this approach
won't cover your demand for an office installed on another computer.
Apart from that: Yes, fundamentalrc should contain all the necessary
bootstrap variable settings so that your process bootstraps a full OOo
UNO environment (apart from other settings irrelevant for URE).
-Stephan
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
