AutoHotkey Community

v1.0.96.00

New features:

• ComObjQuery: Queries a COM object for an interface or service.
• ComObjFlags: Retrieves or changes flags which control a COM wrapper object's behaviour.
• ComObjCreate allows non-dispatch objects to be created if an interface identifier (IID) is given.
• COM arrays support for-loops and the Clone() method.
• ListVars shows the inner variant type and value of each COM wrapper object, in addition to the wrapper's address.

Changes:

• When a literal integer or variable containing both a numeric string and cached binary integer is assigned to a field of an object, an integer is stored instead of a string. This particularly benefits scripts calling COM methods which accept integers but not strings, or have different behaviour depending on the type of value.
• NULL values are now allowed with ComObjParameter for the VT_UNKNOWN and VT_DISPATCH types.
• Improved support for Common Language Runtime (.NET) objects via COM.
• FileRecycle should now warn before deleting a file which is too large to recycle.
• When a SafeArray created with ComObjArray is assigned to an element of another SafeArray, a separate copy is created. This prevents the script from crashing due to a second attempt at "destroying" the array. ComObjFlags allows this behaviour to be avoided.

Fixes:

• Assigning to a COM array of VT_DISPATCH or VT_UNKNOWN crashed the script.
• Break and Continue were tolerated outside of loops in some cases.
• Standalone carriage-return (`r) was not correctly interpreted as end-of-line.
• MouseMove miscalculated negative coordinates with the Input and Event send modes.
• Selecting Edit This Script from the tray menu or using the Edit command crashed the script (broken by v1.0.95).
• Error dialogs pointed at irrelevant lines of code in some cases.

Downloads (etc.)

Thank you for the updates - I really need to learn how to use QueryInterface/Service at some point.

Very nice - is there a proper way to iterate multidimensional arrays?

Nested loops. I think there's no one "correct" order to iterate through a multi-dimensional array; it depends on what the array contains. Furthermore, I think that they're far from typical.

QueryService isn't widely used, unlike QueryInterface. For either to be useful, you also need to learn how COM interfaces/virtual function tables work. The first ComObjQuery example and (new) last DllCall example show how to call into them, but don't provide much explanation.

I have a couple questions about ComObjQuery:

• Documentation wrote:
  In either case, the return value is either zero or a pointer to the requested interface. Generally this pointer must be released when the script is finished with it.
  Is there a reason you chose to return a pointer, as opposed to a wrapped Com Object?
  
• In regards to the previous question, if I wrap the pointer with ComObj(9,ptr,1), would I still have to Release the object? If not, wouldn't that be the resolution to Sean's concern about leaking Com Objects? Or am I missing something here?

The first and probably only thing you (the hypothetical advanced user) would need to do with the wrapper object is retrieve the pointer from within it. If you can figure out how to call interface functions correctly, you are presumably capable of releasing the pointer when it is appropriate - or in the less efficient case, wrapping it to be released automatically. If the method you are calling returns an interface pointer, you'd need to handle it the same way. Likewise for ComObjUnwrap in AutoHotkey_L, but not in Sean's private build.
No.
I feel that it's not my place to answer that question.

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 raw 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.

ComObjValue is the exception, since it interprets the wrapper object's contents as a 64-bit integer regardless of the actual type. It can be equated to variant.llVal. By contrast, ComObjUnwrap can be equated to ComObjQuery(ComObject, IID_IDispatch). Built-in SafeArray support made ComObjValue redundant for my original purpose, which was to copy the value from an object created by ComObjParameter into a script-built SafeArray (of parameters to pass to the CLR). The improvements to CLR support in v1.0.96.00 make it further redundant.

Thank you for your explanation - I will have to study it some more.

If that is your position, I would put up the argument that the default behavior for the flags should be 1 (Take ownership of an IUnknown), as opposed to 0 (AddRef is called automatically). That way the average user could ComObjEnwrap(ptr) without having to add the extra params or release the object (either of which might likely be forgotten). However, if wrapping & unwrapping objects should is more for the hypothetical advanced user, perhaps the syntax should be ObjEnwrap & ObjUnwrap?

In any case, since my knowledge is quite limited here, so I trust your position. Again, thanks fro the updates .