AutoHotkey Community

It is currently May 27th, 2012, 12:59 am

All times are UTC [ DST ]




Post new topic Reply to topic  [ 55 posts ]  Go to page 1, 2, 3, 4  Next
Author Message
PostPosted: December 29th, 2009, 5:07 pm 
Offline
User avatar

Joined: May 5th, 2007, 7:24 pm
Posts: 1240
Location: Seville, Spain
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 :P

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]


Last edited by fincs on January 2nd, 2010, 12:24 pm, edited 2 times in total.

Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: December 30th, 2009, 1:00 am 
Offline

Joined: February 12th, 2007, 7:54 am
Posts: 2462
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.


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: December 30th, 2009, 2:07 am 
Offline

Joined: October 17th, 2006, 4:15 pm
Posts: 7502
Location: Australia
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;


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: December 30th, 2009, 12:15 pm 
Offline
User avatar

Joined: May 5th, 2007, 7:24 pm
Posts: 1240
Location: Seville, Spain
Lexikos wrote:
Maybe better to use OleInitialize/Uninitialize vs CoInitialize/Uninitialize, as COM.ahk does.

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
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]


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: December 30th, 2009, 1:17 pm 
Offline

Joined: December 4th, 2006, 10:35 am
Posts: 561
Location: Galil, Israel
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


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: December 30th, 2009, 1:25 pm 
Offline

Joined: October 17th, 2006, 4:15 pm
Posts: 7502
Location: Australia
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?


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: December 30th, 2009, 1:28 pm 
Offline
User avatar

Joined: May 5th, 2007, 7:24 pm
Posts: 1240
Location: Seville, Spain
Yes please :D

_________________
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]


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: December 30th, 2009, 2:51 pm 
Offline

Joined: February 12th, 2007, 7:54 am
Posts: 2462
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.


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: December 30th, 2009, 2:57 pm 
Offline

Joined: February 12th, 2007, 7:54 am
Posts: 2462
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.


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: December 30th, 2009, 5:03 pm 
Offline
User avatar

Joined: May 5th, 2007, 7:24 pm
Posts: 1240
Location: Seville, Spain
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
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]


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: December 30th, 2009, 9:03 pm 
Offline

Joined: December 4th, 2006, 10:35 am
Posts: 561
Location: Galil, Israel
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


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: December 31st, 2009, 1:01 am 
Offline

Joined: February 12th, 2007, 7:54 am
Posts: 2462
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.


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: December 31st, 2009, 3:23 am 
Offline

Joined: February 12th, 2007, 7:54 am
Posts: 2462
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


Report this post
Top
 Profile  
Reply with quote  
 Post subject:
PostPosted: December 31st, 2009, 12:55 pm 
Offline
User avatar

Joined: May 5th, 2007, 7:24 pm
Posts: 1240
Location: Seville, Spain
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
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]


Report this post
Top
 Profile  
Reply with quote  
 Post subject: Thrilled
PostPosted: December 31st, 2009, 9:32 pm 
Offline

Joined: February 17th, 2008, 5:01 pm
Posts: 303
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? :D


Report this post
Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 55 posts ]  Go to page 1, 2, 3, 4  Next

All times are UTC [ DST ]


Who is online

Users browsing this forum: No registered users and 9 guests


You can post new topics in this forum
You can reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Powered by phpBB® Forum Software © phpBB Group