SAP R/3 automation with win32com
aleaxit at yahoo.com
Tue Dec 5 10:26:34 CET 2000
<obou at my-deja.com> wrote in message news:90i6n6$hg0$1 at nnrp1.deja.com...
> I don't know VB at all and don't really know how to translate VB
> functions calls to Python function calls. Especially when using COM.
> There are some strange differences. In my example, there are in VB
> function calls that takes 3 parameters where in Python I have to put
> only 2 parameters in the brackets and get the third as a return value.
> The salesOrd.DimAs function calls are such cases. In VB the return
> value is written as a third parameter and the function has no return
> Is there a way to identify which parameter have to stay in the brackets
> and which ones will be sent as return value?
COM parameters are defined as [in], [out], [out,retval], or [in,out]
(there are also other attributes, but these are the ones that matter
here). The [out,retval], if present at all, is only the last one.
In VB, a parameter [out,retval] appears as a return value, all others
appear as actual parameters to the function call (and not as returns).
In Python, parameters [in] and [in,out] appear as actual parameters
to the function call; parameters [out], [out,retval], and [in,out]
appear as return values (once you've run makepy on the type library
to let Python know what is what -- otherwise, [out] and [in,out]
can be troublesome). Note that [in,out] is BOTH an actual parameter
(for the 'in' part) AND a return value (for the 'out' part).
[out] and [in,out] are not all that common in well-designed COM
(Automation) type-libraries, but, they do happen at times.
The VB Object Browser does not clearly display the attributes of
the parameters. *However*, another precious tool is called "OLE
View" and should be also part of VB's higher editions (and I
think oleview.exe is also one of the tools you can download for
free as part of Microsoft's "Platform SDK"). THAT one, OleView,
lets you display any type-library in terms of IDL, the Interface
Definition Language, which includes the [in], [out], etc,
notations. It's a very good tool for exploring COM stuff. Of
course, a component's docs SHOULD include the non-trifling
details of what parameters are input ones, which are output
ones, etc, etc, but, sometimes, such little crucial things
drop by the wayside... and OleView can save your life then!-)
Alternatively, if you'd rather read Python than IDL, look at
the source-file that makepy.py generates for you when you 'hook
up' to a type-library. It's placed in win32com\genpy, and its
filename is the GUID of the library; in the Python classes it
builds to correspond to each COM interface, it also clearly
separates and distinguishes between input and output parameters
of each method.
More information about the Python-list