[python-win32] VB COM tip: watch out for mixed case

Wed Apr 9 18:31:50 EDT 2003

This is a multi-part message in MIME format.

------=_NextPart_000_000C_01C2FE83.54D6F660
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

(KUDOS) I am new to Python and am writing my first COM-aware Python script
that does some "real work" (i.e. generating some revenue for my firm).  I
want to say how *easy* it is to do COM in Python thanks to many of you out
there. I am impressed with the functionality of modules such as gencache and
they save me a lot of effort. For example, I changed one of the interfaces
in a Visual Basic COM server, and Python picked it up and automatically
upgraded the MinorVersion at run time without my lifting a finger.  Bravo.

Now, a note to others dealing with VB6 COM DLLs: I had a truly annoying bug
and after three hours of trial and error I discovered why. It lies in the
way VB maintains upper and lower case in public methods and properties.

As you know, VB and COM are case-insensitive, whereas Python is
case-sensitive.  However, (and this is helpful when you are aware it is
happening) VB "auto-changes" case on your Property and Sub and Funtion
names.  This doesn't always happen consistently with Class names:  you can
change the case of Class names in the .cls file, but at compile time it uses
the case of the class names in the .vbp file. (Or, the other way around,
particularly if you check files in and out using Visual SourceSafe 5).
However, for interfaces that are Implemented (meaning, you have "Private Sub
Interface_Method" methods in your "Multiuse" CoClasses), the case of the
Method name is not automatically made consistent.

Example:  I had properties named "PathName" and "Pathname" (inconsistently)
which did not get cannonized to either form. Module win32com created
wrappers with whatever case got compiled in to the VB DLL. I had difficulty
accessing those methods from Python. Then, truly irksome, when I returned to
VB and tried to manually make these names consistently cased (that is,
rename them all to "Pathname"), VB sometimes unexpectedly them back to
"PathName" when compiling. Curses!

Summary: if your win32 COM Python script accesses some methods and
properties in a VB DLL but balks at others, confirm that (1) the DLL's
wrapper script in the gen_py folder, (2) your VB source code, and (3) the
compiled VB DLL are using names with consistent case.

Dudley McFadden
David Ford Consulting Engineers, Inc.
Sacramento, California, US

------=_NextPart_000_000C_01C2FE83.54D6F660
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DWindows-1252">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.6249.1">
<TITLE>VB COM tip: watch out for mixed case</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

(KUDOS) I am new to Python and am writing my first =
COM-aware Python script that does some &quot;real work&quot; (i.e. =
generating some revenue for my firm).&nbsp; I want to say how *easy* it =
is to do COM in Python thanks to many of you out there. I am impressed =
with the functionality of modules such as gencache and they save me a =
lot of effort. For example, I changed one of the interfaces in a Visual =
Basic COM server, and Python picked it up and automatically upgraded the =
MinorVersion at run time without my lifting a finger.&nbsp; =
Bravo.

Now, a note to others dealing with VB6 COM DLLs: I had =
a truly annoying bug and after three hours of trial and error I =
discovered why. It lies in the way VB maintains upper and lower case in =
public methods and properties.

As you know, VB and COM are case-insensitive, whereas =
Python is case-sensitive.&nbsp; However, (and this is helpful when you =
are aware it is happening) VB &quot;auto-changes&quot; case on your =
Property and Sub and Funtion names.&nbsp; This doesn't always happen =
consistently with Class names:&nbsp; you can change the case of Class =
names in the .cls file, but at compile time it uses the case of the =
class names in the .vbp file. (Or, the other way around, particularly if =
you check files in and out using Visual SourceSafe 5).&nbsp; However, =
for interfaces that are Implemented (meaning, you have &quot;Private Sub =
Interface_Method&quot; methods in your &quot;Multiuse&quot; CoClasses), =
the case of the Method name is not automatically made consistent.&nbsp; =

Example:&nbsp; I had properties named =
&quot;PathName&quot; and &quot;Pathname&quot; (inconsistently) which did =
not get cannonized to either form. Module win32com created wrappers with =
whatever case got compiled in to the VB DLL. I had difficulty accessing =
those methods from Python. Then, truly irksome, when I returned to VB =
and tried to manually make these names consistently cased (that is, =
rename them all to &quot;Pathname&quot;), VB sometimes unexpectedly them =
back to &quot;PathName&quot; when compiling. Curses!

<P><FONT SIZE=3D2>Summary: if your win32 COM Python script accesses some =
methods and properties in a VB DLL but balks at others, confirm that (1) =
the DLL's wrapper script in the gen_py folder, (2) your VB source code, =
and (3) the compiled VB DLL are using names with consistent =
case.</FONT></P>

<P><FONT SIZE=3D2>Dudley McFadden</FONT>

<BR><FONT SIZE=3D2>David Ford Consulting Engineers, Inc.</FONT>

<BR><FONT SIZE=3D2>Sacramento, California, US</FONT>
</P>

</BODY>
</HTML>
------=_NextPart_000_000C_01C2FE83.54D6F660--