Jump to content

Sky Slate Blueberry Blackcurrant Watermelon Strawberry Orange Banana Apple Emerald Chocolate
Photo

Sean's ComUtils [AHK_L] (diminished)


  • Please log in to reply
30 replies to this topic
jethrow
  • Moderators
  • 2854 posts
  • Last active: May 17 2017 01:57 AM
  • Joined: 24 May 2009
This thread is inactive. Please refer to Acc Library [AHK_L]

NOTE:
- The Query Library isn't necessary any more since the introduction of ComObjQuery().
- The Atl Library isn't necessary any more since the introduction of ActiveX controls via the Gui command.

If you still wanted to download the full ComUtils Libraries Package (NOT RECOMMENDED) here is the previous post:

>>>Download ComUtils Libraries<<<
(Includes the Acc, Atl, & Query Libraries for AutoHotkey_L)

Sean has given me permission to modify and release these libraries (see here). I modified the libraries so that they no longer leak Com Objects. However, keep in mind, these are Sean's Function Libraries - I only modified some of the parameters in the ComObjEnwrap function calls (or released the raw interface pointer), and changed the ComObjUnwrap calls to ComObjValue (thanks for pointing this out fincs). Also keep in mind, these libraries are provided "AS-IS" - Sean is not releasing them, and they are not really my functions to modify & update any more than I already have. That being said, they are 99.6% Sean's coding, so enjoy :D .



sinkfaze
  • Moderators
  • 6367 posts
  • Last active: Nov 30 2018 08:50 PM
  • Joined: 18 Mar 2008
+1

tank
  • Administrators
  • 4345 posts
  • AutoHotkey Foundation
  • Last active: May 02 2019 09:16 PM
  • Joined: 21 Dec 2007
+1
Never lose.
WIN or LEARN.

Sean
  • Members
  • 2462 posts
  • Last active: Feb 07 2012 04:00 AM
  • Joined: 12 Feb 2007
I think the best solution is that expose QueryInterface/Service as a built-in function, and, integrate Atl_AxCreateContainer into AHK's GUI. Then, only ACC functions will be remained.

tank
  • Administrators
  • 4345 posts
  • AutoHotkey Foundation
  • Last active: May 02 2019 09:16 PM
  • Joined: 21 Dec 2007
Yes as long as that doesn't leak as well :)
any how thes Should be built in but building acc into the control commands would be good as well but not sure of the logistics
Never lose.
WIN or LEARN.

pajenn
  • Members
  • 391 posts
  • Last active: Feb 06 2015 07:57 AM
  • Joined: 07 Feb 2009

Sean has written a series of Libraries to be used with the Native COM support of AutoHotkey_L called ComUtils (Acc,Atl,Query).


The Acc library in the linked zip file is missing a lot of functions that were previously present in older versions of ACC.ahk and that were necessary for the ShellDesktop() function and similar operations. For example, acc_Query, acc_Name, acc_Selection , ... Also Acc_Term is no longer included. Why were they dropped and is there a newer ShellDesktop function or another method to get info about Desktop icons/files that doesn't need those functions?

Hardware: fast laptop with SSD
Software: Win 7 Home Premium 64-bit, android for phone and tablet


a4u
  • Guests
  • Last active:
  • Joined: --

The Acc library in the linked zip file is missing a lot of functions ...

You're a couple steps behind. AHK_L has object support, so the following are essentially the same:
; AHK Basic:
acc_Name(pacc, idChild)

; AHK_L:
pacc.accName(idChild)

... is there a newer ShellDesktop function ...

Sean wrote one here for COM_L, and here it would be with the Acc library:
ShellDesktop() 
{ 
   DetectHiddenWindows, On 
   ControlGet, hWnd, hWnd,, SysListView321, ahk_class Progman 
   Global   l,t,w,h  
   If   oAcc := Acc_ObjectFromWindow(hWnd) 
   Loop, % Acc_Children(oAcc, oAcc.accChildCount, varChildren) 
   If   NumGet(varChildren,(A_Index-1)*16)=3 && idChild:=NumGet(varChildren,A_Index*16-8) 
   sResult   .="[" A_Index "]`n" 
      . "Name:`t"      oAcc.accName(idChild) "`n" 
      . "(l,t,r,b):`t" oAcc.accLocation(ComObjParameter(0x4003,&l:=0), ComObjParameter(0x4003,&t:=0), ComObjParameter(0x4003,&w:=0), ComObjParameter(0x4003,&h:=0), idChild) 
      . "(" (l:=NumGet(l,0,"int")) "," (t:=NumGet(t,0,"int")) "," l+NumGet(w) "," t+NumGet(h) ")`n"
   Return   sResult 
}
NOTE - per the thread subject, the Acc library hasn't been released yet. It's use is not recommended yet.

pajenn
  • Members
  • 391 posts
  • Last active: Feb 06 2015 07:57 AM
  • Joined: 07 Feb 2009

The Acc library in the linked zip file is missing a lot of functions ...

You're a couple steps behind. AHK_L has object support, so the following are essentially the same:
; AHK Basic:
acc_Name(pacc, idChild)

; AHK_L:
pacc.accName(idChild)


Thank you. I'll look into those changes.

Hardware: fast laptop with SSD
Software: Win 7 Home Premium 64-bit, android for phone and tablet


jethrow
  • Moderators
  • 2854 posts
  • Last active: May 17 2017 01:57 AM
  • Joined: 24 May 2009
I updated the original post with a download of a modified version of ComUtils that should be safe to use.

2 Cents:

... resolve for me why the logic Lexikos applied to stubbornly add AddRef to ComObjUnwrap even after a warning was not applied to ComObjValue.

My object was to not expose AddRef/Release. Telling from the past experience, forcing an user to call Release himself was not good. Once he was told to call Release (in some case), he tended to call it blindly to any variable (of returned value). An user usually translates some VBS/JS codes, but as there is no counter part for Release in VBS/JS he mostly has no clue in which situation he should apply Release.

IMO, ComObjEnwrap/ComObjUnwrap should have never been exposed. How many users will use those features? Anyway, I warned in the corresponding thread: I highly discourage to call those functions.

So, don't tell the user how to deal with a necessary evil as he might get it wrong? In that case what chance does he have of doing it right? When I introduced Object(address) and someone used it merely to pass objects to functions, I saw that as a failure on my part as author of the documentation.

It's a little different in this case, as the average user shouldn't have any reason to consider calling it, or any need to call it.

However, it may be that I haven't adequately explained my motivation for opposing Sean's implementation of ComObjEnwrap/Unwrap. I firmly believe that any
COM interface pointer made accessible to the script should be treated according to the COM reference counting rules. Anyone dealing with external COM code via DllCall will need to learn them eventually, and inconsistencies only make this more difficult. These functions are intended for advanced users, not VBScript converts.

In my understanding (which is very limited :( ), the situation comes down to how the Com Object Reference count should be handled. Personally, I agree with both Lexikos & Sean. I don't think that handling the pointer interfaces should be completely hidden from the user - especially if the user is returning an interface pointer from a DllCall, as Lexikos pointed out. However, I believe the ComObj functions are designed more for the average user - and therefore should NOT deal directly with the interface pointer. For instance, ComObjQuery returns an interface pointer, which would need released. IMO, this function should either return a wrapped Com Object, or the function should not have a ComObj prefix (perhaps just ObjQuery?). Same thing with ComObj(E|U)nWrap - I think they should refrain from using the ComObj prefix as they are designed for the more advanced user. Then the less advanced users will refrain from using these functions (kind of like DllCall is now).

Anyways, as I'm not developing AHK, that's just my input, for what it's worth.

fincs
  • Moderators
  • 1662 posts
  • Last active:
  • Joined: 05 May 2007

IMO, this function should either return a wrapped Com Object

No. ComObjQuery() is intended to be used to query for non-IDispatch-compatible COM interfaces, so wrapping the return object is pointless.

EDIT: All instances of ComObjUnwrap() in your modified ComUtils should be changed to ComObjValue() in order to avoid the AddRef.

Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006
Please tell me why the average user should need to use enwrap/unwrap/query.

These functions specifically relate to COM objects (internally, instances of ComObject), so using only Obj as the prefix would be inappropriate.

To begin with, the "polymorphic" behaviour of ComObjActive (i.e. ComObjEnwrap/Unwrap) is error-prone. I think it was mostly aimed at increasing user-friendliness, but didn't necessarily succeed. I'm strongly considering removing that behaviour in v2 and implementing the following:
[*:3hqpki85]ComObjActive(CLSID) as it is now.
[*:3hqpki85]ComObject([vt,]value[,flags]) instead of ComObj(), ComObjParameter(), ComObjEnwrap() or anything else the user came up with.
[*:3hqpki85]&ComObject as equivalent to the old ComObjUnwrap.It may help to separate the advanced functions from the more commonly used ones, in the documentation.

(I've made several caffeine-fuelled edits to this post since posting it.)

tank
  • Administrators
  • 4345 posts
  • AutoHotkey Foundation
  • Last active: May 02 2019 09:16 PM
  • Joined: 21 Dec 2007
I can think of dozens of uses for query I have pointed else where. Not limited to getting the window object from an element or browser which overcomes a certain security problem in older versions of IE
Never lose.
WIN or LEARN.

Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006
tank, do you expect an average user to work out how to call method x of non-IDispatch interface y? That's the only way that interface y can be used. Do you expect an average user to figure out by themself which service to query for, or to even think of querying for a service in the first place? If you're writing that code for them, it is your responsibility to write it correctly; they'll probably just copy and paste.

tank
  • Administrators
  • 4345 posts
  • AutoHotkey Foundation
  • Last active: May 02 2019 09:16 PM
  • Joined: 21 Dec 2007
Agreed but a similar arguement can be made about COM in general. Or dllcalls numget/put sendmessage,registercallback etc. Why are you so opposed. I suppose because support for such within the user community. Anyway we have Seans example of doing it with a wraped function. But I ask you is it so much to let us have a built in way? When digging thru the recent executed lines trying to trace your code its easier with built in function instead of even more obscure calls in a wrapped function
Never lose.
WIN or LEARN.

Lexikos
  • Administrators
  • 9844 posts
  • AutoHotkey Foundation
  • Last active:
  • Joined: 17 Oct 2006

Agreed but a similar arguement can be made about COM in general.

Dispatchable objects and vtable calls are on two entirely different levels of difficulty.

Or dllcalls numget/put sendmessage,registercallback etc.

Again, these have higher difficulty level than simple COM scripts such as one would convert from VBScript, though not typically as high as vtable calls.

Why are you so opposed.

Opposed to what?

But I ask you is it so much to let us have a built in way?

To do what?

Maybe you missed the introduction of ComObjQuery.