--- In [email protected], "swzoh" <sean...@...> wrote:
> As you may know already, CoInitialize/OleInitialize for STA creates > a hidden Message-only window, OleMainThreadWndClass. But the code > uses WaitForSingleObject, which will also block the messages to > this window. Here is a quote in the MSDN documentation. > http://msdn.microsoft.com/en-us/library/ms687032.aspx > A thread that uses a wait function with no time-out interval may cause the > system to become deadlocked. Two examples of code that indirectly creates > windows are DDE and the CoInitialize function. > So, I suggest to replace it with CoWaitForMultipleHandles. > http://msdn.microsoft.com/en-us/library/ms680732.aspx > And, the code doesn't create a message loop. I don't know if a message loop > is really necessary here, may better to have it to know if there is no > pending ones, as better call CoUninitialize/OleUninitialize after processing > all the messages. But: most scripts distributed with plugin have a com.unload, and work okay. E.g. could you confirm thant comPluginDemoScriptWord.powerpro (com.unload on line 97) comPluginDemoScriptWordDotSyntax.powerpro (com.unload on line 69) run okay on your machine? If so, whatever the problem is, it only affects scripts using certain COM objects. In any case, couldn't hurt, so I rewrote my code, substituting CoWaitForMultipleHandles for WaitForSingleObject. No difference. Added message loop. No difference. Removed extra thread, ran all calls to COM api on the main pp thread. That made problem with Com.Unload in this script go away: Local num = "12345678" Local vbs = Com.Create_Object("ScriptControl") vbs.Language = "VBScript" Local formatted = vbs.Eval("FormatNumber(&(num),0)") vbs = Com.Release(vbs) Com.Unload But then create_object failed in e.g. comPluginDemoScriptWord.powerpro, comPluginDemoScriptWordDotSyntax.powerpro. Hmmm. Maybe you could (and anyone else interested) could run all sample scripts in com distro and let me know which work, which fail.
