Python and COM: a bug?

Mark Hammond mhammond at skippinet.com.au
Wed Nov 24 17:09:06 EST 1999


> 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 :)

No luck involved - it could well be that VBScript is simply not
exploiting that COM rule - I will check.

Yes - VBScript does indeed re-query for the DISPID before each call -
ie, it does not cache the items.  I would put money on the fact that
this is your problem.

If it is the problem, you are clearly breaking the rules, and there is
a good chance that later versions of VBScript, or indeed any other COM
compatible language would also break.

I am quite confident that we do not have anything this fundamental
broken.


> 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

Or you could take another tact - something like:

ob = pythoncom.CoCreateInstance("Your.ProgID", None,
pythoncom.CLSCTX_ALL, pythoncom.IID_IDispatch)

dispid = ob.GetIDsOfNames("foo")
print dispid

dispid2 = ob.GetIDsOfNames("foo")
print dispid2

if dispid != dispid2:
  print "Eeek"

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

Python also doesnt _need_ this step - just does a better job with
byref params etc if you use it.  I doubt it will have any effect on
your problem.

Mark.





More information about the Python-list mailing list