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.
Login
Register
FAQ
Search
.
