Hi Martin, Martin Dvořák wrote:
>> 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. > > Calling storeToURL() via OOo Basic macro works. Does it mean it is a > CLI-UNO-specific problem? I verified that the output file gets created > before the exception is thrown, so I guess that the save operation > must fail during the save process, which would indicate it is called > properly. If it was a CLI-UNO specific problem I would expect that something in transfering parameters went wrong - the only candidate would be the "Overwrite" parameter. But that obviously isn't the case here. So perhaps the problem is caused by threading issues, as your CLI-UNO transported API call does not use the OOo main thread as in case of the Basic macro or GUI code. > I've tried to pass the InteractionHandler but it does not get called. > I suppose I passed it correctly because it gets called for other > errors (like if I try to save to a location without write > permissions). This makes me think that the error happens somewhere deep inside and there is some code in OOo that - errorneously! - handles the error itself and just passes an "ERRCODE_ABORT" to the upper code layers. This is the only error code that must not be handled by the InteractionHandler, it's the same internal error code that also is created by the Handler itself after it has reported the problem. Again this could point to the mentioned problem of stacked (recursive) OLE objects. > I guess the last thing I can try is to catch the exception in OOo > process in SwXMLWriter like you say. I'll try that, it will just take > me some time because I have to prepare OOo build environment and build > it. Is there by any chance an OOo debug-build with debugging symbols > (preferrably for Visual Studio) available for download somewhere? You don't need a complete debug build to track this down. You just need some pdb files and the matching source code. This will give you the call stack and line numbers. I can collect some pdb files for you, the source code is available via cvs. I think you need both for the following modules: sw, svx, sfx2, embeddedobj, svtools, comphelper. You mentioned that you are using OOo 2.4.1. Just to avoid misunderstandings: can you give me the exact milestone number? It should be visible in the about box. If it is not visible, try hitting "CTRL-SDT". You should find something like OOHm17 or so (the number behind the "m" is important). Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "[email protected]". I use it for the OOo lists and only rarely read other mails sent to it. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
