Hello Hal,
Here's the weird part: On this client's computer, when I get the
recovery window, OOo is STILL running and if I close that window, my
program can still connect to OOo.
You must differ between the "crash save" and the "recover files" dialog.
First one is shown directly after the crash occured and try to save all
currently open documents. After saving of those documents was done the
whole office process will be restarted ... and then you will see the
"recover files" dialog. To make such reboot possible we use a second
process.
If you have a look on your task manager you will see two processes
(soffice.bin and soffice.exe). Soffice.bin is the "real" office process
... soffice.exe is a small wrapper executable only. The wrapper
executable will never crash [hopefully :-)] and so it will stay alive
for the whole time. But soffice.bin can crash and will be restartet
automaticly by the wrapper.
So for an outside user it looks like the office stays alive.
On the other side your bridge connection was established directly to the
soffice.bin process ... so it should be killed by such reboot also. I do
not know anything about smoothless reconnecting such bridges. So I'm
wondering how it should work. Are you realy sure that your bridge stays
alive ?
If I even got just, "OOo is dead," I can deal with that by restarting
it. If I could get, "Print successful" from the print function call, I
could use that and an "OOo is dead" to know if the doc printed before
death.
"OOo is dead" should be signaled by a suitable RuntimeException of the
bridge thrown by every remote request on any UNO object your client knows.
"Print successfully" can be detected if your synchron print call does
not throw an exception and you reach your next line of code. Of course
real notification of successfully print jobs are done by using a print
listener :-)
Do you mean a registry entry as in a Windows registry, or in an OOo
config file? If it's in a config file, I could make the change when I
start and change it back when I'm done, or find another work around.
I mean "an OOo config file" of course - otherwise I have to make my code
system dependend (linux, windows etcpp) which wont be an option anyway
:-) But making such changes at runtime isnt a realy good idea ...
Because you must make sure that your client application enever crashes
without reseting those option !
Everytime such requests about client-office-scripting use cases occure I
have the same tip: configure a special user configuration layer for that
use case (different from the normal one). That will make persistent
changes possible. You can configur that office instance as you like -
you wont need bootstrap code to make all those changes at runtime.
See it as a seperate application - different to the normal UI case of
OOo. And in fact - its a different application with it's own definitions
and settings.
From what you're saying, though, the problem is that the recovery flag
is not something that can be changed in a running instance. It has to
be set as on or off when the program is run. Is that right?
Right. It cant be done another way ... otherwise it can happen that a
crash occure on starting the office before the configuration setting was
realy read from the configuration. Do you know "Münchausen" ? :-)
One thing I like about working for myself is that my boss would rather
me take longer on a program and produce elegant code than to rush and
have something ugly that's hard to maintain. ;-)
Best decision you boss ever had :-)
Hal
Regards
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
