Skip to content
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

pythoncom.Empty does not always generate VT_EMPTY #2149

Open
Chronial opened this issue Nov 22, 2023 · 2 comments
Open

pythoncom.Empty does not always generate VT_EMPTY #2149

Chronial opened this issue Nov 22, 2023 · 2 comments

Comments

@Chronial
Copy link

Chronial commented Nov 22, 2023

Commit f60c64d tried to fix the behavior pythoncom.Empty, so using it generates VT_EMPTY variants instead of VT_ERROR:DISP_E_PARAMNOTFOUND, for which a new pythoncom.ArgNotFound constant was introduced.

But the change missed one case:

if (obj->ob_type == &PyOleEmptyType) {
// Quick exit - use default parameter
V_VT(var) = VT_ERROR;
V_ERROR(var) = DISP_E_PARAMNOTFOUND;
return TRUE;
}

So, depending on where you use it, pythoncom.Empty is sometimes converted to VT_EMPTY and sometimes to VT_ERROR.

One example of where this happens is calling IDispatch interfaces via pywin32.

As a workaround, you can manually construct a VT_EMPTY: win32com.client.VARIANT(pythoncom.VT_EMPTY, 0)

Note that there is some code in pywin32 that relies on the current behavior, so when fixing this issue, some uses of pythoncom.Empty need to be replaced by pythoncom.ArgNotFound.

@mhammond
Copy link
Owner

Unfortunately way back in the day there were some objects which relied on the current behaviour, which might make this tricky to change without breaking code. I don't have office locally, but I'd be a lot more confident if we could assure ourselves the most of the test scripts (eg, testOffice.py) worked with current versions of those apps.

@Chronial
Copy link
Author

I thought so – that's why I didn't create a PR for this. I also didn't "encounter" this issue – I just noticed it while debugging for #2150. Unless somebody actually encounters this in the wild, it's probably simpler to just leave it as is for now.

I mostly created this Issue to document what I noticed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants