On Wednesday 12 September 2007, Andreas Schlüns wrote: > Hello Hal , > > >>> 2) How can I keep the Document Recovery Window from popping up > >>> and get Java to throw an error instead? > >> > >> You can disable the whole recovery stuff be passing an option > >> "-norecovery" to your command line if you start the office. > > > > Okay. What happens then? Does it throw an error instead? Do I > > get any notice? Is there a way to disable recovery form within > > Java? I've had a few issues with running from the command line and > > using multiple arguments. (Long story on that...) > > You will get an exception from the bridge you used to connect the > office. But those exception can tell you "office has died" only. > Nothing more in detail.
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. 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. > I know that our boostrap class isnt ready for passing any command > line parameter to the office currently. Hopefully that will be > changed asap. But sorry - currently the command line way is the only > one how recovery can be disabled. mmmhhhh ... in the moment I'm > thinking about that I had an idea. Might be I can establish a > configuration entry which disables recovery at all. On the other side > such configuration entry will have some other disadvantages ! If you > client application uses the normal user layer of the installed office > it will also disable recovery for the UI use case - which might was > not expected. Only solution here - use a different configuration > layer ... which requires another command line parameter too :-) 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. 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? > > In one trail, I got the recovery window, closed it, and let my > > program continue. It then tried to close the document and I got an > > error because the document had already been disposed of. If I stop > > the recovery window, it'd be nice to have some other error thrown > > so I don't find out there's a problem until I try to close it. > > Hint: you should write your code for closing resources of OOo more > gracefully. If you e.g. whish to dispose() a component ... you should > catch any css.lang.DisposedException. It doesnt matter if you or some > others has destroyed those resource. Same for XCloseable. If you get > a DisposedException on close(false) it does not mean a real error ! That's on the list of things to do while cleaning up this situation. I had literally never gotten that error before and I didn't remember seeing it in the documentation, but when I wrote this class it was several years ago when I first started learning Java. I'm taking a few days off (I *really* need a break after this issue), then I'm going to add some more error trapping and some more graceful code for a few quick fixes I had to do to get it working. 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. ;-) > > If there were a way to catch an error or know a document had been > > lost, that would be a HUGE help and, as long as the document is > > lost *after* printing, I could program around it. > > As long as you hold a reference to these document it wont be "lost". > But yes - it can be already marked as "disposed". So you have to > handle that. That's the error I had and the one I'll be catching. It's an interesting error because if I catch it, I don't really have to do much and can skip the whole document closing routine. In effect, when I catch it, I say, "If disposed, then return now and just skip the next 10-20 lines of code for closing error trapping and logging." Oh, and I set a flag or two and return one variable to null. > >>> 3) Is there any other way to find out what problem is causing the > >>> Document Recovery issue? > >> > >> Yes - dont cancel recovery and have look on the last dialog. There > >> you will find button which show you the stacktrace. Another idea: > >> attach a debugger to the running office and let your operation run > >> till it crashes. The debugger will show you all threads and > >> stacks. On windows you can use the free Microsoft Visual C++ > >> Express 2005 edition. > > > > I don't have access to Windows development tools. The other issue > > is that I'm self taught. I've never used any kind of debugger > > other than print statements. > > Then you should have a look on the stacktrace shown by the recover > dialog as I've mentioned. I'll do that next time I can try this. Since using another printer has solved the problem, my client might be fed up with this and not want to spend more time on it. > >> But note: A debugger will also change the timing so it can happen > >> that the problem does not occure then :-) > > > > That's a consideration. > > > > Right now my client is quite happy printing to the other printer, > > but I still want to figure out what is going on here so I can solve > > it and don't have the same problem again with other clients. I'm > > going to have to space out my use of her computer for debugging for > > a while because she's had to give up a lot of time on it for me to > > debug everything. I will be looking at what I can do along the way > > and hope that I don't have to ask for time on her system until I > > have a clear idea of what I can do and have the code completely > > done. > > Without a debugger it will be difficult to find such type of > problems. Analyzing Java stacktraces of your client application wont > help - because they show the request started by your code only. But > they cant show you the stacktrace of the remote process (means OOo). > > Our recovery feature can show you the stack which crashed ... but it > doesnt show you all threads. But exactly that can help on analyzing > synchronization problems. > > So the one and only solution to find such problems ... will be a > debugger :-) On the other hand, if a stack trace shows me what command of mine is causing the error, that could help a lot. At this point, I think it comes down to a problem with the printer driver and how it, OOo, and Windows XP interact. I might see if it's possible for them to upgrade the driver. Hal --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
