AutoHotkey Community

Last week I was bored and decided to read documents about COM (specifically IDispatch). As a side effect I ended up tinkering with AutoHotkey_L/U trying to get COM support in

Update: There's now a updated version.
Here's a link to an archive containing a precompiled binary, some testscripts, the source and the documentation:
http://www.autohotkey.net/~fincs/ComObject.7z
The size increase in AutoHotkeyU.exe is around 2 kB

Also, 404th post ;p

_________________
fincs
Highly recommended: AutoHotkey_L (see why) (all my code snippets require it)
Formal request to polyethene - I support the unity of the AutoHotkey community
Get SciTE4AutoHotkey v3.0.00 (Release Candidate)
[My project list]

Why didn't you post it in AutoHotkeyU thread and leave the link to it instead here? Then, Lexikos and/or jackieku may review and try to incorporate it with appropriate modifications into AutoHotkey_L/AutoHotkeyU. No I haven't tested it but I looked over the source file.

Looks good, though I haven't tested it.
Although it probably wouldn't have any effect other than keep the COM libraries loaded permanently, I don't like the thought of calling CoInitialize repeatedly without balancing by calling CoUninitialize. If you try to unload COM on exit, you would need to call CoUninitialize once for each call to CoInitialize (i.e. once for each call to ComObject(), FileGetShortcut or FileCreateShortcut). Perhaps you should remove all existing calls to CoInitialize, call it when the program loads and call CoUninitialize on exit.

Maybe better to use OleInitialize/Uninitialize vs CoInitialize/Uninitialize, as COM.ahk does.
Since built-in functions commonly have a need for this, ExpandExpression passes a buffer of sufficient size via aResultToken:

Ok, I've already changed it.

The documentation also says the calls must be balanced. Anyway, what if a script doesn't actually use COM? Memory would be wasted, so I prefer untouching script_autoit.cpp and only calling OleInitialize() the first time the script calls ComObject() so the COM library would stay resident.

Ah, I forgot about that :p (I saw it in functions like SubStr())

Well, this is COM-related so I thought that posting it in the AutoHotkeyU/_L threads would be spamming. Maybe I should start a new thread?

_________________
fincs
Highly recommended: AutoHotkey_L (see why) (all my code snippets require it)
Formal request to polyethene - I support the unity of the AutoHotkey community
Get SciTE4AutoHotkey v3.0.00 (Release Candidate)
[My project list]

Sean would know better than I, but doesn't the OLE init lock all subsequent COMs to single thread model ?

ie., have always thought OLE init restricted to when actually necessary.

but then again, am sure no expert on that.

_________________
Joyce Jamce

So does CoInitialize. Why would that be a problem for AutoHotkey?
Should I split the topic instead?

Yes please

_________________
fincs
Highly recommended: AutoHotkey_L (see why) (all my code snippets require it)
Formal request to polyethene - I support the unity of the AutoHotkey community
Get SciTE4AutoHotkey v3.0.00 (Release Candidate)
[My project list]

I have no problem with that, however, I thought it would be better to attract also the attention of other developers, as, no offense but your COM code was almost broken in my view. Well, I could see where you adopted the code from, however, that's not enough with AHK. And, although it's totally a personal matter, I don't like the implementation this way. I usually prefer JScript way/syntax over VBScript way/syntax, but when it comes to COM Automation, I can't resist being attracted toward the VBScript approach. Well, may be a natural consequence as it was implemented by VB developers.

Both OleInitialize and CoInitialize establish single-thread apartment, however, OleInitialize loads a little more library needed to manage especially Cilpboard/Drag-n-Drop etc.

I don't understand. Are you referring to the object syntax (which was designed by Lexikos) or the ComObject class? If not then give me an example of how you would do it
Anyway I'm fairly new at COM so I might make mistakes often.

_________________
fincs
Highly recommended: AutoHotkey_L (see why) (all my code snippets require it)
Formal request to polyethene - I support the unity of the AutoHotkey community
Get SciTE4AutoHotkey v3.0.00 (Release Candidate)
[My project list]

not my expertise, but understanding was the OLE init'd Com threads locked to single thread but CoInitializeEx init'd not.

as for AHK, addition of simple dllcallthreaded function (even if in forked builds) is problematic with single thread mandated COM. (ie, when COM 'built in as function'). Also even script based thread to COM call would be impaired.

_________________
Joyce Jamce

What I had in mind had been summarized in this thread:
http://www.autohotkey.com/forum/topic52271.html

I stopped posting further as I felt it was a waste of time since, at the time, that was not really a problem of AHK itself, merely that of the external script COM.ahk. So, I decided just to let it go as AHK will face the problem itself sooner or later if it wants a native COM Automation support. The time came faster than I expected. In summary, I wanted the support for a new type, Variant, in native manner or through Object or with whatever, and ideally the native COM support uses/allows it exclusively whenever possible, e.g. for the return value of Invoke etc (:to be clear, this part is more about my personal preference. I don't mean that there is no other way around). And/or at least introduce new flags to distinguish raw integer/float (:VT_I4/VT_R8).

BTW, I'd like to only mention that using VT_I8 will be problematic, even subtle one, as it will work sometimes but not always. Some objects expect strictly VT_I4(/VT_I2) and passing VT_I8 to them will fail, often silently, no coercion will happen. Better minimize (or even completely abandon) the usage of VT_I8 and use VT_I4 (and VT_BSTR) exclusively instead. I believe other problems in your current code will be surfaced quickly.

You may take a look here:
http://www.autohotkey.com/forum/topic22923-397.html

I now see your point. Currently my code tries its best at marshalling the parameters. However there is a problematic type: SYM_OPERAND. It can be treated both as a string and as a binary integer as Lexikos said in that thread. I currently treat it exclusively as a string. The problem is that literal integers are also of type SYM_OPERAND (!), so I should also check for them...

I actually had code to detect if an __int64 value could be passed as VT_I4 but decided against it for performance. Now you've made me reconsider...

_________________
fincs
Highly recommended: AutoHotkey_L (see why) (all my code snippets require it)
Formal request to polyethene - I support the unity of the AutoHotkey community
Get SciTE4AutoHotkey v3.0.00 (Release Candidate)
[My project list]

I'm thrilled to see people working on this... Thanks for your work, fincs, and to the doubtlessly very helpful feedback from everyone in this thread (which I won't even try to read since it's so over my head ). ... While I'm posting, thanks for your awesome contribution of SciTE4AHK. Intertia has kept me primarily with PSPad and Notepad++ (for it's AHK_L debugging support with DBGP), but I'm looking forward to checking out v2.1.

I'm surprised that Tank hasn't weighed in yet... He's a big fan of COM, right?