Rimon Barr schrieb:
> Hi Thomas,
>
> I noticed your new comtypes 0.4 release from Friday, which includes
> not only my patch, but a complete revamping of the safearray
> implementation. Thank you! I'm going to try it next week. With this
> new safearray support, I can likely get a particular COM piece of my
> system to work without requiring C++ or C#.
>
> In the meantime, I noticed something that I believe is a bug with how
> COM properties are mapped to object attributes... If you run the
> following code, it should display the problem:
>
> import comtypes, comtypes.client
> xl=comtypes.client.CreateObject('Excel.Application')
> xl.Visible=1 # (1)
> xl.Workbooks.Add()
> r=xl.Range['A1:B1']
> r.Value # (2)
> r.Value() # (3)
> r.Value=1 # (4)
> Basically, this is equivalent to code in the Excel test case:
>
> http://svn.python.org/projects/ctypes/trunk/comtypes/comtypes/test/test_excel.py
> Incidentally, the test case fails on my system. Perhaps it runs fine on yours.
>
This code worked for me when I had Office 97 installed, but it also fails
for me now that I have Office 2003.
> Line (1) displays how properties should work, and it does work for
> me. Assigning to Python object attribute, updates the corresponding
> COM property. Line (2) should read the contents of the range of
> cells. But, it doesn't. Instead, I get an instance of a
> bound_named_property. Line (3) works, by calling the getter. But, why
> is it mapped this way? I think it's inconsistent, and I prefer
> behaviour (1) to (3). Furthermore, the assignment in line (4) simply
> overwrites the attribute, and has no COM effect.
>
The reason that the code does not work with the newer office is the following:
In Office 97, 'Value' was a simply property of the Range object. With simple
I mean that the property did not take any arguments. (The LCID parameter is
special,
let us ignore it)
In Office 2003, 'Value' is a property that take an optional parameter named
'RangeValueDataType'.
Here is an excerpt from the generated typelib module:
COMMETHOD(['propget'], HRESULT, 'Value',
( ['in', 'optional'], VARIANT, 'RangeValueDataType' ),
( ['in', 'lcid'], c_int, 'lcid', _lcid ),
( ['retval', 'out'], POINTER(VARIANT), 'RHS' )),
The possible values for 'RangeValueDataType' are these:
# values for enumeration 'XlRangeValueDataType'
xlRangeValueDefault = 10
xlRangeValueXMLSpreadsheet = 11
xlRangeValueMSPersistXML = 12
So, in VB you can probably write something like
v = ...Range("A1:B1").Value
and VB will call the propget accessor with no arguments.
This code will probably have the same effect:
v = ...Range("A1:B1").Value(xlRangeValueDefault)
Using one of the other xlRange... constants will return
the contents as XML text (I tried this).
All this because in VB there is not really a difference between method calls
and property accesses AFAIU.
In Python/comtypes, things are different.
Long ago I decided that I wanted to access COM properties by using
indexing syntax in Python. So, to access a parameterless COM property,
one would write
v = ...Range["A1:B1"].Value
...Range["A1:B1"].Value = xyz
To access a COM property that requires parameters, one would write
v = ....Range["A1:B1"].Value[a, b, c]
The consequence, of course, is that there is no way to pass named
parameters to a property access (there is no Python syntax for that).
I guess we have to live with that.
To access a property with optional parameters, we have to use indexing
with NO parameters. Unfortunately, this is not valid Python syntax:
...Range["A1:B1"].Value[]
but this is (it will pass an empty tuple to the __getitem__ method):
...Range["A1:B1"].Value[()]
Indeed, the test_excel.py unittests work when we change the code accordingly.
The following code has the same effect, because apparently passing
'xlRangeValueDefault'
is the same as passing nothing:
...Range["A1:B1"].Value[xlRangeValueDefault]
If we can live with the above, fine. If not, ONE possibility that I see
would be that comtypes creates additional setter and getter functions for the
'Value' property, maybe called _setValue(...) and _getValue(...).
Thomas
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
comtypes-users mailing list
comtypes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/comtypes-users
