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: [email protected] For additional commands, e-mail: [email protected]
