-
-
Notifications
You must be signed in to change notification settings - Fork 101
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support VT_ERROR variant type and optional parameters #325
Comments
#372 is very close to your suggestion. In 1.2.0, comtypes/comtypes/automation.py Lines 220 to 229 in d1f5cd7
When implementing #486, I noticed that the Your suggestion is smarter than adding a workaround that will not cause errors when But I'm not sure what type the I think that use cases implementing com-ffi and |
I don't know whether this will be helpful for this issue, I will share how COM support in other languages has handled In PHP, There was an error that |
In ruby, " |
@junkmd I am not quite sure of the purpose of My use case is in implementing a server with optional arguments where the COM layer is providing the At that point, you wouldn't really need to worry about the This is not currently blocking me so is more of a "wouldn't it be nice" feature than something I am desperately pursuing. But if you can give me some hints (and some design guidance) then I am happy to dig back into this and see where we can get to. |
When comtypes/comtypes/automation.py Lines 571 to 574 in d1f5cd7
Lines 753 to 773 in d1f5cd7
comtypes/comtypes/_memberspec.py Lines 53 to 83 in da27aaf
comtypes/comtypes/_memberspec.py Lines 346 to 347 in da27aaf
|
Currently comtypes does not support variants with typecode 0xa (VT_ERROR). This is particularly important for servers supporting optional arguments for their methods, as an optional argument is replaced with a VT_ERROR variant with a particular error code (DISP_E_PARAMNOTFOUND).
Supporting VT_ERROR itself seems like a simple fix, as internally it is just an HRESULT, i.e. a 32-bit integer (where different parts of the bit field represent different components). As far as I can tell, the only change necessary is to modify
VARIANT.__get_value()
to have a VT_ERROR branch which duplicates the 32bit int pathway. comtypes currently has some support for creating HRESULTs from the individual components but does not have an actual class representing them, a more advanced fix would perhaps be to create an HRESULT/SCODE class that would allow the subfields to be examined.However, the most important change required is to modify the machinery used in calling the Python functions on the server class so that if an argument is supplied with DISP_E_PARAMNOTFOUND then this can be removed from the argument list actually supplied to the server. I am not completely sure how to do this so would welcome some support in implementing this, and any pitfalls that might be lurking out there for the unwary. @vasily-v-ryabov , @cfarrow do you have any thoughts?
The text was updated successfully, but these errors were encountered: