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.
This very strange; can you check if saving via storeToURL() fails also if you call it from OOo Basic? This would allow to verify your problem what we otherwise couldn't do easily, as we don't have your application. The error code looks strange, if I decoded it correctly it could point to a problem with recursive OLE objects, but then I don't understand why saving via GUI works. So the best thing would be if your problem could be reproduced. > 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. In case you are still interested in debugging ;-), you could try to catch an IOException after the call to the SwXMLWriter. This should show you the place where it is thrown and perhaps give us a clue what the root cause may be. You could also pass an InteractionHandler instance in your MediaDescriptor that will catch the exception for you and - if we are lucky! - will give a better error message. Of course then catching the naughty exception would be easiert also as you don't need to catch all C++ exceptions in the debugger but instead of that set a breakpoint in the InteractionHandler code (module uui). Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "nospamfor...@gmx.de". I use it for the OOo lists and only rarely read other mails sent to it. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.org For additional commands, e-mail: dev-h...@openoffice.org
