Protocol and/or types generation for type libraries.

[dmwyatt]

It seems like comtypes has enough information to generate Protocols and/or other type information when generating Python code for type libraries.

I'm not a win32 or really much of a C programmer, but I've been muddling my way through using some win32 stuff and I find myself writing a lot of code that it seems like comtypes should be in a position to take care of for me.

I realize this is a really old library and it might just be in maintenance mode, but I thought it'd throw this out there.

[kdschlosser]

comtypes only generates code for information that it is able to read from the type libraries. I have found that not all of the information that might be needed is included in a type library.

A great example of such a case is mmdeviceapi which is the type library for Windows Core Audio. It doesn't contain even close to everything needed to have a fill implementation of Windows Core Audio in python. I know this because I have personally checked the type library and I ended up hand writing the 36,417 lines of code needed.

[junkmd]

@dmwyatt @kdschlosser

comtypes only generates code for information that it is able to read from the type libraries. I have found that not all of the information that might be needed is included in a type library.

I agreed that.

I think something like Protocol should not be defined in the runtime code, but in the type stub file as I plan to do in #327. The additional functionality I planned in #327 to add will also be implemented to generate type stubs based on type libraries, so there is "missing information not to be covered".

If you are interested in the work related to #327, I would be happy to have you as a contributor.

I recognize that this question has been resolved.

If the issue remains, please re-open.