Python COM troubles

[William Wicker]

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

>"William Wicker" <remove.me.wwicker at spectratechnologies.com> wrote in
>message news:390a2f04.149999918 at news.onlineisp.com...
>
>> 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 "makepy.py -i", and select your type library.  This
>will spit out some code, something like:
>
>gencache.EnsureModule(...)
>
>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!
>
>Mark.

Wonderful! I'm looking forward to it.