On Wednesday 12 September 2007, Andreas Schlüns wrote: > 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.
I see. I do something very similar on a lot of my work. I have a number of daemons running on my system and I have a launcher that sets up a few file paths then has a loop that does nothing but launch the program, then wait and loop back and relaunch if it stops. The idea is to make the launch loop so simple that it won't crash unless there's a serious catastrophe. > 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 ? Yes, I'm sure the bridge stays alive. While I had to change things on the last day or so, I had a "watcher" thread that would track all OOo function calls. If there was an error, OOo would automatically be restarted and that would show in the output and in the log file. After each recovery window showed, the connection was still there. Here's another point, one I forgot, and the more I think about it, the more important it sounds. Sorry for not including it earlier. This has been a rough several days. When I get the recovery window, there is no filename for the bad document. It's blank! And, as I said, when I relaunch, there is no recovered document I can pick to recover, just the regular Writer window that opens. I'm sorry I left that bit out before. That would make me wonder, even though the problem only occurs with one printer, if the error is happening when or just after the document is closed. Is it possible, whether I'm using the listener or sync printing, that with dual CPUs there could be an issue with threading so printing is not quite complete due to driver issues so when the document is closed, there's still some printing work going on? I'm just thinking over whatever ideas I can at this point. I don't know if they hold any merit. > > 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. It's never completely died, though. I've just gotten the document recovery window. I didn't check the "Can we contact you" because the contact info in that install is for my client, not for me, but I did make sure I sent in the debugging info at least once. > "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 :-) If I get more time to test this on my client's "bad" printer, I'll try some more debugging to verify the print finishes. > > 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 I just wanted to be sure. (I hate the idea of that one registry for everything. To big and over done and to "one registry for all" is too much like "one ring to rule them all"...) > :-) 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. It seems to me the only way to be sure to make a different configuration is to create a special OOo install itself that is only used for scripting. Is there another way to do it? > 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" ? :-) Okay. That reference explains it all! > > 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 :-) Close. Second best overall and best business decision. The best decision he ever had involved a former girlfriend, legal papers, a bad Internet connection, and a peppy and likeable dachshund. (And it's as puzzling and strange as it sounds!) Hal --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
