[python-win32] Bypassing gen_py, accessing makepy-generated class directly

[Jim Bell]

Thanks everyone for the info.

Generating with -o is fine, needs no fixups that I can tell.

I was confusing bypassing the gen_py mechanism (which is possible) with 
bypassing the entire COM registration (which isn't possible). makepy 
presents everything pythonishly, but ultimately it still needs to be 
COM, which comes from the COM mechanisms, with types and interfaces, and 
private ties to the DLL. Going directly to the DLL with ctypes doesn't 
stand a chance.

So that old thread is spot-on: win32com.client.GetObject() is it.


On 2013-12-17 5:16 AM, Mark Hammond wrote:
> oops 2 :) - where I said "-i" I meant "-o"
>
> Mark
>
> On 17/12/2013 10:13 PM, Mark Hammond wrote:
>> [oops - resend with cc to list]
>>
>> It should be fine if the typelib itself doesn't register, so long as the
>> objects themselves are registered.  You should still run makepy over the
>> typelib normally (so the generated file is still in the normal
>> directory), but generating it to its own file should still work ok too -
>> CoClassBaseClass is defined in win32com.client(.__init__.py) - it's
>> possible the generation with -i doesn't import this and will need a
>> manual fixup)
>>
>>    Then you can do something like:
>>
>> ob = win32com.client.Dispatch("The.ClassId")
>>
>> at which point 'ob' is going to be a "dumb dispatch" object as it can't
>> find the typelib.  Then, if you ran makepy "normally" you could do:
>>
>> kls = win32com.client.gencache.GetClassForProgID("The.ClassId")
>> # wrap the dumb object in the generated class
>> ob = kls(ob)
>>
>> or with makepy -i, something like:
>>
>> import somelib
>> # wrap the dumb object in the generated class
>> ob = somelib.TheClassName(ob)
>>
>> Hope that answers the question!
>>
>> Mark
>>
>>
>> On 17/12/2013 11:15 AM, Jim Bell wrote:
>>> I have a somelib.dll/somelib.tlb that doesn't register, and I want to
>>> bypass the gen_py mechanism to package it better. I run makepy -o
>>> somelib.py.
>>>
>>> I should be able to instantiate it more directly, not through
>>> client.Dispatch(), shouldn't I? Manually wrap it analogously to the
>>> server?
>>>
>>> I see somelib.SomeApplication inherits CoClassBaseClass, and that wants
>>> to construct with some sort of object, but what?
>>>
>>> # Like this
>>> import somelib
>>> # Not win32com.client.Dispatch(...)
>>> app = somelib.SomeApplication(someMagicHere)
>>> # Above raises 'Class not registered' if passed None.
>>>
>>> This thread seemed to be in the ballpark, but I'm still missing
>>> something...
>>> https://mail.python.org/pipermail/python-win32/2009-December/009860.html 
>>>
>>>
>>> And I know that, conceptually, something actually needs to reference 
>>> the
>>> .dll somewhere, and I don't see that happening. (And that sure seems
>>> like ctypes domain, too.)
>>>
>>> Where's my disconnect?
>>>
>>> _______________________________________________
>>> python-win32 mailing list
>>> python-win32 at python.org
>>> https://mail.python.org/mailman/listinfo/python-win32
>>
>
>