#155 Incorrect IDispatch::Invoke property from CDispatch.__setattr__

[Fredrik Orderud]

It appears to be something wrong with the _GetDescInvokeType function in dynamic.py [line 116]. For some reason it always returns the varkind field from the VARDESC struct returned by ITypeComp::Bind (if available). For dispatch-invokable names, this value is always 3 (VAR_DISPATCH).

A return value 3 from _GetDescInvokeType is treated as DISPATCH_METHOD | DISPATCH_PROPERTYGET when passed as input to IDispatch::Invoke. This is incorrect for property put calls to IDispatch::Invoke that expects an INVOKE_PROPERTYPUT argument.

A patch that fixes the problem for me is attached. It reproduces the existing behavior of returning 3 on property get. Please feel free to adapt it to your preferences and apply it to the pywin32 code base.

Associated bug report: https://sourceforge.net/p/pywin32/bugs/709/

[Mark Hammond]

I need to understand this a little better (and I've lost much of the context of this code).

entry.desc[3] is the wVarFlags element of a VARDESC whereas [4] is the varkind (note also that we can now use those attribute names - we aren't limited to indexes). The wVarFlags is documented as being a VARFLAGS enumeration - https://msdn.microsoft.com/en-us/library/windows/desktop/ms221426%28v=vs.85%29.aspx - but VAR_DISPATCH isn't one of those flags - that's a flag on the varkind. So while I could imagine a patch similar to this that still examines entry.desc[4] (or entry.desc.varkind), it's not clear to me that thanging to wVarFlags is the right thing to do.

Can you explain how you came to this change?

[Fredrik Orderud]

Sorry for specifying incorrect entry.desc index in the patch. The varkind member of course maps to entry.desc[4]. My fault. Updated patch attached.

I fully agree that it would be more intuitive to use attribute names when accessing entry.desc, but unfortunately that is not possible. The reason for this is that the PyVARDESC object is flattened into a tuple in DispatchItem._AddVar_ [build.py line 251].

[Mark Hammond]

Revision aeed1c9d4bf9 and will be in the next pywin32 - thanks!

[Fredrik Orderud]

Thanks a lot Mark! Any idea when PyWin32 r220 will be available?

[Mark Hammond]

Either a few days, or about 20 days (vacation:)