Problem with nested dispatches in build 201
OLD project page for the Python extensions for Windows
Brought to you by:
mhammond
We have an application which exposes an automation
object Application. One member of Application is Zip
which is another automation object which has a
property Recursive of type BOOL. In a Python script we
have:
Application.Zip.Recursive = 1
With build 201 we get a COM error saying that we have
a wrong number of parameters.
The same was working fine with build 200
Logged In: YES
user_id=14198
Could you please provide a sample or some way for me to
repro this?
Logged In: YES
user_id=464497
I attach a strip down version of the odl file describing
Application and Zip objects.
I debugged the code using versions 203 and 200. The
problem seems to be in CDispatch.__setattr__
if self.__LazyMap__(attr):
# Check the "general" property map.
if self._olerepr_.propMap.has_key(attr):
entry = self._olerepr_.propMap[attr]
invoke_type = _GetDescInvokeType ...
self._oleobj_.Invoke(entry.dispid, 0, invoke_type, 0, value)
return
invoke_type has the value of 3 in version 203 instead of 4
(pythoncom.INVOKE_PROPERTYPUT) in version 200, which
works.
Logged In: YES
user_id=464497
After a long while, I am reopening this issue, as I am
trying to upgrade from pythonwin 200 to pythonwin207 for
Python 2.3. The problem still exists.
I attach the file Problem.odl, in which I define two
interfaces, IApplicationAuto and IZipAuto. The interface
IApplicationAuto has a member Zip, which returns an object
implementing the IZipAuto interface. When setting, from a
script, Application.Zip.NoDirectoryEntries = 0 I am getting
the following error:
Source line: Application.Zip.NoDirectoryEntries = 0
Traceback...
c:\python\lib\site-packages\win32com\client\dynamic.py
line 528 in __setattr__
self._oleobj_.Invoke(entry.dispid, 0, invoke_type, 0, value)
COM Error: Invalid number of parameters (0x8002000e...)
The Application automation class is implemented in MFC
using
BEGIN_DISPATCH_MAP(CApplicationAuto, CHHCmdTarget)
//{{AFX_DISPATCH_MAP(CApplicationAuto)
DISP_PROPERTY_EX(CApplicationAuto, "SerialNumber",
GetSerialNumber, SetNotSupported, VT_BSTR)
DISP_PROPERTY_EX(CApplicationAuto, "Zip", GetZip,
SetZip, VT_DISPATCH)
...
END_DISPATCH_MAP()
Logged In: YES
user_id=464497
It seems the problem is with properties listed under the
properties: section in the ODL. If the property is defined
like this:
[id(5)] BOOL NoDirectoryEntries;
we get an error (wrong number of parameters)
but if it is defined like this:
[propget, id(5)] HRESULT NoDirectoryEntries([out, retval]
VARIANT_BOOL* result);
[propput, id(5)] HRESULT NoDirectoryEntries([in]
VARIANT_BOOL setting);
it works OK. I think the problem is in _GetDescInvokeType,
which when called from CDispatch.__setattr__ returns
pythoncom.INVOKE_PROPERTYGET | pythoncom.INVOKE_FUNC
instead of pythoncom.INVOKE_PROPERTYPUT which was returned
in versio 200 which was working.
Logged In: YES
user_id=14198
It appears you forgot to attach the .odl file - I did try to
reproduce it here, but got stuck. I applied the following
patch to the pywin32 distribution:
Index: com/TestSources/PyCOMTest/PyCOMTest.idl
RCS file:
/cvsroot/pywin32/pywin32/com/TestSources/PyCOMTest/PyCOMTest.idl,v
retrieving revision 1.12
diff -u -r1.12 PyCOMTest.idl
--- com/TestSources/PyCOMTest/PyCOMTest.idl 13 Feb 2006
01:23:49 -0000 1.12
+++ com/TestSources/PyCOMTest/PyCOMTest.idl 27 Feb 2006
10:11:06 -0000
@@ -225,6 +225,7 @@
[propput] HRESULT IntProp([in] int val);
[propget] HRESULT CurrencyProp([out, retval]
CY* retval);
[propput] HRESULT CurrencyProp([in] CY val);
+ BOOL BoolProp;
};
// Define a new class to test how Python handles
derived interfaces!
(with a few different variations) but MSVC6 fails to compile
the .idl file. Would it be possible for you to try and
reproduce the problem in this test COM object? If it gets
added to the test suite, it will get fixed :)
You will need the source pywin32 distro (or CVS would be
even better!) and open and build
pywin32\com\TestSources\PyCOMTest\PyCOMTest.dsp in MSVC6.
If you can give me an IDL patch that builds (ignoring the
existing warnings), I should be able to manage the rest (or
if you do manage to add an implementation for a new
property, win32com\test\testPyComTest.py is the driver)
Thanks!