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

[Mark Hammond]

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
>