In what way is it less safe?I'd like to emphasize again:
The real question is not about why should not use the fast mode, but about why should use the fast mode in spite of its less-safe nature.
COM Standard Library
Maybe error-prone a better term? You may start from the post of mine in this page:In what way is it less safe?
<!-- m -->http://www.autohotke...ic14560-75.html<!-- m -->
...the cause of such behaviour would be the function running in whatever thread it "interrupted." As I have tried to explain, the thread interrupted will always be the DispInterface thread, so this is not an issue. It is no more error-prone than directly calling the function.If it becomes the default and is ever used by mistake, the script might begin displaying unpredictable behavior that would be very difficult to track down and isolate.
In any case, it is not likely worth further discussion.
COM_Init(bOLE = False) / COM_Term(bOLE = False)which are wrappers around
COM_CoInitialize() / COM_CoUninitialize() ; bOLE = False COM_OleInitialize() / COM_OleUninitialize() ; bOLE = True
In case it affects your plans, what lexikos said about a callback's fast mode is correct: it shouldn't matter whether a fast-callback thread is interrupted by another thread. This is because by definition, whichever thread interrupted it will restore the proper settings for the fast-callback, which by definition are the proper settings for the thread beneath the fast-callback. This is because AutoHotkey "threads" always collapse in reverse order (i.e. no multithreading).
The advancement that Sean has made to AHK is almost beyond comprehension.
How to put this... for example, using a simple command " Invoke() ",
you can now, with AHK, directly control *any* part of any webpage being displayed in IExplorer on your machine.
as for windows scripting,
psc := ActiveXObject("MSScriptControl.ScriptControl") ; Handle to script control instance Invoke(psc, "Language=", "JScript") ; sent langauge to Java for this instance msgbox % wow := Invoke(psc, "Eval", "sh=new ActiveXObject(""WScript.Shell"");`nsh.Popup('Hello, world!', 2); sh ") ; invokes EVAL for the javascript sh=... which sets an active X object inside java to create the popup invoke(wow, "Popup","Sean, this is really, really cool!!!!") ; the same thing, using the same handle, directly for AHK! Release(psc) CoUninitialize()
or more simply ?
CoInitialize() wow := ActiveXObject("WScript.Shell") invoke(wow, "Popup","Hello world!",2) Release(wow) CoUninitialize()
but then again,
what do i know...
edit: it looks to complex so, retry:
psc := ActiveXObject("MSScriptControl.ScriptControl") Invoke(psc, "Language=", "JScript") JavaCode := "x = 'WOW' ; x" ; whatever and as much java code you want !! result := Invoke(psc, "Eval", JavaCode) Release(psc) CoUninitialize()
which my AHK errors on on the JavaCode := line (????)
so last try:
com_CoInitialize() psc := com_ActiveXObject("MSScriptControl.ScriptControl") com_Invoke(psc, "Language=", "JScript") JavaCode = ( x = "Wow" ; x ) ; whatever and as much java code you want !! result := com_Invoke(psc, "Eval", JavaCode) com_Release(psc) com_CoUninitialize() msgbox % result
Thanks for the clarification. lexicos had said that, and I think I must apologize him for that, I didn't read his post very carefully at the time. I should've read AHK's source-code myself to discuss it properly.In case it affects your plans, what lexikos said about a callback's fast mode is correct: it shouldn't matter whether a fast-callback thread is interrupted by another thread. This is because by definition, whichever thread interrupted it will restore the proper settings for the fast-callback, which by definition are the proper settings for the thread beneath the fast-callback. This is because AutoHotkey "threads" always collapse in reverse order (i.e. no multithreading).
BTW, what I'd really like to know was/is how much performance the Fast mode gains over the default Slow mode. I switched from Fast to (default) Slow at some time, not because I actually met a problem with the Fast mode, but because there had been nothing Slow mode couldn't do where Fast mode could do, so I decided to stick with the default.
Anyway, I may reconsider adding Fast mode. In the same token, I may add Cdecl too. Due to the (undocumented) stack correction procedure at the end of DllCall, I believe Cdecl is actually faster than Stdcall. Although it's undocumented, I suppose it's unlikely to change as it makes DllCall really robust against crash. May I assume it?
The perceived impact on performance probably depends mostly on how many calls are made to the callback in a short period of time. If thousands of calls are made in a few seconds, "Fast" could help a lot. If performance is important, it's probably best to benchmark it for that particular task....how much performance the Fast mode gains over the default Slow mode.
Although I can't say for sure that Cdecl is faster, in theory "yes" (due to the way DllCall is implemented). However, I suspect the difference is negligible compared to Fast vs. Slow mode.Due to the (undocumented) stack correction at the end of DllCall, I believe Cdecl is actually faster than Stdcall. Although it's undocumented, I suppose it's unlikely to change as it makes DllCall very robust against crash. May I assume it?
Example:
Code= ( sh=new ActiveXObject("WScript.Shell"); sh.Popup('Hello, world!', 2); ) COM_ScriptControl(Code, "JScript")
objWord = com_CreateObject("Word.Application")
am unable to see my way to:
objWord.Documents.Open("FILE")
or
objWord.WordBasic
com_Invoke(objWord, "Documents")
also brought no joy...
suggestions ?
Make sure you used ":=" and not "=" in your actual code. Also, I don't have Word installed, but...likely am mssing something basic, but with
objWord [color=red]=[/color] com_CreateObject("Word.Application")
objWord.Documents.Open("FILE")...should translate to...
Documents := COM_Invoke(objWord, "Documents") COM_Invoke(Documents, "Open", "FILE") COM_Release(Documents)
code was figurative, not literal..
com_CoInitialize() objWord := com_CreateObject("Word.Application") msgbox % objword msgbox % invoke(objWord,"Documents")
also tried variants of (objword, "Documents=", "Open)