Fix struct handling in makepy generated code

[the-snork]

In code generated by makepy, there was no chance to create struct instances, as using Record failed. Convenience constructors are generated now.

class TestStruct1:
	def __new__(cls, *args, **kwargs):
		return pythoncom.GetRecordFromGuids(CLSID, MajorVersion, MinorVersion, LCID, '{7A4CE6A7-7959-4E85-A3C0-B41442FF0F67}')
class TestStruct2:
	def __new__(cls, *args, **kwargs):
		return pythoncom.GetRecordFromGuids(CLSID, MajorVersion, MinorVersion, LCID, '{78F0EA07-B7CF-42EA-A251-A4C6269F76AF}')

In addition, functions using structs as out values could not be called, as the default (missing) value could not be converted to a struct instance. The change creates struct instances automatically in such cases.

	def GetOutStruct(self, ret=pythoncom.Missing):
		if ret == pythoncom.Missing:
			ret = pythoncom.GetRecordFromGuids(CLSID, MajorVersion, MinorVersion, LCID, IID('{7A4CE6A7-7959-4E85-A3C0-B41442FF0F67}'))
		return self._ApplyTypes_(1610743852, 1, (24, 0), ((16420, 2),), 'GetOutStruct', None,ret
			)

[the-snork]

@mhammond - that looks like a flaky test, as I did not change anything in that area.

can s/b please verify?

[the-snork]

unfortunately one more issue regarding same guids in different typelibs --- meh

[the-snork]

activating again;

a problem exists for VT_RECORD without VT_BYREF; most probably that will not work through IDispatch -- at least I tried enough and don't want to continue on that

we will change our server to VT_BYREF...

[Avasam]

The datetime failure is indeed a flaky test (ref: #2203)

[mhammond]

Hey @geppi, do you have any thoughts on this pr?

[geppi]

Sorry for the delay, I'm in the mountains over the long Easter weekend and can take a detailed look into this earliest on tuesday. My first thought is that I should probably just write some documentation about the functionality we recently introduced for COM Records with PR #2437.
However, I'm not sure where this documentation should live and what format would be required?

[Avasam]

Looks like in-code comments parsed by a tool called AutoDuck is used to generate helpfiles. Those helpfiles are then decompiled to extract the HTML and are hosted as a GitHub page:

In #2432 I'm trying to restore shipping the helpfiles (by adding them to the build commands without building pywin32 twice) to users for local no-internet documentation.
In #2577 I added a link to a mirror of AutoDuck's download which included documentation and examples on how to use it. Hopefully that should help with its usage.

[the-snork]

@Avasam I wonder why the tests still fail, though the encoding changes are reverted

[geppi]

The problem with this PR is that it doesn't create proper Python classes:

>>> struct_1 = TestStruct1()
>>> struct_2 = TestStruct2()
>>> type(struct_1) == type(struct_2)
    True

Ooops!

I've opened PR #2578 to add documentation for the COM Record support including the recent improvement of PR #2437.
I hope this does help to clarify the current implementation and what's possible with COM Records.

[the-snork]

@geppi - unfortunately, the mechanism that you describe does not work with makepy generated code (see the unit test part in this pr)

meaning: this was the smallest possible change in my opinion; of course, a larger change is possible where proper Python records are used.

[geppi]

I'm afraid I don't understand the problem.

In code generated by makepy, there was no chance to create struct instances, as using Record failed.

Could you please provide an example what fails?

Also if you follow the recipe to create subclasses of pythoncom.com_record for the convenience constructors, you should be good to go.

[the-snork]

We are using code generated by makepy, so actually the generated code shall contain all necessary constructors (in my opinion).

Have a look at the IDL changes and the tests within this PR.

What actually does not work (without modification in build.py) is:

coclass.GetOutStruct()

The default argument results in a TypeError "Only com_record objects can be used as records", as it is a special marker and no record instance.

The other problem we experienced is not that easy to reproduce right now with that minimal test.

Consider this:

interf = module.IPyCOMTest(coclass)
interf.GetOutStruct(win32com.client.Record('TestStruct1', interf))

In this scenario, a file is generated by gencache (which is actually not necessary, since everything should be already present in the file that has been generated with makepy). In our production environment, it happened that this file could not be read afterwards and we ended up with an import error. As said, not reproducible within this small test right now.

[the-snork]

I debugged that in our scenario:

win32com.client.Record
-->
gencache.EnsureDispatch(object) does not run into the if clause.

In the end, no Python file is generated and the import fails.

My temp directory contains the following files in gen_py\3.13:
__init__.py
dicts.dat (10 bytes long)

Nothing more.

@geppi --- how to proceed?

[geppi]

I would suggest to fix the code that creates the classes for the records as a first step.

[mhammond]

Formally marking as "request changes" as per the existing comments.

[geppi]

Can we close this now that PR #2708 got merged?

[the-snork]

Can we close this now that PR #2708 got merged?

I have to say sorry. That is our guilty conscience speaking.

Unfortunately, we postponed this sprint by sprint, as always other issues were more important and we had a temporary solution for us (business context).

So yes, I will close this now and come back to this issue and recheck when we decide to update to a newer version of pywin32.

Thank you for your support!