John Sisson wrote: > Hello > We have a Java gui client that manages a pool of oo documents (xp + > oo.1.1..3) and executes oo-Basic macros on them via a UNO XDispatch > interface. We also have Java robotic processes that need to do the same. > > While we can serialize attempts to execute macros in a single client (or > robotic) process, there is the chance that two robotic processes on the > same machine, sharing the same soffice.exe instance will attempt to > launch oo-basic macros on their documents simultaneously. The > documentation implies that this will cause oo-basic to fail. > > - is this so?
Yes. > - will XDispatch try to launch a basic macro on behalf of one client > while another is running on behalf of another client? No. > - is there any defense against this? Not built in ATM. There is nothing that prevents you from implanting a service into the OOo process that receives your dispatch requests and puts them into a queue. > - I imagine it would require some mutexes in the heart of the oo side > of XDispatch Not really, because the same behavior results when everything is done in one thread. While a macro is executed the Basic periodically checks the message loop, mainly because painting and dialogs still should work. Unfortunately at this step all events in the message queue are executed, so also calls through the UNO bridge. We can't halt execution here until the first dispatch is completely done because everything is done in the same thread. IMHO the culprit is that the VCL message queue doesn't allow to set a message filter (f.e. that only paint events are allowed to be executed at a certain point of time). Best regards, Mathias -- Mathias Bauer - OpenOffice.org Application Framework Project Lead Please reply to the list only, [EMAIL PROTECTED] is a spam sink. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
