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