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.
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 :-)
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 !
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.
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.
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 :-)
Hal
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Regards
NAdreas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
