Python COM troubles

William Wicker at
Thu Apr 27 12:34:34 EDT 2000

On Thu, 27 Apr 2000 00:46:35 GMT, "Mark Hammond"
<mhammond at> wrote:

>"William Wicker" < at> wrote in
>message news:390a2f04.149999918 at
>> Is there a way around this appearance of typelessness? There is a type
>> library, and I've run make-py successfully. I just can't see an easy
>> way into it.
>You can try running " -i", and select your type library.  This
>will spit out some code, something like:
>change this to:
>mod = gencache.EnsureModule(...)
>And you should be able to create any of the class objects in the makepy
>module - eg:
>ob = mod.TheClassName()

This works great!

There is one hitch (maybe). At some point, as I dive deeper into the
object structure (SolidWorks -> Document -> Selection ->
SelectedObject), I get a handle to an object which exists only to
super-class others. Can I pull some trick to force an unknown COM
object to use a specific class interface?

>If you search deja news, there should be lots of info about this - but
>generally relating to "Lotus Notes", which also has the same problem.
>[BTW - drop them a line, and tell them they should fix their objects :-]
>> COM dispatch methods that are documented to return SAFEARRAYS of
>> dispatch pointers fail with pythonwin v125 and 128 (the only ones I've
>> felt safe enough to try). The traceback is something like this:
>> SystemError: NULL result without error in call_object
>> >>>
>From a CVS checkin message on 11th of Feb:
>Can you believe that we have never been able to recieve arrays of
>IDispatch or IUnknown objects?!?!?
>If you tried, you would have got "SystemError: NULL result without error
>in call_object"
>:-)  This was fixed in 129.  But 129 hasnt made it public yet - I will do
>this as soon as I can log back in to starship!

Wonderful! I'm looking forward to it.

More information about the Python-list mailing list