Python and COM: a bug?

[Gaetan Corneau]

Bill,

> How is this "O" written?
> Is it an ATL C++ COM object that uses IDispatchImpl? (i.e. a 
> dual interface) Is it a C++ COM object that implements IDispatch on its
own? 
> (not a dual interface)
> Is it a C++ COM object that uses OLEAUT's builtin IDispatch, but just
> doesn't use ATL? (i.e. a dual interface)
> 
> My hunch would either be a bug in Python dispid code, or your 
> COM object has a bug in some custom IDispatch code.

I'm not sure. I know it is implemented using ATL 3.0, but I don't know the
details (and since I'm a newbie in COM/C++/ATL, I can't tell the
difference). I'll ask.

[Half an hour later]  :)

OK. You may well be right about a bug in our code. I was told that the
interface is not dual and that the dispids are created dynamically the first
time a property is used. So maybe there is a problem in this code and that
the fact that I have never encountered the problem in VBScript is pure luck.
I'm still not sure, because a lot of people are using those COM objects in
dozens of VB Scripts and none have reported this kind of problem. But, hey,
I have seen much stranger occurences than that already :)

What I'll do is write a test script in Python that just tries to reproduce
the problem. If I can finally find a way to reproduce it on demand, I'll ask
our resident COM expert to trace the code to see if the problem is on our
side. If its not, maybe I'll have some more clues. One way or another, this
is one potentially very dangerous bug, for us at least, so I'll invest more
time and effort to find what the problem is.



> I also don't think we try to optimize any calls. COM doesn't 
> give one enough
> information to even bother optimizing anything other than 
> caching Name -> DispID mappings.

That's what I meant by "optimization".


> > And sometimes, I get something like that:
> > 
> > >>> Object
> > <COMObject <unknown>>
> > >>> P = Object.Parent # Parent is an attribute that is the 
> object that
> > created the current object
> > >>> P
> > <method CDispatch.Parent of CDispatch instance at c5e780>
> > >>> P = Object.get_Parent()
> > >>> P
> > <COMObject <unknown>>
> > >>>
> > 
> 
> What really helps in cases like this is to have the IDL for your
> dispatch/dual interface so that we can examine whats 
> happening much easier.
> :)

I put it in attachment.


> 
> The otherthing to note is that the <COMObject <unknown>> 
> occurs because you
> aren't wrapping the typelibrary with Python helper classes. Using
> win32com.client.EnsureModule("<typelib guid>") allows you to support a
> couple of features that are impossible to deterimine without 
> the typelib. I forget exactly what those are off the top of my head.

That's something I don't know about. My (naive) question is: why doesn't
VBScript require such a step?

 
> The answer believe it or not is, "Python is the most powerful 
> scripting > language on the planet for Win32 programming." its multi
threaded, COM
> happy, ActiveX Scripting Engine happy, and really easy to 
> talk to. VBScript
> on the other hand... Don't get me started... :) 

You certainly don't have to convince *me* of that :)
Just the fact that I can develop my Python scripts to test those COM objects
from an INTERACTIVE COMMAND LINE is a *major* feature. I can play with the
objects in a Korn Shell interactively to find the recipe, instead of the
usual edit/save/run/debug cycle.

 
Thanks a lot,
______________________________________________________
   Gaetan Corneau
   Software Developer (Quality Assurance Team)
   BaaN  Supply Chain Solutions  
   http://www.baan.com
   E-mail: Gaetan_Corneau at baan.com                  
   Tel: (418) 266-8252          
______________________________________________________
"Profanity is the one language all programmers know best"





-------------- next part --------------
A non-text attachment was scrubbed...
Name: ITKCOMAPI.idl
Type: application/octet-stream
Size: 26334 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-list/attachments/19991124/2e5a20eb/attachment.obj>