pywin32-bugs — Automated tracker notifications (not for bug reports!)

[pywin32-bugs] [ pywin32-Bugs-3531456 ] RegQueryValueEx on empty multistring returns non-empty list

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

Bugs item #3531456, was opened at 2012-06-01 15:56
Message generated for change (Comment added) made by rupole
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3531456&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: win32
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: William Sadkin (wsadkin)
Assigned to: Nobody/Anonymous (nobody)
Summary: RegQueryValueEx on empty multistring returns non-empty list

Initial Comment:
Somewhere along the line, win32api.RegQueryValueEx stopped returning [] for an empty multistring, and started returning [''], which is a very different and broken.  Unfortunately, I'm not sure how far back this has been broken; I've only recently undertaken converting all our code from python 2.3.5 and pywin32 204 to python 2.7.3 and pywin32 217.  It worked in that earlier incarnation, but as of the latest versions, this no longer functions properly.

I've attached a trivial python script that clearly demonstrates the problem.

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

>Comment By: Roger Upole (rupole)
Date: 2012-06-04 15:52

Message:
This has been fixed, also added a test for this in test_win32api.py.

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

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

[pywin32-bugs] [ pywin32-Bugs-3525912 ] InvokeTypes error using win32com v2.17

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

Bugs item #3525912, was opened at 2012-05-11 10:37
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3525912&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: win32
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Mike Fox (mike_fox)
Assigned to: Nobody/Anonymous (nobody)
Summary: InvokeTypes error using win32com v2.17

Initial Comment:
I think we have found a bug in win32com 2.17.  We are using it with Python 2.7.2.  We are calling a proprietary DLL named PATE, which provides APIs to a database named Enovia from the Dassault corporation.  The Enovia client is linked to a CAD program named CATIA so we must conjure objects of both CATIA and Enovia as shown in the code snippet below.  The strApplicationID is a password administered by my company and has nothing to do with the PATE DLL itself.  Rather, PATE should pass the strApplicationID to the Enovia server, which should authenticate the session.
====================================================================
import win32com.client, win32com.client.gencache, win32com.client.selecttlb
strPATECLSID = '{9BB3CB79-7098-47D0-83A2-F8F56D236DC8}'
strPATEclassCLSID = '{9A1F3C8E-46B7-4CFA-A820-E4256ECD53B5}'

self.objCATIA = win32com.client.GetActiveObject('CATIA.Application')
win32com.client.gencache.EnsureModule(strPATECLSID, 0, 0, 0)
self.objBase= win32com.client.gencache.GetClassForCLSID(strPATEclassCLSID)
self.__objPATECOM = self.objBase(self.objCATIA)
strApplicationID = <secret> 
try:
    self.__objPATECOM.SetApplicationID(strApplicationID)
except (pywintypes.com_error), _e:
    print "Connection error: %s" %(_e)
    return False
====================================================================
When we use win32com 2.16 the code above works fine but when we use win32com 2.17 it throws the error message shown below.

   File testKBE_PATECAKE.py, line 367 in ConnectToENOVIA
     self.__objPATECOM.SetApplicationID(strApplicationID)
   File "C:\Python27\lib\site-packages\win32com\gen_py\9BB3CB79 -7098-47D0-83A2-F8
F56D236DC8x0x0x0.py", line 457 in SetApplicationID
     return self._oleobj_.InvokeTypes(1610940417, LCID, 1, (24, 0), ((16396, 1),)
, iAID
   File "C:\Python27\lib\site-packages\win32com\client\dynamic.py", line 516 in 
__getattr__
     raise AttributeError("%s.%s" % (self._username_, attr))
   AttributeEror: CATIA.Application.InvokeTypes

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

>Comment By: Mark Hammond (mhammond)
Date: 2012-06-02 19:48

Message:
What I really don't understand still is why it works in an earlier version,
when best I can tell, the types of all the objects and that code block are
all the same...

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

Comment By: Mike Fox (mike_fox)
Date: 2012-06-01 16:30

Message:
I put some print statements into the DispatchBaseClass.__init__ method as
you suggested.  That method checks whether the oobj == None, then checks
whether oobj is an instance of DispatchBaseClass. Both tests fail so the
QueryInterface method is never called and the raw oobj is put into the
DispatchBaseClass.__dict__

When I printed the raw oobj (that was input to the __init__ method) it
printed 
    <PyIDispatch at 0x000000002371440 with obj at 0x000000000048E258>

If I change the 6th line of the __init__ method from
    elif isinstance(oobj, DispatchBaseClass):
to
    else:
the code runs without throwing any errors.  What does that mean?

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

Comment By: Mark Hammond (mhammond)
Date: 2012-05-30 16:42

Message:
It looks like the genpy idea I had was wrong - the objects are the same in
both examples.

What should happen is that the line:

  self.__objPATECOM = self.objBase(self.objCATIA)

end up calling DispatchBaseClass.__init__ which is in
win32com\client\__init__.py.  What *should* happen, and appears to be
happening in 216 is it should enter the branch:

		elif isinstance(oobj, DispatchBaseClass):
			try:
				oobj = oobj._oleobj_.QueryInterface(self.CLSID,
pythoncom.IID_IDispatch) # Must be a valid COM instance
			except pythoncom.com_error, details:
				import winerror
				# Some stupid objects fail here, even tho it is _already_
IDispatch!!??
				# Eg, Lotus notes.
				# So just let it use the existing object if E_NOINTERFACE
				if details.hresult != winerror.E_NOINTERFACE:
					raise
				oobj = oobj._oleobj_

In the working case it just does the QI so oobj ends up as a "raw"
IDispatch.  In your failing 217 scenario, it seems to be either not hitting
that first condition at all, or enters that block but hits the "except
pythoncom.com_error" block.

You might want to instrument that code with prints to try and (a) confirm
I'm correct in the working case and (b) work out how it fails in the
failing case (ie, whether the 'if' statement simply isn't entered at all or
it hits the exception).

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

Comment By: Mike Fox (mike_fox)
Date: 2012-05-30 11:11

Message:
Sorry for the delay.  I added print statements after lines 4, 6, and 7 (in
the code shown in my original post).  With version 2.16
(pywin32-216.win-amd64-py2.7) I get the following correct output:
    self.objCATIA= <COMObject CATIA.Application>
    self.objBase=
win32com.gen_py.9BB3CB79-7098-47D0-83A2-F8F56D236DC8x0x0x0.PATECOM
    self.__objPATECOM= <win32com.gen_py.CATIA V5
BOEPATEAutomationInterfaces Object 
                       Library.PATECOM instance at 0x44540104>

Then I ran the same sript with version 2.17 (pywin32-217.win-amd64-py2.7)
and got the following:
    self.objCATIA= <COMObject CATIA.Application>
    self.objBase=
win32com.gen_py.9BB3CB79-7098-47D0-83A2-F8F56D236DC8x0x0x0.PATECOM
    self.__objPATECOM= <win32com.gen_py.CATIA V5
BOEPATEAutomationInterfaces Object 
                       Library.PATECOM instance at 0x44540104>
    Traceback (moste recent call last):
    File testKBE_PATECAKE.py, line 370 in ConnectToENOVIA
       self.__objPATECOM.SetApplicationID(strApplicationID)
   File "C:\Python27\lib\site-packages\win32com\gen_py\9BB3CB79
-7098-47D0-83A2-F8
           F56D236DC8x0x0x0.py", line 457 in SetApplicationID
       return self._oleobj_.InvokeTypes(1610940417, LCID, 1, (24, 0),
((16396, 1),), iAID
   File "C:\Python27\lib\site-packages\win32com\client\dynamic.py", line
516 in __getattr__
    raise AttributeError("%s.%s" % (self._username_, attr))
AttributeEror: CATIA.Application.InvokeTypes
    

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

Comment By: Mark Hammond (mhammond)
Date: 2012-05-15 17:34

Message:
Can you please modify your test code to add:

print self.objCATIA

After creating it, and tell me what it prints in both the failing and
working cases?

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

Comment By: Mike Fox (mike_fox)
Date: 2012-05-15 17:32

Message:
To Mark Hammond:
I don't think the problem is caused by a pre-existing wrapper in the gen_py
folder as you suggested in your comment.  When I uninstalled version 2.17
of pywin32 and installed version 2.16 on the same PC (with the contents of
the gen_py folder unchanged) I was able to call the SetApplicationID method
without it throwing an error.

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

Comment By: Mark Hammond (mhammond)
Date: 2012-05-11 19:51

Message:
I suspect the problem is that previously you have makepy support generated
for the 'CATIA.Application' object which should make things work.  The
problem is that when you do:

self.__objPATECOM = self.objBase(self.objCATIA)

The DispatchBaseClass.__init__ function in win32com\client\__init__.py
checks to see if the object is itself a makepy generated object and will
work correctly if it is.

Even though, this really is a bug as we should handle that situation.  A
fix would probably be to change the line in DispatchBaseClass.__init__
from:

		elif isinstance(oobj, DispatchBaseClass):
to
                elif hasattr(oobj, "_oleobj_"):


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

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

[pywin32-bugs] [ pywin32-Bugs-3525912 ] InvokeTypes error using win32com v2.17

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

Bugs item #3525912, was opened at 2012-05-11 10:37
Message generated for change (Comment added) made by mike_fox
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3525912&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: win32
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Mike Fox (mike_fox)
Assigned to: Nobody/Anonymous (nobody)
Summary: InvokeTypes error using win32com v2.17

Initial Comment:
I think we have found a bug in win32com 2.17.  We are using it with Python 2.7.2.  We are calling a proprietary DLL named PATE, which provides APIs to a database named Enovia from the Dassault corporation.  The Enovia client is linked to a CAD program named CATIA so we must conjure objects of both CATIA and Enovia as shown in the code snippet below.  The strApplicationID is a password administered by my company and has nothing to do with the PATE DLL itself.  Rather, PATE should pass the strApplicationID to the Enovia server, which should authenticate the session.
====================================================================
import win32com.client, win32com.client.gencache, win32com.client.selecttlb
strPATECLSID = '{9BB3CB79-7098-47D0-83A2-F8F56D236DC8}'
strPATEclassCLSID = '{9A1F3C8E-46B7-4CFA-A820-E4256ECD53B5}'

self.objCATIA = win32com.client.GetActiveObject('CATIA.Application')
win32com.client.gencache.EnsureModule(strPATECLSID, 0, 0, 0)
self.objBase= win32com.client.gencache.GetClassForCLSID(strPATEclassCLSID)
self.__objPATECOM = self.objBase(self.objCATIA)
strApplicationID = <secret> 
try:
    self.__objPATECOM.SetApplicationID(strApplicationID)
except (pywintypes.com_error), _e:
    print "Connection error: %s" %(_e)
    return False
====================================================================
When we use win32com 2.16 the code above works fine but when we use win32com 2.17 it throws the error message shown below.

   File testKBE_PATECAKE.py, line 367 in ConnectToENOVIA
     self.__objPATECOM.SetApplicationID(strApplicationID)
   File "C:\Python27\lib\site-packages\win32com\gen_py\9BB3CB79 -7098-47D0-83A2-F8
F56D236DC8x0x0x0.py", line 457 in SetApplicationID
     return self._oleobj_.InvokeTypes(1610940417, LCID, 1, (24, 0), ((16396, 1),)
, iAID
   File "C:\Python27\lib\site-packages\win32com\client\dynamic.py", line 516 in 
__getattr__
     raise AttributeError("%s.%s" % (self._username_, attr))
   AttributeEror: CATIA.Application.InvokeTypes

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

>Comment By: Mike Fox (mike_fox)
Date: 2012-06-01 16:30

Message:
I put some print statements into the DispatchBaseClass.__init__ method as
you suggested.  That method checks whether the oobj == None, then checks
whether oobj is an instance of DispatchBaseClass. Both tests fail so the
QueryInterface method is never called and the raw oobj is put into the
DispatchBaseClass.__dict__

When I printed the raw oobj (that was input to the __init__ method) it
printed 
    <PyIDispatch at 0x000000002371440 with obj at 0x000000000048E258>

If I change the 6th line of the __init__ method from
    elif isinstance(oobj, DispatchBaseClass):
to
    else:
the code runs without throwing any errors.  What does that mean?

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

Comment By: Mark Hammond (mhammond)
Date: 2012-05-30 16:42

Message:
It looks like the genpy idea I had was wrong - the objects are the same in
both examples.

What should happen is that the line:

  self.__objPATECOM = self.objBase(self.objCATIA)

end up calling DispatchBaseClass.__init__ which is in
win32com\client\__init__.py.  What *should* happen, and appears to be
happening in 216 is it should enter the branch:

		elif isinstance(oobj, DispatchBaseClass):
			try:
				oobj = oobj._oleobj_.QueryInterface(self.CLSID,
pythoncom.IID_IDispatch) # Must be a valid COM instance
			except pythoncom.com_error, details:
				import winerror
				# Some stupid objects fail here, even tho it is _already_
IDispatch!!??
				# Eg, Lotus notes.
				# So just let it use the existing object if E_NOINTERFACE
				if details.hresult != winerror.E_NOINTERFACE:
					raise
				oobj = oobj._oleobj_

In the working case it just does the QI so oobj ends up as a "raw"
IDispatch.  In your failing 217 scenario, it seems to be either not hitting
that first condition at all, or enters that block but hits the "except
pythoncom.com_error" block.

You might want to instrument that code with prints to try and (a) confirm
I'm correct in the working case and (b) work out how it fails in the
failing case (ie, whether the 'if' statement simply isn't entered at all or
it hits the exception).

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

Comment By: Mike Fox (mike_fox)
Date: 2012-05-30 11:11

Message:
Sorry for the delay.  I added print statements after lines 4, 6, and 7 (in
the code shown in my original post).  With version 2.16
(pywin32-216.win-amd64-py2.7) I get the following correct output:
    self.objCATIA= <COMObject CATIA.Application>
    self.objBase=
win32com.gen_py.9BB3CB79-7098-47D0-83A2-F8F56D236DC8x0x0x0.PATECOM
    self.__objPATECOM= <win32com.gen_py.CATIA V5
BOEPATEAutomationInterfaces Object 
                       Library.PATECOM instance at 0x44540104>

Then I ran the same sript with version 2.17 (pywin32-217.win-amd64-py2.7)
and got the following:
    self.objCATIA= <COMObject CATIA.Application>
    self.objBase=
win32com.gen_py.9BB3CB79-7098-47D0-83A2-F8F56D236DC8x0x0x0.PATECOM
    self.__objPATECOM= <win32com.gen_py.CATIA V5
BOEPATEAutomationInterfaces Object 
                       Library.PATECOM instance at 0x44540104>
    Traceback (moste recent call last):
    File testKBE_PATECAKE.py, line 370 in ConnectToENOVIA
       self.__objPATECOM.SetApplicationID(strApplicationID)
   File "C:\Python27\lib\site-packages\win32com\gen_py\9BB3CB79
-7098-47D0-83A2-F8
           F56D236DC8x0x0x0.py", line 457 in SetApplicationID
       return self._oleobj_.InvokeTypes(1610940417, LCID, 1, (24, 0),
((16396, 1),), iAID
   File "C:\Python27\lib\site-packages\win32com\client\dynamic.py", line
516 in __getattr__
    raise AttributeError("%s.%s" % (self._username_, attr))
AttributeEror: CATIA.Application.InvokeTypes
    

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

Comment By: Mark Hammond (mhammond)
Date: 2012-05-15 17:34

Message:
Can you please modify your test code to add:

print self.objCATIA

After creating it, and tell me what it prints in both the failing and
working cases?

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

Comment By: Mike Fox (mike_fox)
Date: 2012-05-15 17:32

Message:
To Mark Hammond:
I don't think the problem is caused by a pre-existing wrapper in the gen_py
folder as you suggested in your comment.  When I uninstalled version 2.17
of pywin32 and installed version 2.16 on the same PC (with the contents of
the gen_py folder unchanged) I was able to call the SetApplicationID method
without it throwing an error.

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

Comment By: Mark Hammond (mhammond)
Date: 2012-05-11 19:51

Message:
I suspect the problem is that previously you have makepy support generated
for the 'CATIA.Application' object which should make things work.  The
problem is that when you do:

self.__objPATECOM = self.objBase(self.objCATIA)

The DispatchBaseClass.__init__ function in win32com\client\__init__.py
checks to see if the object is itself a makepy generated object and will
work correctly if it is.

Even though, this really is a bug as we should handle that situation.  A
fix would probably be to change the line in DispatchBaseClass.__init__
from:

		elif isinstance(oobj, DispatchBaseClass):
to
                elif hasattr(oobj, "_oleobj_"):


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

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

[pywin32-bugs] [ pywin32-Bugs-3531456 ] RegQueryValueEx on empty multistring returns non-empty list

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

Bugs item #3531456, was opened at 2012-06-01 15:56
Message generated for change (Tracker Item Submitted) made by wsadkin
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3531456&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: win32
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: William Sadkin (wsadkin)
Assigned to: Nobody/Anonymous (nobody)
Summary: RegQueryValueEx on empty multistring returns non-empty list

Initial Comment:
Somewhere along the line, win32api.RegQueryValueEx stopped returning [] for an empty multistring, and started returning [''], which is a very different and broken.  Unfortunately, I'm not sure how far back this has been broken; I've only recently undertaken converting all our code from python 2.3.5 and pywin32 204 to python 2.7.3 and pywin32 217.  It worked in that earlier incarnation, but as of the latest versions, this no longer functions properly.

I've attached a trivial python script that clearly demonstrates the problem.

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

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

[pywin32-bugs] [ pywin32-Bugs-3525912 ] InvokeTypes error using win32com v2.17

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

Bugs item #3525912, was opened at 2012-05-11 10:37
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3525912&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: win32
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Mike Fox (mike_fox)
Assigned to: Nobody/Anonymous (nobody)
Summary: InvokeTypes error using win32com v2.17

Initial Comment:
I think we have found a bug in win32com 2.17.  We are using it with Python 2.7.2.  We are calling a proprietary DLL named PATE, which provides APIs to a database named Enovia from the Dassault corporation.  The Enovia client is linked to a CAD program named CATIA so we must conjure objects of both CATIA and Enovia as shown in the code snippet below.  The strApplicationID is a password administered by my company and has nothing to do with the PATE DLL itself.  Rather, PATE should pass the strApplicationID to the Enovia server, which should authenticate the session.
====================================================================
import win32com.client, win32com.client.gencache, win32com.client.selecttlb
strPATECLSID = '{9BB3CB79-7098-47D0-83A2-F8F56D236DC8}'
strPATEclassCLSID = '{9A1F3C8E-46B7-4CFA-A820-E4256ECD53B5}'

self.objCATIA = win32com.client.GetActiveObject('CATIA.Application')
win32com.client.gencache.EnsureModule(strPATECLSID, 0, 0, 0)
self.objBase= win32com.client.gencache.GetClassForCLSID(strPATEclassCLSID)
self.__objPATECOM = self.objBase(self.objCATIA)
strApplicationID = <secret> 
try:
    self.__objPATECOM.SetApplicationID(strApplicationID)
except (pywintypes.com_error), _e:
    print "Connection error: %s" %(_e)
    return False
====================================================================
When we use win32com 2.16 the code above works fine but when we use win32com 2.17 it throws the error message shown below.

   File testKBE_PATECAKE.py, line 367 in ConnectToENOVIA
     self.__objPATECOM.SetApplicationID(strApplicationID)
   File "C:\Python27\lib\site-packages\win32com\gen_py\9BB3CB79 -7098-47D0-83A2-F8
F56D236DC8x0x0x0.py", line 457 in SetApplicationID
     return self._oleobj_.InvokeTypes(1610940417, LCID, 1, (24, 0), ((16396, 1),)
, iAID
   File "C:\Python27\lib\site-packages\win32com\client\dynamic.py", line 516 in 
__getattr__
     raise AttributeError("%s.%s" % (self._username_, attr))
   AttributeEror: CATIA.Application.InvokeTypes

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

>Comment By: Mark Hammond (mhammond)
Date: 2012-05-30 16:42

Message:
It looks like the genpy idea I had was wrong - the objects are the same in
both examples.

What should happen is that the line:

  self.__objPATECOM = self.objBase(self.objCATIA)

end up calling DispatchBaseClass.__init__ which is in
win32com\client\__init__.py.  What *should* happen, and appears to be
happening in 216 is it should enter the branch:

		elif isinstance(oobj, DispatchBaseClass):
			try:
				oobj = oobj._oleobj_.QueryInterface(self.CLSID,
pythoncom.IID_IDispatch) # Must be a valid COM instance
			except pythoncom.com_error, details:
				import winerror
				# Some stupid objects fail here, even tho it is _already_
IDispatch!!??
				# Eg, Lotus notes.
				# So just let it use the existing object if E_NOINTERFACE
				if details.hresult != winerror.E_NOINTERFACE:
					raise
				oobj = oobj._oleobj_

In the working case it just does the QI so oobj ends up as a "raw"
IDispatch.  In your failing 217 scenario, it seems to be either not hitting
that first condition at all, or enters that block but hits the "except
pythoncom.com_error" block.

You might want to instrument that code with prints to try and (a) confirm
I'm correct in the working case and (b) work out how it fails in the
failing case (ie, whether the 'if' statement simply isn't entered at all or
it hits the exception).

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

Comment By: Mike Fox (mike_fox)
Date: 2012-05-30 11:11

Message:
Sorry for the delay.  I added print statements after lines 4, 6, and 7 (in
the code shown in my original post).  With version 2.16
(pywin32-216.win-amd64-py2.7) I get the following correct output:
    self.objCATIA= <COMObject CATIA.Application>
    self.objBase=
win32com.gen_py.9BB3CB79-7098-47D0-83A2-F8F56D236DC8x0x0x0.PATECOM
    self.__objPATECOM= <win32com.gen_py.CATIA V5
BOEPATEAutomationInterfaces Object 
                       Library.PATECOM instance at 0x44540104>

Then I ran the same sript with version 2.17 (pywin32-217.win-amd64-py2.7)
and got the following:
    self.objCATIA= <COMObject CATIA.Application>
    self.objBase=
win32com.gen_py.9BB3CB79-7098-47D0-83A2-F8F56D236DC8x0x0x0.PATECOM
    self.__objPATECOM= <win32com.gen_py.CATIA V5
BOEPATEAutomationInterfaces Object 
                       Library.PATECOM instance at 0x44540104>
    Traceback (moste recent call last):
    File testKBE_PATECAKE.py, line 370 in ConnectToENOVIA
       self.__objPATECOM.SetApplicationID(strApplicationID)
   File "C:\Python27\lib\site-packages\win32com\gen_py\9BB3CB79
-7098-47D0-83A2-F8
           F56D236DC8x0x0x0.py", line 457 in SetApplicationID
       return self._oleobj_.InvokeTypes(1610940417, LCID, 1, (24, 0),
((16396, 1),), iAID
   File "C:\Python27\lib\site-packages\win32com\client\dynamic.py", line
516 in __getattr__
    raise AttributeError("%s.%s" % (self._username_, attr))
AttributeEror: CATIA.Application.InvokeTypes
    

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

Comment By: Mark Hammond (mhammond)
Date: 2012-05-15 17:34

Message:
Can you please modify your test code to add:

print self.objCATIA

After creating it, and tell me what it prints in both the failing and
working cases?

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

Comment By: Mike Fox (mike_fox)
Date: 2012-05-15 17:32

Message:
To Mark Hammond:
I don't think the problem is caused by a pre-existing wrapper in the gen_py
folder as you suggested in your comment.  When I uninstalled version 2.17
of pywin32 and installed version 2.16 on the same PC (with the contents of
the gen_py folder unchanged) I was able to call the SetApplicationID method
without it throwing an error.

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

Comment By: Mark Hammond (mhammond)
Date: 2012-05-11 19:51

Message:
I suspect the problem is that previously you have makepy support generated
for the 'CATIA.Application' object which should make things work.  The
problem is that when you do:

self.__objPATECOM = self.objBase(self.objCATIA)

The DispatchBaseClass.__init__ function in win32com\client\__init__.py
checks to see if the object is itself a makepy generated object and will
work correctly if it is.

Even though, this really is a bug as we should handle that situation.  A
fix would probably be to change the line in DispatchBaseClass.__init__
from:

		elif isinstance(oobj, DispatchBaseClass):
to
                elif hasattr(oobj, "_oleobj_"):


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

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

[pywin32-bugs] [ pywin32-Bugs-3525912 ] InvokeTypes error using win32com v2.17

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

Bugs item #3525912, was opened at 2012-05-11 10:37
Message generated for change (Comment added) made by mike_fox
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3525912&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: win32
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Mike Fox (mike_fox)
Assigned to: Nobody/Anonymous (nobody)
Summary: InvokeTypes error using win32com v2.17

Initial Comment:
I think we have found a bug in win32com 2.17.  We are using it with Python 2.7.2.  We are calling a proprietary DLL named PATE, which provides APIs to a database named Enovia from the Dassault corporation.  The Enovia client is linked to a CAD program named CATIA so we must conjure objects of both CATIA and Enovia as shown in the code snippet below.  The strApplicationID is a password administered by my company and has nothing to do with the PATE DLL itself.  Rather, PATE should pass the strApplicationID to the Enovia server, which should authenticate the session.
====================================================================
import win32com.client, win32com.client.gencache, win32com.client.selecttlb
strPATECLSID = '{9BB3CB79-7098-47D0-83A2-F8F56D236DC8}'
strPATEclassCLSID = '{9A1F3C8E-46B7-4CFA-A820-E4256ECD53B5}'

self.objCATIA = win32com.client.GetActiveObject('CATIA.Application')
win32com.client.gencache.EnsureModule(strPATECLSID, 0, 0, 0)
self.objBase= win32com.client.gencache.GetClassForCLSID(strPATEclassCLSID)
self.__objPATECOM = self.objBase(self.objCATIA)
strApplicationID = <secret> 
try:
    self.__objPATECOM.SetApplicationID(strApplicationID)
except (pywintypes.com_error), _e:
    print "Connection error: %s" %(_e)
    return False
====================================================================
When we use win32com 2.16 the code above works fine but when we use win32com 2.17 it throws the error message shown below.

   File testKBE_PATECAKE.py, line 367 in ConnectToENOVIA
     self.__objPATECOM.SetApplicationID(strApplicationID)
   File "C:\Python27\lib\site-packages\win32com\gen_py\9BB3CB79 -7098-47D0-83A2-F8
F56D236DC8x0x0x0.py", line 457 in SetApplicationID
     return self._oleobj_.InvokeTypes(1610940417, LCID, 1, (24, 0), ((16396, 1),)
, iAID
   File "C:\Python27\lib\site-packages\win32com\client\dynamic.py", line 516 in 
__getattr__
     raise AttributeError("%s.%s" % (self._username_, attr))
   AttributeEror: CATIA.Application.InvokeTypes

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

>Comment By: Mike Fox (mike_fox)
Date: 2012-05-30 11:11

Message:
Sorry for the delay.  I added print statements after lines 4, 6, and 7 (in
the code shown in my original post).  With version 2.16
(pywin32-216.win-amd64-py2.7) I get the following correct output:
    self.objCATIA= <COMObject CATIA.Application>
    self.objBase=
win32com.gen_py.9BB3CB79-7098-47D0-83A2-F8F56D236DC8x0x0x0.PATECOM
    self.__objPATECOM= <win32com.gen_py.CATIA V5
BOEPATEAutomationInterfaces Object 
                       Library.PATECOM instance at 0x44540104>

Then I ran the same sript with version 2.17 (pywin32-217.win-amd64-py2.7)
and got the following:
    self.objCATIA= <COMObject CATIA.Application>
    self.objBase=
win32com.gen_py.9BB3CB79-7098-47D0-83A2-F8F56D236DC8x0x0x0.PATECOM
    self.__objPATECOM= <win32com.gen_py.CATIA V5
BOEPATEAutomationInterfaces Object 
                       Library.PATECOM instance at 0x44540104>
    Traceback (moste recent call last):
    File testKBE_PATECAKE.py, line 370 in ConnectToENOVIA
       self.__objPATECOM.SetApplicationID(strApplicationID)
   File "C:\Python27\lib\site-packages\win32com\gen_py\9BB3CB79
-7098-47D0-83A2-F8
           F56D236DC8x0x0x0.py", line 457 in SetApplicationID
       return self._oleobj_.InvokeTypes(1610940417, LCID, 1, (24, 0),
((16396, 1),), iAID
   File "C:\Python27\lib\site-packages\win32com\client\dynamic.py", line
516 in __getattr__
    raise AttributeError("%s.%s" % (self._username_, attr))
AttributeEror: CATIA.Application.InvokeTypes
    

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

Comment By: Mark Hammond (mhammond)
Date: 2012-05-15 17:34

Message:
Can you please modify your test code to add:

print self.objCATIA

After creating it, and tell me what it prints in both the failing and
working cases?

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

Comment By: Mike Fox (mike_fox)
Date: 2012-05-15 17:32

Message:
To Mark Hammond:
I don't think the problem is caused by a pre-existing wrapper in the gen_py
folder as you suggested in your comment.  When I uninstalled version 2.17
of pywin32 and installed version 2.16 on the same PC (with the contents of
the gen_py folder unchanged) I was able to call the SetApplicationID method
without it throwing an error.

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

Comment By: Mark Hammond (mhammond)
Date: 2012-05-11 19:51

Message:
I suspect the problem is that previously you have makepy support generated
for the 'CATIA.Application' object which should make things work.  The
problem is that when you do:

self.__objPATECOM = self.objBase(self.objCATIA)

The DispatchBaseClass.__init__ function in win32com\client\__init__.py
checks to see if the object is itself a makepy generated object and will
work correctly if it is.

Even though, this really is a bug as we should handle that situation.  A
fix would probably be to change the line in DispatchBaseClass.__init__
from:

		elif isinstance(oobj, DispatchBaseClass):
to
                elif hasattr(oobj, "_oleobj_"):


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

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

[pywin32-bugs] [ pywin32-Bugs-3530753 ] anchor=False needed for FileList.include_pattern

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

Bugs item #3530753, was opened at 2012-05-30 01:22
Message generated for change (Comment added) made by stevenwinfield
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3530753&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: installation
Group: None
>Status: Deleted
>Resolution: Duplicate
Priority: 5
>Private: Yes
Submitted By: Steven Winfield (stevenwinfield)
Assigned to: Nobody/Anonymous (nobody)
Summary: anchor=False needed for FileList.include_pattern

Initial Comment:
While searching for "pythonwin\pywin\*.cfg", this is done in convert_data_files: ("file" here is "pythonwin\pywin\*.cfg")

flist.findall(os.path.dirname(file))     ( == flist.findall("pythonwin\pywin"))

...which populates flist.allfiles with lots of stuff beginning "pythonwin\pywin", then

flist.include_pattern(os.path.basename(file))     ( == flist.include_pattern("*.cfg"))

... is presumably meant to pick out all the .cfg files, but the docs for FileList.include_pattern are quite clear:

If 'anchor' is true (the default), then the pattern match is more
stringent: "*.py" will match "foo.py" but not "foo/bar.py".  If
'anchor' is false, both of these will match.

...so either anchor=False is required, or the call to os.path.basename can be removed (unless recursion is required, but I only saw .cfg files in pythonwin\pywin).


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

>Comment By: Steven Winfield (stevenwinfield)
Date: 2012-05-30 01:25

Message:
Sorry - a browser refresh caused this to be posted again.

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

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

[pywin32-bugs] [ pywin32-Bugs-3530753 ] anchor=False needed for FileList.include_pattern

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

Bugs item #3530753, was opened at 2012-05-30 01:22
Message generated for change (Tracker Item Submitted) made by stevenwinfield
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3530753&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: installation
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Steven Winfield (stevenwinfield)
Assigned to: Nobody/Anonymous (nobody)
Summary: anchor=False needed for FileList.include_pattern

Initial Comment:
While searching for "pythonwin\pywin\*.cfg", this is done in convert_data_files: ("file" here is "pythonwin\pywin\*.cfg")

flist.findall(os.path.dirname(file))     ( == flist.findall("pythonwin\pywin"))

...which populates flist.allfiles with lots of stuff beginning "pythonwin\pywin", then

flist.include_pattern(os.path.basename(file))     ( == flist.include_pattern("*.cfg"))

... is presumably meant to pick out all the .cfg files, but the docs for FileList.include_pattern are quite clear:

If 'anchor' is true (the default), then the pattern match is more
stringent: "*.py" will match "foo.py" but not "foo/bar.py".  If
'anchor' is false, both of these will match.

...so either anchor=False is required, or the call to os.path.basename can be removed (unless recursion is required, but I only saw .cfg files in pythonwin\pywin).


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

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

[pywin32-bugs] [ pywin32-Bugs-3530615 ] anchor=False needed for FileList.include_pattern

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

Bugs item #3530615, was opened at 2012-05-29 11:31
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3530615&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: installation
Group: None
>Status: Closed
>Resolution: Out of Date
Priority: 5
Private: No
Submitted By: Steven Winfield (stevenwinfield)
Assigned to: Nobody/Anonymous (nobody)
Summary: anchor=False needed for FileList.include_pattern

Initial Comment:
While searching for "pythonwin\pywin\*.cfg", this is done in convert_data_files: ("file" here is "pythonwin\pywin\*.cfg")

flist.findall(os.path.dirname(file))     ( == flist.findall("pythonwin\pywin"))

...which populates flist.allfiles with lots of stuff beginning "pythonwin\pywin", then

flist.include_pattern(os.path.basename(file))     ( == flist.include_pattern("*.cfg"))

... is presumably meant to pick out all the .cfg files, but the docs for FileList.include_pattern are quite clear:

If 'anchor' is true (the default), then the pattern match is more
stringent: "*.py" will match "foo.py" but not "foo/bar.py".  If
'anchor' is false, both of these will match.

...so either anchor=False is required, or the call to os.path.basename can be removed (unless recursion is required, but I only saw .cfg files in pythonwin\pywin).


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

>Comment By: Mark Hammond (mhammond)
Date: 2012-05-29 16:36

Message:
I believe this has been addressed in the hg repo - please reopen if this
isn't the case or there is something we missed.

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

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

[pywin32-bugs] [ pywin32-Bugs-3530615 ] anchor=False needed for FileList.include_pattern

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

Bugs item #3530615, was opened at 2012-05-29 11:31
Message generated for change (Tracker Item Submitted) made by stevenwinfield
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3530615&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: installation
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Steven Winfield (stevenwinfield)
Assigned to: Nobody/Anonymous (nobody)
Summary: anchor=False needed for FileList.include_pattern

Initial Comment:
While searching for "pythonwin\pywin\*.cfg", this is done in convert_data_files: ("file" here is "pythonwin\pywin\*.cfg")

flist.findall(os.path.dirname(file))     ( == flist.findall("pythonwin\pywin"))

...which populates flist.allfiles with lots of stuff beginning "pythonwin\pywin", then

flist.include_pattern(os.path.basename(file))     ( == flist.include_pattern("*.cfg"))

... is presumably meant to pick out all the .cfg files, but the docs for FileList.include_pattern are quite clear:

If 'anchor' is true (the default), then the pattern match is more
stringent: "*.py" will match "foo.py" but not "foo/bar.py".  If
'anchor' is false, both of these will match.

...so either anchor=False is required, or the call to os.path.basename can be removed (unless recursion is required, but I only saw .cfg files in pythonwin\pywin).


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

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

[pywin32-bugs] [ pywin32-Bugs-3530493 ] Unhelpful traceback if sdk_dir is None

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

Bugs item #3530493, was opened at 2012-05-29 05:01
Message generated for change (Tracker Item Submitted) made by stevenwinfield
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3530493&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: installation
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Steven Winfield (stevenwinfield)
Assigned to: Nobody/Anonymous (nobody)
Summary: Unhelpful traceback if sdk_dir is None

Initial Comment:
In setup.py, the global variable sdk_dir is set on line 310 by find_platform_sdk_dir().

If find_platform_sdk_dir() can't find a Platform SDK it returns None, since os.environ.get("MSSdk") on line 162 returns None.

Later, sdk_dir is used as the first argument to os.path.join on line 604, but this fails with a slightly unhelpful traceback:

Traceback (most recent call last):
  File "setup.py", line 1945, in <module>
    """ % dirs).split(),
  File "setup.py", line 604, in __init__
    if os.path.isfile(os.path.join(sdk_dir, "include", "activdbg.h")):
  File "H:\external\local_windows_32_vc8\python27\lib\ntpath.py", line 96, in join
    assert len(path) > 0
TypeError: object of type 'NoneType' has no len()

A check for "if sdk_dir is None" after line 310 with a relevant error messge would be nice :-)

I'm hitting this problem because I'm building with Visual Studio 2005, whose Platform SDK is at C:\Program Files (x86)\Microsoft Visual Studio 8\VC\PlatformSDK (on a 64bit system, but building the 32bit binaries).

Thanks for all the hard work on this package!


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

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

[pywin32-bugs] [ pywin32-Bugs-3528888 ] Errors when installing with UAC disabled

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

Bugs item #3528888, was opened at 2012-05-22 10:37
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3528888&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: installation
Group: None
Status: Open
>Resolution: Accepted
Priority: 5
Private: No
Submitted By: class101 (class1o1)
Assigned to: Mark Hammond (mhammond)
>Summary: Errors when installing with UAC disabled

Initial Comment:
If your installation of pywin32 on Windows 7 always end with 

close failed in file object destructor:
sys.excepthook is missing
lost sys.stderr

This is maybe because you are running Windows under the "Administrator" account and anything you normally run is equal to a "run as Administrator"

And paradoxically running the installation of pywin32 on Windows 7 as Administrator causes this error.

So a workaround is to create another admin account

net user Admin /add
net user Admin <type your password>
net localgroup Administrators Admin /add

and then run the pywin32 installation with

runas /user:Admin pywin32-217.win32-py2.7.exe


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

>Comment By: Mark Hammond (mhammond)
Date: 2012-05-28 23:10

Message:
I can verify that disabling UAC causes this error when run from an admin
account (regardless of that account's name).  It looks like the install
completes successfully (at least the pywin32_postinstall.log file in the
temp dir is complete), but I'll try and dig further into what is causing
this error to be shown.

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

Comment By: class101 (class1o1)
Date: 2012-05-27 03:17

Message:
To note that on all of my Windows machines, first things I do is enabling
the Administrator account to take ownage of it, and always disabling the
UAC

To me this is urgent to fix this for good mhammond because postscripts
seems to generate files and its a bit dangerous to redistribute something
that unstable out of the box because the we identify further errors and we
have to investigate few hours to finally find out pywin32 was not 100%
installed, I had made some research about this issue previously, it seems
you applied previous patches for this few years ago, but I'm sorry to
inform you 217 is still not stable and fails to install with reproducable
cases.

Also you may be instered to throw out then don't use the Administrator
account, I'm working with computer each day this is my work and I notice
pywin32 is only or really on of the few product I see failing under the
Administrator account and working under a different admin account, but when
you know how quircky is the Windows security scheme, its more than evident
but definitely not a solution for me to use another Admin account, Windows
is just too quircky for this.

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

Comment By: class101 (class1o1)
Date: 2012-05-22 10:43

Message:
Bug identified and workaround tested working on 

Windows 7, 64-bit, English, main admin account: Administrator
Windows 7, 64-bit, French, main admin account: Administrateur
Windows 7, 64-bit, English, main admin account: Admin

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

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

[pywin32-bugs] [ pywin32-Bugs-3530195 ] errors towards the end of installation.

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

Bugs item #3530195, was opened at 2012-05-28 01:37
Message generated for change (Tracker Item Submitted) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3530195&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: installation
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: 3860654 ()
Assigned to: Nobody/Anonymous (nobody)
Summary: errors towards the end of installation.

Initial Comment:
While trying to install pywin32-217.win-amd64-py2.6.exe, I get following errors towards the end of installation.

Traceback (most recent call last):

  File "<string>", line 612, in <module>

  File "<string>", line 322, in install

  File "<string>", line 160, in LoadSystemModule

ImportError: DLL load failed: The specified module could not be found.


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

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

[pywin32-bugs] [ pywin32-Bugs-3528888 ] [solution inside] Windows 7 installation failure

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

Bugs item #3528888, was opened at 2012-05-22 10:37
Message generated for change (Comment added) made by class1o1
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3528888&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: installation
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: class101 (class1o1)
Assigned to: Mark Hammond (mhammond)
Summary: [solution inside] Windows 7 installation failure

Initial Comment:
If your installation of pywin32 on Windows 7 always end with 

close failed in file object destructor:
sys.excepthook is missing
lost sys.stderr

This is maybe because you are running Windows under the "Administrator" account and anything you normally run is equal to a "run as Administrator"

And paradoxically running the installation of pywin32 on Windows 7 as Administrator causes this error.

So a workaround is to create another admin account

net user Admin /add
net user Admin <type your password>
net localgroup Administrators Admin /add

and then run the pywin32 installation with

runas /user:Admin pywin32-217.win32-py2.7.exe


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

>Comment By: class101 (class1o1)
Date: 2012-05-27 03:17

Message:
To note that on all of my Windows machines, first things I do is enabling
the Administrator account to take ownage of it, and always disabling the
UAC

To me this is urgent to fix this for good mhammond because postscripts
seems to generate files and its a bit dangerous to redistribute something
that unstable out of the box because the we identify further errors and we
have to investigate few hours to finally find out pywin32 was not 100%
installed, I had made some research about this issue previously, it seems
you applied previous patches for this few years ago, but I'm sorry to
inform you 217 is still not stable and fails to install with reproducable
cases.

Also you may be instered to throw out then don't use the Administrator
account, I'm working with computer each day this is my work and I notice
pywin32 is only or really on of the few product I see failing under the
Administrator account and working under a different admin account, but when
you know how quircky is the Windows security scheme, its more than evident
but definitely not a solution for me to use another Admin account, Windows
is just too quircky for this.

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

Comment By: class101 (class1o1)
Date: 2012-05-22 10:43

Message:
Bug identified and workaround tested working on 

Windows 7, 64-bit, English, main admin account: Administrator
Windows 7, 64-bit, French, main admin account: Administrateur
Windows 7, 64-bit, English, main admin account: Admin

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

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

[pywin32-bugs] [ pywin32-Feature Requests-3529527 ] add AddEnglishCounter in win32pdh

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

Feature Requests item #3529527, was opened at 2012-05-24 11:06
Message generated for change (Tracker Item Submitted) made by argos83
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551957&aid=3529527&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: win32
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Sebastian (argos83)
Assigned to: Nobody/Anonymous (nobody)
Summary: add AddEnglishCounter in win32pdh

Initial Comment:
Counter paths in win32pdh are language dependent. For instance, the following code will raise a pywintypes.error when run on a not English Windows.:

import win32pdh
path = win32pdh.MakeCounterPath(( None, 'System', None, None, 0, 'System Up Time'))
query = win32pdh.OpenQuery()
handle = win32pdh.AddCounter(query, path)

E.g., to make that work on a Spanish Windows, the MakeCounterPath line should be:
path = win32pdh.MakeCounterPath(( None, 'Sistema', None, None, 0, 'Tiempo de actividad del sistema'))

Which makes it real hard to distribute a solution that is supposed to run on different language platforms.

To avoid that, there's this PdhAddEnglishCounter function: http://msdn.microsoft.com/en-us/library/windows/desktop/aa372536(v=vs.85).aspx
Which is not implemented on pywin. If implemented, this should work on any windows language:

import win32pdh
path = win32pdh.MakeCounterPath(( None, 'System', None, None, 0, 'System Up Time'))
query = win32pdh.OpenQuery()
handle = win32pdh.AddEnglishCounter(query, path)

AddCounter and AddEnglishCounter functions have the same signature. I guess that adding the following to win32pdhmodule.cpp should be enough:

typedef PDH_STATUS (WINAPI * FuncPdhAddEnglishCounter)(
    HQUERY hQuery,	// handle to the query
    LPCTSTR szFullCounterPath,	// path of the counter
    DWORD_PTR dwUserData,	// user-defined value
    HCOUNTER *phCounter	// pointer to the counter handle buffer
   );	

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

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

[pywin32-bugs] [ pywin32-Bugs-3528888 ] [solution inside] Windows 7 installation failure

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

Bugs item #3528888, was opened at 2012-05-22 10:37
Message generated for change (Comment added) made by class1o1
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3528888&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: installation
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: class101 (class1o1)
>Assigned to: Mark Hammond (mhammond)
Summary: [solution inside] Windows 7 installation failure

Initial Comment:
If your installation of pywin32 on Windows 7 always end with 

close failed in file object destructor:
sys.excepthook is missing
lost sys.stderr

This is maybe because you are running Windows under the "Administrator" account and anything you normally run is equal to a "run as Administrator"

And paradoxically running the installation of pywin32 on Windows 7 as Administrator causes this error.

So a workaround is to create another admin account

net user Admin /add
net user Admin <type your password>
net localgroup Administrators Admin /add

and then run the pywin32 installation with

runas /user:Admin pywin32-217.win32-py2.7.exe


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

>Comment By: class101 (class1o1)
Date: 2012-05-22 10:43

Message:
Bug identified and workaround tested working on 

Windows 7, 64-bit, English, main admin account: Administrator
Windows 7, 64-bit, French, main admin account: Administrateur
Windows 7, 64-bit, English, main admin account: Admin

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

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

[pywin32-bugs] [ pywin32-Bugs-3528888 ] [solution inside] Windows 7 installation failure

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

Bugs item #3528888, was opened at 2012-05-22 10:37
Message generated for change (Tracker Item Submitted) made by class1o1
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3528888&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: installation
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: class101 (class1o1)
Assigned to: Nobody/Anonymous (nobody)
Summary: [solution inside] Windows 7 installation failure

Initial Comment:
If your installation of pywin32 on Windows 7 always end with 

close failed in file object destructor:
sys.excepthook is missing
lost sys.stderr

This is maybe because you are running Windows under the "Administrator" account and anything you normally run is equal to a "run as Administrator"

And paradoxically running the installation of pywin32 on Windows 7 as Administrator causes this error.

So a workaround is to create another admin account

net user Admin /add
net user Admin <type your password>
net localgroup Administrators Admin /add

and then run the pywin32 installation with

runas /user:Admin pywin32-217.win32-py2.7.exe


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

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

[pywin32-bugs] [ pywin32-Bugs-3528396 ] Cannot compile Unicode variant for Python 2.7

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

Bugs item #3528396, was opened at 2012-05-20 06:25
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3528396&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: installation
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: shypike (shypike)
Assigned to: Nobody/Anonymous (nobody)
Summary: Cannot compile Unicode variant for Python 2.7

Initial Comment:
Is it possible to build PyWin32 for Python 2.7 with Unicode support?
I have tried to (by changing setup.py), but I keep running into compilation problems.
I have setup the environment properly and I can build the non-Unicode variant successfully (except for Exchange support, which I don't care about).


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

>Comment By: Mark Hammond (mhammond)
Date: 2012-05-20 15:57

Message:
It's not possible now but shouldn't be far from working.  If you run into
specific problems, please open bugs, but closing this as invalid as there
is nothing actionable.

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

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

[pywin32-bugs] [ pywin32-Bugs-3528407 ] Cannot compile Unicode variant for Python 2.7

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

Bugs item #3528407, was opened at 2012-05-20 08:51
Message generated for change (Settings changed) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3528407&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: installation
Group: None
>Status: Closed
>Resolution: Duplicate
Priority: 5
Private: No
Submitted By: shypike (shypike)
Assigned to: Nobody/Anonymous (nobody)
Summary: Cannot compile Unicode variant for Python 2.7

Initial Comment:
Is it possible to build PyWin32 for Python 2.7 with Unicode support?
I have tried to (by changing setup.py), but I keep running into compilation problems.
I have setup the environment properly and I can build the non-Unicode variant successfully (except for Exchange support, which I don't care about).


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

Comment By: shypike (shypike)
Date: 2012-05-20 08:53

Message:
DUPLICATE, PLEASE REMOVE

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

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

[pywin32-bugs] [ pywin32-Bugs-3528407 ] Cannot compile Unicode variant for Python 2.7

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

Bugs item #3528407, was opened at 2012-05-20 08:51
Message generated for change (Comment added) made by shypike
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3528407&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: installation
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: shypike (shypike)
Assigned to: Nobody/Anonymous (nobody)
Summary: Cannot compile Unicode variant for Python 2.7

Initial Comment:
Is it possible to build PyWin32 for Python 2.7 with Unicode support?
I have tried to (by changing setup.py), but I keep running into compilation problems.
I have setup the environment properly and I can build the non-Unicode variant successfully (except for Exchange support, which I don't care about).


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

>Comment By: shypike (shypike)
Date: 2012-05-20 08:53

Message:
DUPLICATE, PLEASE REMOVE

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

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

[pywin32-bugs] [ pywin32-Bugs-3528407 ] Cannot compile Unicode variant for Python 2.7

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

Bugs item #3528407, was opened at 2012-05-20 08:51
Message generated for change (Tracker Item Submitted) made by shypike
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3528407&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: installation
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: shypike (shypike)
Assigned to: Nobody/Anonymous (nobody)
Summary: Cannot compile Unicode variant for Python 2.7

Initial Comment:
Is it possible to build PyWin32 for Python 2.7 with Unicode support?
I have tried to (by changing setup.py), but I keep running into compilation problems.
I have setup the environment properly and I can build the non-Unicode variant successfully (except for Exchange support, which I don't care about).


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

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

[pywin32-bugs] [ pywin32-Bugs-3528396 ] Cannot compile Unicode variant for Python 2.7

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

Bugs item #3528396, was opened at 2012-05-20 06:25
Message generated for change (Tracker Item Submitted) made by shypike
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3528396&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: installation
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: shypike (shypike)
Assigned to: Nobody/Anonymous (nobody)
Summary: Cannot compile Unicode variant for Python 2.7

Initial Comment:
Is it possible to build PyWin32 for Python 2.7 with Unicode support?
I have tried to (by changing setup.py), but I keep running into compilation problems.
I have setup the environment properly and I can build the non-Unicode variant successfully (except for Exchange support, which I don't care about).


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

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

[pywin32-bugs] [ pywin32-Bugs-3527563 ] dll's in wrong folder after installation

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

Bugs item #3527563, was opened at 2012-05-17 03:54
Message generated for change (Comment added) made by robert-whitley
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3527563&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: installation
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Robert Whitley (robert-whitley)
Assigned to: Nobody/Anonymous (nobody)
Summary: dll's in wrong folder after installation

Initial Comment:
Using the installer for build 216 and 217 I had an error at the end which I've attached to this bug report.

Win32com didn't import properly. The reason for this is that three dll's were in the wrong folder.

* pywintypes26
* pythoncomloader26
* pythoncom26

They needed to be moved to win32 folder. This problem was reported on stack overflow nearly a year ago and the fix is still the same. http://stackoverflow.com/questions/7238403/import-win32api-error-in-python-2-6

I use Python 2.6 32-bit version on Windows 7 64-bit version.

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

>Comment By: Robert Whitley (robert-whitley)
Date: 2012-05-17 07:20

Message:
I found the log in the temp directory but it was empty so I didn't bother
uploading it.

I have uploaded what the installer looks like when it errors.

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

Comment By: Mark Hammond (mhammond)
Date: 2012-05-17 07:03

Message:
What is the most recent thing shown in the main installer window when this
happens?  There might even be a pywin32_postinstall.log (or something like
that :) in your temp directory - could you grab that while the error dialog
is up and attach it here?  I'm going to need help to work out exactly when
and why it happens...

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

Comment By: Robert Whitley (robert-whitley)
Date: 2012-05-17 05:28

Message:
The problem happens right at the end.

I tried build 217, uninstalled, tried again, uninstalled, tried build 216,
uninstalled, tried 217 again. On each of these occasions I had the same
error.

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

Comment By: Mark Hammond (mhammond)
Date: 2012-05-17 04:52

Message:
The install script should copy them there (or to system32) - I expect that
error is the problem.

When exactly during the install process does this happen - right at the
end?  Is this reproducible - ie, can you uninstall then reinstall and see
the same issue?

Thanks!

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

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

[pywin32-bugs] [ pywin32-Bugs-3527563 ] dll's in wrong folder after installation

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

Bugs item #3527563, was opened at 2012-05-17 03:54
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3527563&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: installation
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Robert Whitley (robert-whitley)
Assigned to: Nobody/Anonymous (nobody)
Summary: dll's in wrong folder after installation

Initial Comment:
Using the installer for build 216 and 217 I had an error at the end which I've attached to this bug report.

Win32com didn't import properly. The reason for this is that three dll's were in the wrong folder.

* pywintypes26
* pythoncomloader26
* pythoncom26

They needed to be moved to win32 folder. This problem was reported on stack overflow nearly a year ago and the fix is still the same. http://stackoverflow.com/questions/7238403/import-win32api-error-in-python-2-6

I use Python 2.6 32-bit version on Windows 7 64-bit version.

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

>Comment By: Mark Hammond (mhammond)
Date: 2012-05-17 07:03

Message:
What is the most recent thing shown in the main installer window when this
happens?  There might even be a pywin32_postinstall.log (or something like
that :) in your temp directory - could you grab that while the error dialog
is up and attach it here?  I'm going to need help to work out exactly when
and why it happens...

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

Comment By: Robert Whitley (robert-whitley)
Date: 2012-05-17 05:28

Message:
The problem happens right at the end.

I tried build 217, uninstalled, tried again, uninstalled, tried build 216,
uninstalled, tried 217 again. On each of these occasions I had the same
error.

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

Comment By: Mark Hammond (mhammond)
Date: 2012-05-17 04:52

Message:
The install script should copy them there (or to system32) - I expect that
error is the problem.

When exactly during the install process does this happen - right at the
end?  Is this reproducible - ie, can you uninstall then reinstall and see
the same issue?

Thanks!

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

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

[pywin32-bugs] [ pywin32-Bugs-3527563 ] dll's in wrong folder after installation

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

Bugs item #3527563, was opened at 2012-05-17 03:54
Message generated for change (Comment added) made by robert-whitley
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3527563&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: installation
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Robert Whitley (robert-whitley)
Assigned to: Nobody/Anonymous (nobody)
Summary: dll's in wrong folder after installation

Initial Comment:
Using the installer for build 216 and 217 I had an error at the end which I've attached to this bug report.

Win32com didn't import properly. The reason for this is that three dll's were in the wrong folder.

* pywintypes26
* pythoncomloader26
* pythoncom26

They needed to be moved to win32 folder. This problem was reported on stack overflow nearly a year ago and the fix is still the same. http://stackoverflow.com/questions/7238403/import-win32api-error-in-python-2-6

I use Python 2.6 32-bit version on Windows 7 64-bit version.

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

>Comment By: Robert Whitley (robert-whitley)
Date: 2012-05-17 05:28

Message:
The problem happens right at the end.

I tried build 217, uninstalled, tried again, uninstalled, tried build 216,
uninstalled, tried 217 again. On each of these occasions I had the same
error.

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

Comment By: Mark Hammond (mhammond)
Date: 2012-05-17 04:52

Message:
The install script should copy them there (or to system32) - I expect that
error is the problem.

When exactly during the install process does this happen - right at the
end?  Is this reproducible - ie, can you uninstall then reinstall and see
the same issue?

Thanks!

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

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