Hello Hal Vaughan,
Oh, and I am using XCloseable.close(true) to close a document.
mmmhhhh ... in my last mail I've mentioned to use close(false) .-)
It's always better to errors on closing documents by yourself instead
of delivering the owner ship to any other and ignore errors here.
Lates on closing the whole application you will find such "not realy
closed documents" and will run into trouble.
1) Is there a problem with OOo using a dual CPU system with version
2.0.2? Is there a problem with the Java interface using a dual CPU
system in the same version?
"Multi CPU systems" have a different timing then single CPU machines.
Thats a fact. So you will be able to find bugs inside OOo which will
might be never occure on a single CPU system.
On the other side OOo has some problems with threading. Most times
deadlocks occure ... but sometimes also crashes reasoned by non
synchronized code sections will occure.
That does not mean "you cant use OOo on multi CPU machines".
That means only - the chance to find bugs in OOo will be a little bit
higher then on single CPU machines :-)
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.
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.
But note: A debugger will also change the timing so it can happen that
the problem does not occure then :-)
Best Regards
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
