 |
AutoHotkey Community
Let's help each other out
|
| View previous topic :: View next topic |
| Author |
Message |
fincs
Joined: 05 May 2007
Posts: 1160
Location: Seville, Spain
|
 Posted: Tue Dec 29, 2009 4:07 pm Post subject: Experimental COM support for AutoHotkeyU/_L |
 |
|
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
Get SciTE4AutoHotkey v3.0.00 (Release Candidate)
[My project list]
Last edited by fincs on Sat Jan 02, 2010 11:24 am; edited 2 times in total |
|
| Back to top |
|
 |
Sean
Joined: 12 Feb 2007
Posts: 2462
|
| Posted: Wed Dec 30, 2009 12:00 am Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
Lexikos
Joined: 17 Oct 2006
Posts: 7295
Location: Australia
|
| Posted: Wed Dec 30, 2009 1:07 am Post subject: |
|
|
Looks good, though I haven't tested it.
| fincs wrote: | | Remove all instances of CoUninitialize() in the script_autoit.cpp file. |
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.
| Quote: | // Working buffer for int->string conversions.
TCHAR numbuf[MAX_NUMBER_SIZE]; |
Since built-in functions commonly have a need for this, ExpandExpression passes a buffer of sufficient size via aResultToken:
| Code: | | LPTSTR numbuf = aResultToken.buf; |
|
|
| Back to top |
|
|
fincs
Joined: 05 May 2007
Posts: 1160
Location: Seville, Spain
|
| Posted: Wed Dec 30, 2009 11:15 am Post subject: |
|
|
Ok, I've already changed it.
| Lexikos wrote: | | fincs wrote: | | Remove all instances of CoUninitialize() in the script_autoit.cpp file. |
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. |
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.
| Lexikos wrote: | | Code: | // Working buffer for int->string conversions.
TCHAR numbuf[MAX_NUMBER_SIZE]; |
Since built-in functions commonly have a need for this, ExpandExpression passes a buffer of sufficient size via aResultToken:
| Code: | | LPTSTR numbuf = aResultToken.buf; |
|
Ah, I forgot about that :p (I saw it in functions like SubStr())
| Sean wrote: | | 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. |
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
Get SciTE4AutoHotkey v3.0.00 (Release Candidate)
[My project list] |
|
| Back to top |
|
|
Joy2DWorld
Joined: 04 Dec 2006
Posts: 561
Location: Galil, Israel
|
| Posted: Wed Dec 30, 2009 12:17 pm Post subject: |
|
|
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 |
|
| Back to top |
|
|
Lexikos
Joined: 17 Oct 2006
Posts: 7295
Location: Australia
|
| Posted: Wed Dec 30, 2009 12:25 pm Post subject: |
|
|
| Joy2DWorld wrote: | | ... doesn't the OLE init lock all subsequent COMs to single thread model ? |
So does CoInitialize. Why would that be a problem for AutoHotkey?
| fincs wrote: | | Maybe I should start a new thread? |
Should I split the topic instead? |
|
| Back to top |
|
|
fincs
Joined: 05 May 2007
Posts: 1160
Location: Seville, Spain
|
|
| Back to top |
|
|
Sean
Joined: 12 Feb 2007
Posts: 2462
|
| Posted: Wed Dec 30, 2009 1:51 pm Post subject: |
|
|
| fincs wrote: | | 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? |
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. |
|
| Back to top |
|
|
Sean
Joined: 12 Feb 2007
Posts: 2462
|
| Posted: Wed Dec 30, 2009 1:57 pm Post subject: |
|
|
| Joy2DWorld wrote: | | Sean would know better than I, but doesn't the OLE init lock all subsequent COMs to single thread model ? |
Both OleInitialize and CoInitialize establish single-thread apartment, however, OleInitialize loads a little more library needed to manage especially Cilpboard/Drag-n-Drop etc. |
|
| Back to top |
|
|
fincs
Joined: 05 May 2007
Posts: 1160
Location: Seville, Spain
|
| Posted: Wed Dec 30, 2009 4:03 pm Post subject: |
|
|
| Sean wrote: | | 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. |
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
Get SciTE4AutoHotkey v3.0.00 (Release Candidate)
[My project list] |
|
| Back to top |
|
|
Joy2DWorld
Joined: 04 Dec 2006
Posts: 561
Location: Galil, Israel
|
| Posted: Wed Dec 30, 2009 8:03 pm Post subject: |
|
|
| Lexikos wrote: | | Joy2DWorld wrote: | | ... doesn't the OLE init lock all subsequent COMs to single thread model ? |
So does CoInitialize. Why would that be a problem for AutoHotkey?
|
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 |
|
| Back to top |
|
|
Sean
Joined: 12 Feb 2007
Posts: 2462
|
| Posted: Thu Dec 31, 2009 12:01 am Post subject: |
|
|
| fincs wrote: | | If not then give me an example of how you would do it |
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. |
|
| Back to top |
|
|
Sean
Joined: 12 Feb 2007
Posts: 2462
|
| Posted: Thu Dec 31, 2009 2:23 am Post subject: |
|
|
| Joy2DWorld wrote: | | 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. |
You may take a look here:
http://www.autohotkey.com/forum/topic22923-397.html |
|
| Back to top |
|
|
fincs
Joined: 05 May 2007
Posts: 1160
Location: Seville, Spain
|
| Posted: Thu Dec 31, 2009 11:55 am Post subject: |
|
|
| Sean wrote: | 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). |
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...
| Sean wrote: |
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. |
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
Get SciTE4AutoHotkey v3.0.00 (Release Candidate)
[My project list] |
|
| Back to top |
|
|
JoeSchmoe
Joined: 17 Feb 2008
Posts: 303
|
| Posted: Thu Dec 31, 2009 8:32 pm Post subject: Thrilled |
|
|
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?  |
|
| Back to top |
|
|
|
|
You can post new topics in this forum
You can reply to topics in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Register
Profile
Log in to check your private messages
Log in
