[pywin32-bugs] [ pywin32-Patches-1457673 ] dispids can go wrong when using typelibs

[SourceForge.net <no...@so...>]

Patches item #1457673, was opened at 2006-03-24 22:18
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1457673&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tony Roberts (tonyroberts)
>Assigned to: Mark Hammond (mhammond)
Summary: dispids can go wrong when using typelibs

Initial Comment:
Hi,

In DesignatedWrapPolicy._wrap_, if a typelib is 
available it's used to populate _name_to_dispid_ the 
other dispid maps. However, the case of the 
methods/properties in the type library don't always 
match the python code as the midl compiler may 
produce a typelib with differently cased names to the 
original idl file.

When iterating over _public_attrs_, if a dispid 
already exists for name.lower(), it should be used 
instead of a new dispid - otherwise there's the 
posibility of having two dispids for what should be 
the same attribute. When iterating over 
_public_methods_, it's not always enough to check 
that name.lower() already exists in _name_to_dispid_ 
as the corresponding name in _dispid_to_func_ may 
have the wrong case.

cheers,
Tony.

----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2006-08-30 19:35

Message:
Logged In: YES 
user_id=14198

Sorry for the delay in looking at this.  Can you give me an
idea of when MIDL may change the case of elements?  I'm
vaguely worried about the case where an object may want to
implement 2 interfaces, each with an attribute that differs
only by case - the current behaviour would be correct in
that case.  But given VB makes no case distinction, I can't
defend that argument too far - but would like an idea of
when MIDL can screw up like that...

Thanks!

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1457673&group_id=78018