[pywin32-bugs] [ pywin32-Bugs-1202308 ] genpy.py doesn't catch all dispatchable interfaces.

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

Bugs item #1202308, was opened at 2005-05-16 00:09
Message generated for change (Settings changed) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1202308&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: com
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: George van den Driessche (gbmvdd)
Assigned to: Nobody/Anonymous (nobody)
Summary: genpy.py doesn't catch all dispatchable interfaces.

Initial Comment:
Symptoms
========

PyWin32 is installed from pywin32-204.win32-py2.3.exe.
Using win32com.client to hook events in Visual 
Studio .NET 2003, the following code fails:

-------- bugtest.py --------
from win32com.client.gencache import EnsureModule
from win32com.client import Dispatch

EnvDTE = EnsureModule( '{80CC9F66-E7D8-4DDD-
85B6-D9E6CD0E93E2}', 0, 7, 0 ) 
dte = Dispatch( 'VisualStudio.DTE' )
events = dte.Events
docEvents = events.DocumentEvents
print docEvents
-------- bugtest.py --------


The failure is as follows:

-------- traceback --------
Traceback (most recent call last):
  File "C:\dev\PyAddin\BugTest.py", line 7, in -toplevel-
    docEvents = events.DocumentEvents
  File "C:\PROGRA~1\Python23\lib\site-
packages\win32com\client\__init__.py", line 455, in 
__getattr__
    return self._ApplyTypes_(*args)
  File "C:\PROGRA~1\Python23\lib\site-
packages\win32com\client\__init__.py", line 449, in 
_ApplyTypes_
    user, resultCLSID)
  File "C:\PROGRA~1\Python23\lib\site-
packages\win32com\client\__init__.py", line 467, in 
_get_good_object_
    return _get_good_object_(obj, obUserName, 
resultCLSID)
  File "C:\PROGRA~1\Python23\lib\site-
packages\win32com\client\__init__.py", line 485, in 
_get_good_object_
    return _get_good_single_object_(obj, obUserName, 
resultCLSID)
  File "C:\PROGRA~1\Python23\lib\site-
packages\win32com\client\__init__.py", line 472, in 
_get_good_single_object_
    return Dispatch(obj, obUserName, resultCLSID, 
UnicodeToString=NeedUnicodeConversions)
  File "C:\PROGRA~1\Python23\lib\site-
packages\win32com\client\__init__.py", line 96, in 
Dispatch
    return __WrapDispatch(dispatch, userName, 
resultCLSID, typeinfo, UnicodeToString, clsctx)
  File "C:\PROGRA~1\Python23\lib\site-
packages\win32com\client\__init__.py", line 40, in 
__WrapDispatch
    return klass(dispatch)
  File "C:\PROGRA~1\Python23\lib\site-
packages\win32com\client\__init__.py", line 490, in 
__init__
    self.__dict__["_dispobj_"] = self.default_interface(oobj)
  File "C:\PROGRA~1\Python23\lib\site-
packages\win32com\client\__init__.py", line 495, in 
__getattr__
    d=self.__dict__["_dispobj_"]
KeyError: '_dispobj_'
-------- traceback --------



Cause
=====

In genpy.py, _Build_CoClassChildren enumerates the 
dispatchable interfaces of a coclass, to construct the 
list of interfaces and dispinterfaces to be generated. But 
some interfaces, though dispatchable, are not listed as 
TKIND_DISPATCH (I think these are Automation 
interfaces as opposed to Dual interfaces; this is just a 
guess, though). These interfaces then don't get included 
in the generated module. Listing the dispinterfaces for 
DocumentEvents using the OLE object viewer that 
comes with Visual Studio, versus inspecting the 
generated Python coclass for DocumentEvents, 
highlights the shortcoming.



Possible solution
=================

Applying the following patch to genpy.py solves the 
problem, allowing Visual Studio events to be hooked in 
Python:

-------- diff --------
680c680,681
<         if refAttr.typekind == 
pythoncom.TKIND_DISPATCH:
---
>         if refAttr.typekind == 
pythoncom.TKIND_DISPATCH or >            (refAttr.typekind == 
pythoncom.TKIND_INTERFACE and refAttr[11] & 
pythoncom.TYPEFLAG_FDISPATCHABLE):
-------- diff --------

I have not tried to test whether this has any adverse 
effects on other aspects of pythoncom. But the 
additional data in the generated module seems to be 
healthy.



Remarks
=======

Visual Studio .NET has a different system of event 
source objects from Office applications. Office 
applications are their own event sources, whereas 
Visual Studio .NET has several different event objects, 
for Document events, Solution events, IDE events and 
so on. I suppose this architectural difference is why this 
bug appears not to have been reported against Office 
applications too.


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

>Comment By: Mark Hammond (mhammond)
Date: 2005-06-27 22:40

Message:
Logged In: YES 
user_id=14198

Thanks - it did require one other change to get all the
tests passing, but I tracked that down.

Checking in client/genpy.py;
new revision: 1.47; previous revision: 1.46

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

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