On 02/12/09 10:33, Mikhail Voitenko wrote:
Hi Martin,
The problem looks strange, the UI-source code that is used in case of
dispatch saving does not really do anything special regarding the
arguments if I remember correctly. And the arguments you send look correct.
The error you have mentioned looks to be writer error
ERRCODE_IO_RECURSIVE if I am not wrong. It seems to be related to the
internal filter logic.
The mentioned by me error code is wrong. Sorry for the typo, it is of
course writer error ERR_SWG_WRITE_ERROR.
Regards,
Mikhail.
Regards,
Mikhail.
On 02/10/09 15:03, Martin Dvořák wrote:
Hi all,
We've got a .NET application which automates OpenOffice v2.4.1 by
means of UNO CLI interface. It's been in use for some time already,
tested by many users on many different computers and proved to work
above expectations. Thousands of documents have already been created
and saved using the application, again, all without a problem, but a
few days ago we've identified special circumstances under which
XStorable.storeToURL() refuses to work, returning
unoidl.com.sun.star.task.ErrorCodeIOException with ErrCode = 461854.
XStorable.storeToURL() fails for us if a user copy/pastes some
Microsoft Equation OLE object _together_ with some surrounding text
from another _ODT_ document opened in _another_ OOo Writer instance.
Please, let me emphasize:
1. the problem does not happen if the user copies only the Microsoft
Equation object itself - he/she has to copy it together with some
surrounding text to reproduce the problem
2. the problem does not happen if the document opened in another OOo
Writer instance is for example Microsoft Word document - the problem
seem to happen only if source for copying is ODT document
3. the problem does not happen if our automated OOo Writer and OOo
Writer which is the source for copying share the same instance (same
soffice.bin process, same user data directory).
One final observation - even though XStorable.storeToURL() (and also
both other methods - store and storeAsURL) fail, it is still possible
to save without a problem for example by dispatching ".uno:SaveAs"
command or by clicking on Save or Save As in menu.
It seems to us like OOo is doing in its Save implementation something
we don't and probably should before calling XStorable.storeToURL().
What could it be? Some kind of commiting of pasted data? Some
additional MediaDescriptor properties? Currently, we pass only
FilterName=writer8 and Overwrite=true.
I'd appreciate any help on this one. We usually managed to solve most
of the problems by debugging, reading OOo source code a writing test
cases, but this one seems to be immune to everything we tried.
Thanks, Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
