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

[pywin32-bugs] [ pywin32-Bugs-2132639 ] win32file.GetCommState incorrect handling of DCB

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

Bugs item #2132639, was opened at 2008-09-28 04:56
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2132639&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: Alan Gardner (jiaailun)
Assigned to: Nobody/Anonymous (nobody)
Summary: win32file.GetCommState incorrect handling of DCB

Initial Comment:
I believe I have found a bug in win32file.GetCommState and win32file.SetCommState.  I have seen it in Python 2.4 and Python 2.5, running an older version of pywin32, as well as the current (212) version.  It exists in Win2k and WinXP.  I use pyserial 2.4 as a wrapper for the comm ports, though I believe the problem is in win32file.

The problem manifests itself when I try to open a com port in Python after having that port open in Procomm (an old, no longer supported terminal program).  I have only seen it happen with a particular brand of USB to serial converters (Edgeport, made by Digi).  In these conditions the python script will hang at the win32file.SetCommState() command, usually timing out after 5-30 seconds, and quitting with no error message.

After having done some probing I think I basically understand the problem, and have a workaround, but I lack the know-how to fix it where it should be fixed, in win32file.  When Procomm opens the port, it sets XoffLim to 16128 and the XonLim to 15872.  When my script (actually, serialwin32.py from pyserial) tries to open the port it first reads the DCB with GetCommState(), changes baud rate, etc in the local PyDCB object, and then tries to reconfigure the port with SetCommState().  

>From what I can tell, SetCommState won't accept a value for XoffLim or XonLim >4096.  For example, if I try to execute the following:
DCB.XoffLim = 16128
SetCommState(porthandle,DCB)

I get an exception: (87, 'SetCommState', 'The parameter is incorrect.')

However, if GetCommState gets a DCB which has XoffLim = 16128, and then that DCB is passed to SetCommState, the script hangs for several seconds before exiting without opening the port and with no error message.  For example, after having opened and closed the port in Procomm:

>>> DCB = GetCommState(porthandle)
>>> DCB.XoffLim
16128L
>>> SetCommState(porthandle,DCB)
(...... hangs here for several seconds ......)

If I set XoffLim and XonLim to values from 0-4096 before calling SetCommState, then it works fine.  For example, after having opened and closed the port in Procomm:

>>> DCB = GetCommState(porthandle)
>>> DCB.XoffLim = 128
>>> DCB.XonLim = 512
>>> SetCommState(porthandle,DCB)
>>>
This works fine, and I can go on to open the port normally.  I have incorporated this fix into serialwin32.py which is working for me now, but it's not an elegant solution.  I am still baffled by why
SetCommState limits Xon/XoffLim to 4096, and by what GetCommState does to the PyDCB to make it cause SetCommState to fail so dramatically.  I also don't understand why I only see this problem with the Edgeport USB converters, and not with several other USB converters or hardware serial ports.  Maybe someone with a more intimate understanding of Python and Win32 can come up with some answers.

Thank you
-Alan Gardner
Woods Hole Oceanographic Institution
Woods Hole, MA 02543

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

>Comment By: Mark Hammond (mhammond)
Date: 2008-09-30 14:52

Message:
If you think pywin32 is doing something incorrect with its DCB handling,
the only real way to demonstrate that is a snippet of C code that behaves
differently.  Given our arg handling looks OK, we will otherwise need to
assume the behaviour is just a characteristic of the windows API itself.

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

Comment By: Alan Gardner (jiaailun)
Date: 2008-09-30 14:41

Message:
OK, since I realize this may be a difficult problem to recreate I have
annotated some screen captures from the interpreter.  In the process I
realized that the XonLim and XoffLim are obviously going to be limited by
the buffer size, and yes, pyserial does set the buffer to 4096.  OK, so now
I have another workaround, increasing the buffer size so that the XonLim
and XoffLim values are no longer to large.  But I still think that there is
an underlying bug.  When a port is opened with CreateFile it appears to
assign a default buffer size, and this can lead to XonLim and XoffLim
values which are out of range.  If SetCommState then tries to set an out of
range value to one of these parameters, it hangs.  I have some captures
from DebugView and PortMon which show Python.exe repeatedly getting and
setting parameters on the serial port in a nearly endless loop.  I can
upload these if it would be helpful, but they are moderately large and
arcane.  For now I will upload the annotated screen captures showing what I
see at this end.
File Added: win32file.SetCommState_interactive.txt

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

Comment By: Roger Upole (rupole)
Date: 2008-09-28 06:13

Message:
I don't see any problem with the way the DCB is passed to/from
SetCommState and GetCommState.  The XonLim and XoffLim members
consistently have the correct value.

If I recall from looking at pyserial a while back, it sets the
buffer sizes to 4096.  Have you tried increasing them in the
call to SetupComm ?


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

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

[pywin32-bugs] [ pywin32-Bugs-2132639 ] win32file.GetCommState incorrect handling of DCB

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

Bugs item #2132639, was opened at 2008-09-27 14:56
Message generated for change (Comment added) made by jiaailun
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2132639&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: Alan Gardner (jiaailun)
Assigned to: Nobody/Anonymous (nobody)
Summary: win32file.GetCommState incorrect handling of DCB

Initial Comment:
I believe I have found a bug in win32file.GetCommState and win32file.SetCommState.  I have seen it in Python 2.4 and Python 2.5, running an older version of pywin32, as well as the current (212) version.  It exists in Win2k and WinXP.  I use pyserial 2.4 as a wrapper for the comm ports, though I believe the problem is in win32file.

The problem manifests itself when I try to open a com port in Python after having that port open in Procomm (an old, no longer supported terminal program).  I have only seen it happen with a particular brand of USB to serial converters (Edgeport, made by Digi).  In these conditions the python script will hang at the win32file.SetCommState() command, usually timing out after 5-30 seconds, and quitting with no error message.

After having done some probing I think I basically understand the problem, and have a workaround, but I lack the know-how to fix it where it should be fixed, in win32file.  When Procomm opens the port, it sets XoffLim to 16128 and the XonLim to 15872.  When my script (actually, serialwin32.py from pyserial) tries to open the port it first reads the DCB with GetCommState(), changes baud rate, etc in the local PyDCB object, and then tries to reconfigure the port with SetCommState().  

>From what I can tell, SetCommState won't accept a value for XoffLim or XonLim >4096.  For example, if I try to execute the following:
DCB.XoffLim = 16128
SetCommState(porthandle,DCB)

I get an exception: (87, 'SetCommState', 'The parameter is incorrect.')

However, if GetCommState gets a DCB which has XoffLim = 16128, and then that DCB is passed to SetCommState, the script hangs for several seconds before exiting without opening the port and with no error message.  For example, after having opened and closed the port in Procomm:

>>> DCB = GetCommState(porthandle)
>>> DCB.XoffLim
16128L
>>> SetCommState(porthandle,DCB)
(...... hangs here for several seconds ......)

If I set XoffLim and XonLim to values from 0-4096 before calling SetCommState, then it works fine.  For example, after having opened and closed the port in Procomm:

>>> DCB = GetCommState(porthandle)
>>> DCB.XoffLim = 128
>>> DCB.XonLim = 512
>>> SetCommState(porthandle,DCB)
>>>
This works fine, and I can go on to open the port normally.  I have incorporated this fix into serialwin32.py which is working for me now, but it's not an elegant solution.  I am still baffled by why
SetCommState limits Xon/XoffLim to 4096, and by what GetCommState does to the PyDCB to make it cause SetCommState to fail so dramatically.  I also don't understand why I only see this problem with the Edgeport USB converters, and not with several other USB converters or hardware serial ports.  Maybe someone with a more intimate understanding of Python and Win32 can come up with some answers.

Thank you
-Alan Gardner
Woods Hole Oceanographic Institution
Woods Hole, MA 02543

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

>Comment By: Alan Gardner (jiaailun)
Date: 2008-09-30 00:41

Message:
OK, since I realize this may be a difficult problem to recreate I have
annotated some screen captures from the interpreter.  In the process I
realized that the XonLim and XoffLim are obviously going to be limited by
the buffer size, and yes, pyserial does set the buffer to 4096.  OK, so now
I have another workaround, increasing the buffer size so that the XonLim
and XoffLim values are no longer to large.  But I still think that there is
an underlying bug.  When a port is opened with CreateFile it appears to
assign a default buffer size, and this can lead to XonLim and XoffLim
values which are out of range.  If SetCommState then tries to set an out of
range value to one of these parameters, it hangs.  I have some captures
from DebugView and PortMon which show Python.exe repeatedly getting and
setting parameters on the serial port in a nearly endless loop.  I can
upload these if it would be helpful, but they are moderately large and
arcane.  For now I will upload the annotated screen captures showing what I
see at this end.
File Added: win32file.SetCommState_interactive.txt

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

Comment By: Roger Upole (rupole)
Date: 2008-09-27 16:13

Message:
I don't see any problem with the way the DCB is passed to/from
SetCommState and GetCommState.  The XonLim and XoffLim members
consistently have the correct value.

If I recall from looking at pyserial a while back, it sets the
buffer sizes to 4096.  Have you tried increasing them in the
call to SetupComm ?


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

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

[pywin32-bugs] [ pywin32-Bugs-2132639 ] win32file.GetCommState incorrect handling of DCB

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

Bugs item #2132639, was opened at 2008-09-27 13:56
Message generated for change (Comment added) made by rupole
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2132639&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: Alan Gardner (jiaailun)
Assigned to: Nobody/Anonymous (nobody)
Summary: win32file.GetCommState incorrect handling of DCB

Initial Comment:
I believe I have found a bug in win32file.GetCommState and win32file.SetCommState.  I have seen it in Python 2.4 and Python 2.5, running an older version of pywin32, as well as the current (212) version.  It exists in Win2k and WinXP.  I use pyserial 2.4 as a wrapper for the comm ports, though I believe the problem is in win32file.

The problem manifests itself when I try to open a com port in Python after having that port open in Procomm (an old, no longer supported terminal program).  I have only seen it happen with a particular brand of USB to serial converters (Edgeport, made by Digi).  In these conditions the python script will hang at the win32file.SetCommState() command, usually timing out after 5-30 seconds, and quitting with no error message.

After having done some probing I think I basically understand the problem, and have a workaround, but I lack the know-how to fix it where it should be fixed, in win32file.  When Procomm opens the port, it sets XoffLim to 16128 and the XonLim to 15872.  When my script (actually, serialwin32.py from pyserial) tries to open the port it first reads the DCB with GetCommState(), changes baud rate, etc in the local PyDCB object, and then tries to reconfigure the port with SetCommState().  

>From what I can tell, SetCommState won't accept a value for XoffLim or XonLim >4096.  For example, if I try to execute the following:
DCB.XoffLim = 16128
SetCommState(porthandle,DCB)

I get an exception: (87, 'SetCommState', 'The parameter is incorrect.')

However, if GetCommState gets a DCB which has XoffLim = 16128, and then that DCB is passed to SetCommState, the script hangs for several seconds before exiting without opening the port and with no error message.  For example, after having opened and closed the port in Procomm:

>>> DCB = GetCommState(porthandle)
>>> DCB.XoffLim
16128L
>>> SetCommState(porthandle,DCB)
(...... hangs here for several seconds ......)

If I set XoffLim and XonLim to values from 0-4096 before calling SetCommState, then it works fine.  For example, after having opened and closed the port in Procomm:

>>> DCB = GetCommState(porthandle)
>>> DCB.XoffLim = 128
>>> DCB.XonLim = 512
>>> SetCommState(porthandle,DCB)
>>>
This works fine, and I can go on to open the port normally.  I have incorporated this fix into serialwin32.py which is working for me now, but it's not an elegant solution.  I am still baffled by why
SetCommState limits Xon/XoffLim to 4096, and by what GetCommState does to the PyDCB to make it cause SetCommState to fail so dramatically.  I also don't understand why I only see this problem with the Edgeport USB converters, and not with several other USB converters or hardware serial ports.  Maybe someone with a more intimate understanding of Python and Win32 can come up with some answers.

Thank you
-Alan Gardner
Woods Hole Oceanographic Institution
Woods Hole, MA 02543

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

>Comment By: Roger Upole (rupole)
Date: 2008-09-27 15:13

Message:
I don't see any problem with the way the DCB is passed to/from
SetCommState and GetCommState.  The XonLim and XoffLim members
consistently have the correct value.

If I recall from looking at pyserial a while back, it sets the
buffer sizes to 4096.  Have you tried increasing them in the
call to SetupComm ?


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

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

[pywin32-bugs] [ pywin32-Bugs-2132696 ] win32file.GetCommState incorrect handling of DCB

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

Bugs item #2132696, was opened at 2008-09-27 15:40
Message generated for change (Settings changed) made by jiaailun
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2132696&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: Deleted
Resolution: None
Priority: 5
Private: No
Submitted By: Alan Gardner (jiaailun)
Assigned to: Nobody/Anonymous (nobody)
Summary: win32file.GetCommState incorrect handling of DCB

Initial Comment:
I believe I have found a bug in win32file.GetCommState and win32file.SetCommState.  I have seen it in Python 2.4 and Python 2.5, running an older version of pywin32, as well as the current (212) version.  It exists in Win2k and WinXP.  I use pyserial 2.4 as a wrapper for the comm ports, though I believe the problem is in win32file.

The problem manifests itself when I try to open a com port in Python after having that port open in Procomm (an old, no longer supported terminal program).  I have only seen it happen with a particular brand of USB to serial converters (Edgeport, made by Digi).  In these conditions the python script will hang at the win32file.SetCommState() command, usually timing out after 5-30 seconds, and quitting with no error message.

After having done some probing I think I basically understand the problem, and have a workaround, but I lack the know-how to fix it where it should be fixed, in win32file.  When Procomm opens the port, it sets XoffLim to 16128 and the XonLim to 15872.  When my script (actually, serialwin32.py from pyserial) tries to open the port it first reads the DCB with GetCommState(), changes baud rate, etc in the local PyDCB object, and then tries to reconfigure the port with SetCommState().  

>From what I can tell, SetCommState won't accept a value for XoffLim or XonLim >4096.  For example, if I try to execute the following:
DCB.XoffLim = 16128
SetCommState(porthandle,DCB)

I get an exception: (87, 'SetCommState', 'The parameter is incorrect.')

However, if GetCommState gets a DCB which has XoffLim = 16128, and then that DCB is passed to SetCommState, the script hangs for several seconds before exiting without opening the port and with no error message.  For example, after having opened and closed the port in Procomm:

>>> DCB = GetCommState(porthandle)
>>> DCB.XoffLim
16128L
>>> SetCommState(porthandle,DCB)
(...... hangs here for several seconds ......)

If I set XoffLim and XonLim to values from 0-4096 before calling SetCommState, then it works fine.  For example, after having opened and closed the port in Procomm:

>>> DCB = GetCommState(porthandle)
>>> DCB.XoffLim = 128
>>> DCB.XonLim = 512
>>> SetCommState(porthandle,DCB)
>>>
This works fine, and I can go on to open the port normally.  I have incorporated this fix into serialwin32.py which is working for me now, but it's not an elegant solution.  I am still baffled by why
SetCommState limits Xon/XoffLim to 4096, and by what GetCommState does to the PyDCB to make it cause SetCommState to fail so dramatically.  I also don't understand why I only see this problem with the Edgeport USB converters, and not with several other USB converters or hardware serial ports.  Maybe someone with a more intimate understanding of Python and Win32 can come up with some answers.

Thank you
-Alan Gardner
Woods Hole Oceanographic Institution
Woods Hole, MA 02543

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

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

[pywin32-bugs] [ pywin32-Bugs-2132696 ] win32file.GetCommState incorrect handling of DCB

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

Bugs item #2132696, was opened at 2008-09-27 15:40
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2132696&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: Alan Gardner (jiaailun)
Assigned to: Nobody/Anonymous (nobody)
Summary: win32file.GetCommState incorrect handling of DCB

Initial Comment:
I believe I have found a bug in win32file.GetCommState and win32file.SetCommState.  I have seen it in Python 2.4 and Python 2.5, running an older version of pywin32, as well as the current (212) version.  It exists in Win2k and WinXP.  I use pyserial 2.4 as a wrapper for the comm ports, though I believe the problem is in win32file.

The problem manifests itself when I try to open a com port in Python after having that port open in Procomm (an old, no longer supported terminal program).  I have only seen it happen with a particular brand of USB to serial converters (Edgeport, made by Digi).  In these conditions the python script will hang at the win32file.SetCommState() command, usually timing out after 5-30 seconds, and quitting with no error message.

After having done some probing I think I basically understand the problem, and have a workaround, but I lack the know-how to fix it where it should be fixed, in win32file.  When Procomm opens the port, it sets XoffLim to 16128 and the XonLim to 15872.  When my script (actually, serialwin32.py from pyserial) tries to open the port it first reads the DCB with GetCommState(), changes baud rate, etc in the local PyDCB object, and then tries to reconfigure the port with SetCommState().  

>From what I can tell, SetCommState won't accept a value for XoffLim or XonLim >4096.  For example, if I try to execute the following:
DCB.XoffLim = 16128
SetCommState(porthandle,DCB)

I get an exception: (87, 'SetCommState', 'The parameter is incorrect.')

However, if GetCommState gets a DCB which has XoffLim = 16128, and then that DCB is passed to SetCommState, the script hangs for several seconds before exiting without opening the port and with no error message.  For example, after having opened and closed the port in Procomm:

>>> DCB = GetCommState(porthandle)
>>> DCB.XoffLim
16128L
>>> SetCommState(porthandle,DCB)
(...... hangs here for several seconds ......)

If I set XoffLim and XonLim to values from 0-4096 before calling SetCommState, then it works fine.  For example, after having opened and closed the port in Procomm:

>>> DCB = GetCommState(porthandle)
>>> DCB.XoffLim = 128
>>> DCB.XonLim = 512
>>> SetCommState(porthandle,DCB)
>>>
This works fine, and I can go on to open the port normally.  I have incorporated this fix into serialwin32.py which is working for me now, but it's not an elegant solution.  I am still baffled by why
SetCommState limits Xon/XoffLim to 4096, and by what GetCommState does to the PyDCB to make it cause SetCommState to fail so dramatically.  I also don't understand why I only see this problem with the Edgeport USB converters, and not with several other USB converters or hardware serial ports.  Maybe someone with a more intimate understanding of Python and Win32 can come up with some answers.

Thank you
-Alan Gardner
Woods Hole Oceanographic Institution
Woods Hole, MA 02543

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

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

[pywin32-bugs] [ pywin32-Bugs-2132639 ] win32file.GetCommState incorrect handling of DCB

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

Bugs item #2132639, was opened at 2008-09-27 14:56
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2132639&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: Alan Gardner (jiaailun)
Assigned to: Nobody/Anonymous (nobody)
Summary: win32file.GetCommState incorrect handling of DCB

Initial Comment:
I believe I have found a bug in win32file.GetCommState and win32file.SetCommState.  I have seen it in Python 2.4 and Python 2.5, running an older version of pywin32, as well as the current (212) version.  It exists in Win2k and WinXP.  I use pyserial 2.4 as a wrapper for the comm ports, though I believe the problem is in win32file.

The problem manifests itself when I try to open a com port in Python after having that port open in Procomm (an old, no longer supported terminal program).  I have only seen it happen with a particular brand of USB to serial converters (Edgeport, made by Digi).  In these conditions the python script will hang at the win32file.SetCommState() command, usually timing out after 5-30 seconds, and quitting with no error message.

After having done some probing I think I basically understand the problem, and have a workaround, but I lack the know-how to fix it where it should be fixed, in win32file.  When Procomm opens the port, it sets XoffLim to 16128 and the XonLim to 15872.  When my script (actually, serialwin32.py from pyserial) tries to open the port it first reads the DCB with GetCommState(), changes baud rate, etc in the local PyDCB object, and then tries to reconfigure the port with SetCommState().  

>From what I can tell, SetCommState won't accept a value for XoffLim or XonLim >4096.  For example, if I try to execute the following:
DCB.XoffLim = 16128
SetCommState(porthandle,DCB)

I get an exception: (87, 'SetCommState', 'The parameter is incorrect.')

However, if GetCommState gets a DCB which has XoffLim = 16128, and then that DCB is passed to SetCommState, the script hangs for several seconds before exiting without opening the port and with no error message.  For example, after having opened and closed the port in Procomm:

>>> DCB = GetCommState(porthandle)
>>> DCB.XoffLim
16128L
>>> SetCommState(porthandle,DCB)
(...... hangs here for several seconds ......)

If I set XoffLim and XonLim to values from 0-4096 before calling SetCommState, then it works fine.  For example, after having opened and closed the port in Procomm:

>>> DCB = GetCommState(porthandle)
>>> DCB.XoffLim = 128
>>> DCB.XonLim = 512
>>> SetCommState(porthandle,DCB)
>>>
This works fine, and I can go on to open the port normally.  I have incorporated this fix into serialwin32.py which is working for me now, but it's not an elegant solution.  I am still baffled by why
SetCommState limits Xon/XoffLim to 4096, and by what GetCommState does to the PyDCB to make it cause SetCommState to fail so dramatically.  I also don't understand why I only see this problem with the Edgeport USB converters, and not with several other USB converters or hardware serial ports.  Maybe someone with a more intimate understanding of Python and Win32 can come up with some answers.

Thank you
-Alan Gardner
Woods Hole Oceanographic Institution
Woods Hole, MA 02543

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

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

[pywin32-bugs] [ pywin32-Patches-1962146 ] win32file.TransmitFile and ConnectEx patch

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

Patches item #1962146, was opened at 2008-05-11 22:06
Message generated for change (Comment added) made by rupole
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1962146&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: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: ionel (ionel_mc)
Assigned to: Nobody/Anonymous (nobody)
Summary: win32file.TransmitFile and ConnectEx patch

Initial Comment:
sample usage:

import win32file, socket, pywintypes
s = socket.socket()
f = file('somefile','rb')
s.connect(('192.168.111.128',10002))
ol = pywintypes.OVERLAPPED()
print win32file.TransmitFile(s, win32file._get_osfhandle(f.fileno()), 0, 0, ol, 0, "prepended data", "appended data")
length = win32file.GetOverlappedResult(s.fileno(), ol, 1)
print length

I hope I haven't done the wrong thing but for the sake of simplicity I'm providing a patch the includes the previous ConnectEx patch (hopefully it'll get accepted :)

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

>Comment By: Roger Upole (rupole)
Date: 2008-09-25 07:20

Message:
There's another possible issue with the way getaddrinfo is used.
It returns a linked list of structures, rather than a single address.
This leaves no way to select which sockaddr will be passed to
ConnectEx.  It might be better to accept a tuple as produced by
the builtin socket.getaddrinfo() so that the caller can choose.



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

Comment By: ionel (ionel_mc)
Date: 2008-09-07 14:40

Message:
Logged In: YES 
user_id=1189761
Originator: YES

File Added: win32file.i-9.patch

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

Comment By: ionel (ionel_mc)
Date: 2008-05-27 18:56

Message:
Logged In: YES 
user_id=1189761
Originator: YES

File Added: win32file.i-8.patch

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

Comment By: Roger Upole (rupole)
Date: 2008-05-27 18:27

Message:
Logged In: YES 
user_id=771074
Originator: NO

Regarding the way getaddrinfo is called, it appears that the
family, socket type, and protocol are hardcoded.  Shouldn't it be
using the values from the Python socket object, since these are
specified when it's created ?

Also, Unicode is accepted for the host, but not the port.  This
isn't a show stopper, but it would be better to be consistent.


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

Comment By: ionel (ionel_mc)
Date: 2008-05-13 13:27

Message:
Logged In: YES 
user_id=1189761
Originator: YES

File Added: win32file.i-7.patch

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

Comment By: ionel (ionel_mc)
Date: 2008-05-13 13:16

Message:
Logged In: YES 
user_id=1189761
Originator: YES

File Added: win32file.i-6.patch

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

Comment By: ionel (ionel_mc)
Date: 2008-05-13 10:51

Message:
Logged In: YES 
user_id=1189761
Originator: YES

sure, close it.
I'll post a message on the list in a few moments.

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

Comment By: Mark Hammond (mhammond)
Date: 2008-05-13 08:22

Message:
Logged In: YES 
user_id=14198
Originator: NO

Sorry for the confusion (and for missing the test!)  To be clear, the
"problem" is simply my lack of cycles to try and digest what exactly the
API allows for versus what your patch does.  I'm not suggesting anything
you are doing is wrong, just that its not immediately obvious to me (hence
my comments re TransmitFile, which a patch for *is* likely to be "obvious"
- but as you mentioned you combined them, I didn't look closely).  You are
correct though that the arg handling is my primary concern, and if you are
really keen to get this in ASAP, would you be so kind as to mail the
python-win32 list asking for other comments and pointing at this bug? 
There are a few people there who's opinion I would defer to - and they may
have more time at the moment to have a look (I'm really hoping to get build
211 out any day now!)

Also, if you are intent on getting these in the same build, should I close
the other patch?

Thanks!

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

Comment By: ionel (ionel_mc)
Date: 2008-05-13 05:09

Message:
Logged In: YES 
user_id=1189761
Originator: YES

I'd rather have them both in the same build. Also, on the arg handling
thing I imagine you didn't like the addrinfo stuff that I did there. It
might look like a mess but i have looked in the socketmodule.c from the
python dist and there's nothing i can use from there (there is a
getsockaddrarg that is used in the connects, it does about the same thing
that i do but on a larger _messy_ scale with more cases like unix sockets
that don't apply here).

Um, I did attach a test_transmitfile.py - should that code really be in
test_win32file.py ?


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

Comment By: Mark Hammond (mhammond)
Date: 2008-05-13 01:29

Message:
Logged In: YES 
user_id=14198
Originator: NO

Thanks.  Unfortunately, I'm going to need to research the ConnextEx stuff
a little more to convince myself the arg handling is reasonable - but it
will be accepted one way or another :)  However, as TransmitFile is likely
to be a much simpler patch, if you supplied a patch for that alone
(including tests ideally - see test_win32file.py for stuff you can maybe
borrow?) I could get it in much sooner (and it would therefore be possible
to make build 211).  Otherwise I'll wrap both this and your ConnectEx
patches up when I find time to tweak.

Thanks again.

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

Comment By: ionel (ionel_mc)
Date: 2008-05-11 22:06

Message:
Logged In: YES 
user_id=1189761
Originator: YES

File Added: test_transmitfile.py

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

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

[pywin32-bugs] [ pywin32-Bugs-2118863 ] Error compiling

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

Bugs item #2118863, was opened at 2008-09-18 23:59
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2118863&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: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Farzin Shakib (acusim)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error compiling

Initial Comment:
I just obtained the pywin32-212.zip and attempted to build it, but got the following error:

$ python setup.py install 
Building pywin32 2.4.212.0
running install
running build
running build_py
running build_ext
Found version 0x500 in C:\Program Files\Microsoft Visual Studio .NET 2003\VC7\PlatformSDK\include\WinResrc.h
building 'pywintypes' extension
c:\Program Files\Microsoft Visual Studio .NET 2003\VC7\BIN\cl.exe /c /nologo /Ob2ty /MD /W3 /EHsc /DNDEBUG -DDISTUTILS_BUILD -Icom/win32com/src/include -Iwin32/src -Ic:\Acusim\Win\V1.3\base\include -Ic:\Acusim\Win\V1.3\base\PC /Tpwin32\src\PyACL.cpp /Fobuild\temp.win32-2.4\Release\win32\src\PyACL.obj -DBUILD_PYWINTYPES /YXPyWinTypes.h /Fpbuild\temp.win32-2.4\Release\pywintypes.pch /Zi /Fdbuild\temp.win32-2.4\Release\pywintypes_vc.pdb /EHsc /DMFC_OCC_IMPL_H=\"..\src\occimpl.h\"
PyACL.cpp
win32\src\PyACL.cpp(4) : fatal error C1083: Cannot open precompiled header file: 'build\temp.win32-2.4\Release\pywintypes.pch': The process cannot access the file because it is being used by another process.

This is done on a Windows 2000.

Any ideas how to resolve this issue?

Farzin



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

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

[pywin32-bugs] [ pywin32-Feature Requests-2103779 ] Add Unicode versions for Registry functions

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

Feature Requests item #2103779, was opened at 2008-09-10 15:39
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551957&aid=2103779&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: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Wim (wim_h)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add Unicode versions for Registry functions

Initial Comment:
pywin32 build 211 has additional functions added for Unicode strings, like: RegEnumKeyExW, RegQueryInfoKeyW.

However, RegOpenKeyExW and RegQueryValueExW are missing... causing problems on Japanese and Chinese Windows versions.


Please, please add RegOpenKeyExW and RegQueryValueExW...



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

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

[pywin32-bugs] [ pywin32-Patches-1962146 ] win32file.TransmitFile and ConnectEx patch

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

Patches item #1962146, was opened at 2008-05-12 06:06
Message generated for change (Comment added) made by ionel_mc
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1962146&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: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: ionel (ionel_mc)
Assigned to: Nobody/Anonymous (nobody)
Summary: win32file.TransmitFile and ConnectEx patch

Initial Comment:
sample usage:

import win32file, socket, pywintypes
s = socket.socket()
f = file('somefile','rb')
s.connect(('192.168.111.128',10002))
ol = pywintypes.OVERLAPPED()
print win32file.TransmitFile(s, win32file._get_osfhandle(f.fileno()), 0, 0, ol, 0, "prepended data", "appended data")
length = win32file.GetOverlappedResult(s.fileno(), ol, 1)
print length

I hope I haven't done the wrong thing but for the sake of simplicity I'm providing a patch the includes the previous ConnectEx patch (hopefully it'll get accepted :)

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

>Comment By: ionel (ionel_mc)
Date: 2008-09-07 22:40

Message:
Logged In: YES 
user_id=1189761
Originator: YES

File Added: win32file.i-9.patch

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

Comment By: ionel (ionel_mc)
Date: 2008-05-28 02:56

Message:
Logged In: YES 
user_id=1189761
Originator: YES

File Added: win32file.i-8.patch

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

Comment By: Roger Upole (rupole)
Date: 2008-05-28 02:27

Message:
Logged In: YES 
user_id=771074
Originator: NO

Regarding the way getaddrinfo is called, it appears that the
family, socket type, and protocol are hardcoded.  Shouldn't it be
using the values from the Python socket object, since these are
specified when it's created ?

Also, Unicode is accepted for the host, but not the port.  This
isn't a show stopper, but it would be better to be consistent.


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

Comment By: ionel (ionel_mc)
Date: 2008-05-13 21:27

Message:
Logged In: YES 
user_id=1189761
Originator: YES

File Added: win32file.i-7.patch

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

Comment By: ionel (ionel_mc)
Date: 2008-05-13 21:16

Message:
Logged In: YES 
user_id=1189761
Originator: YES

File Added: win32file.i-6.patch

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

Comment By: ionel (ionel_mc)
Date: 2008-05-13 18:51

Message:
Logged In: YES 
user_id=1189761
Originator: YES

sure, close it.
I'll post a message on the list in a few moments.

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

Comment By: Mark Hammond (mhammond)
Date: 2008-05-13 16:22

Message:
Logged In: YES 
user_id=14198
Originator: NO

Sorry for the confusion (and for missing the test!)  To be clear, the
"problem" is simply my lack of cycles to try and digest what exactly the
API allows for versus what your patch does.  I'm not suggesting anything
you are doing is wrong, just that its not immediately obvious to me (hence
my comments re TransmitFile, which a patch for *is* likely to be "obvious"
- but as you mentioned you combined them, I didn't look closely).  You are
correct though that the arg handling is my primary concern, and if you are
really keen to get this in ASAP, would you be so kind as to mail the
python-win32 list asking for other comments and pointing at this bug? 
There are a few people there who's opinion I would defer to - and they may
have more time at the moment to have a look (I'm really hoping to get build
211 out any day now!)

Also, if you are intent on getting these in the same build, should I close
the other patch?

Thanks!

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

Comment By: ionel (ionel_mc)
Date: 2008-05-13 13:09

Message:
Logged In: YES 
user_id=1189761
Originator: YES

I'd rather have them both in the same build. Also, on the arg handling
thing I imagine you didn't like the addrinfo stuff that I did there. It
might look like a mess but i have looked in the socketmodule.c from the
python dist and there's nothing i can use from there (there is a
getsockaddrarg that is used in the connects, it does about the same thing
that i do but on a larger _messy_ scale with more cases like unix sockets
that don't apply here).

Um, I did attach a test_transmitfile.py - should that code really be in
test_win32file.py ?


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

Comment By: Mark Hammond (mhammond)
Date: 2008-05-13 09:29

Message:
Logged In: YES 
user_id=14198
Originator: NO

Thanks.  Unfortunately, I'm going to need to research the ConnextEx stuff
a little more to convince myself the arg handling is reasonable - but it
will be accepted one way or another :)  However, as TransmitFile is likely
to be a much simpler patch, if you supplied a patch for that alone
(including tests ideally - see test_win32file.py for stuff you can maybe
borrow?) I could get it in much sooner (and it would therefore be possible
to make build 211).  Otherwise I'll wrap both this and your ConnectEx
patches up when I find time to tweak.

Thanks again.

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

Comment By: ionel (ionel_mc)
Date: 2008-05-12 06:06

Message:
Logged In: YES 
user_id=1189761
Originator: YES

File Added: test_transmitfile.py

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

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

[pywin32-bugs] [ pywin32-Bugs-2052253 ] Problem calling WMI method

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

Bugs item #2052253, was opened at 2008-08-15 02:06
Message generated for change (Comment added) made by ramong
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2052253&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: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ramon Garcia (ramong)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem calling WMI method

Initial Comment:
An exception is issued if a WMI method call is attempted. The following code shows it.

	wmiservice = Dispatch("WbemScripting.SWbemLocator")
	wmi = wmiservice.ConnectServer("localhost", "root\cimv2")
	moniker = r"winmgmts:" \
		"{impersonationLevel=impersonate,(Security,Backup)}!\\\\" + \
		computer + r"\root\cimv2"
	wmi = GetObject(moniker)
	log_files = wmi.ExecQuery \
		("SELECT * FROM Win32_NTEventLogFile")
	for log_file in log_files:
		base = re.sub("event$", "", log_file.FileName)
		backup_filename = base + u".evt"
		log_file.BackupEventlog(backup_filename)

The following exception is raised

  File "c:\python25\lib\site-packages\win32com\client\dynamic.py", line 495, in __getattr__
    raise pythoncom.com_error, details
com_error: (-2147352567, 'Ocurri\xf3 una excepci\xf3n.', (0, u'SWbemObjectEx', u'Invalid parameter ', None, 0, -2147217400), None)


We traced this problem to WMI issing an unexecpected return code when it is attempted to get a property that is a method. The function __getattr__ in class CDispatch tries to resolve an attribute request as an attribute first, and then, if an error is raisen by COM, as a method:

if details[0] in ERRORS_BAD_CONTEXT:
    # May be a method.
    self._olerepr_.mapFuncs[attr] = retEntry
    return self._make_method_(attr)
raise pythoncom.com_error, details

But the list of such errors seems not be enough. WMI is returning error code winerror.DISP_E_EXCEPTION in this case. We workarounded the problem adding winerror.DISP_E_EXCEPTION to ERRORS_BAD_CONTEXT in dynamic.py, but perhaps there is a more specific solution.

Best regards

Ramon Garcia
ra...@cn...
Comisin Nacional de Mercado de Valores

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

>Comment By: Ramon Garcia (ramong)
Date: 2008-09-07 07:49

Message:
Logged In: YES 
user_id=2163452
Originator: YES

Thanks for the help. I will try to prepare a patch.

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

Comment By: Mark Hammond (mhammond)
Date: 2008-09-04 15:01

Message:
Logged In: YES 
user_id=14198
Originator: NO

Excellent - nice find - come to think of it, I didn't actually google,
just looked locally in the platform sdk.  If you can come up with a patch
I'd be happy to check it in, otherwise it will need to wait until I get to
it (but hopefully before the next release).  Note I'd be happy for the
patch to include a "local" definition of that error code - eg:

WBEM_E_INVALID_PARAMETER = -2147217400

at the top of the file would be fine (although a patch including all WBEM_
error codes in winerror or somewhere else suitable might be even better ;)

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

Comment By: Ramon Garcia (ramong)
Date: 2008-09-04 14:42

Message:
Logged In: YES 
user_id=2163452
Originator: YES

The constant HRESULT -2147217400 (hexadecimal 0x80041008) is
WBEM_E_INVALID_PARAMETER "One of the parameters to the call is not
correct"

http://msdn.microsoft.com/en-us/library/aa394559.aspx

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

Comment By: Mark Hammond (mhammond)
Date: 2008-09-04 04:18

Message:
Logged In: YES 
user_id=14198
Originator: NO

We should look inside the exception object if we don't already - but we
still need to find a "well known" error code in it.  I can't find an error
definition for -2147217400, but if we can show it is used exclusively by
WMI to mean "invalid param", then I'd be happy to add it to the list.

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

Comment By: Roger Upole (rupole)
Date: 2008-09-04 02:49

Message:
Logged In: YES 
user_id=771074
Originator: NO

The main problem is that there are any number of reasons why
that particular error may be returned, and any number of error codes
that might be returned when an object does not receive required
parameters.  No matter how specific you attempt to make it, it will
still be too general.  The best that can be done is to make a specific
wrapper just for WMI objects.

Also, as demonstrated WMI does not give you a way to actually
retrieve a method object thru normal Invoke semantics.  This is why it
provides Methods_ and ExecMethod_ for dynamic languages such as
Python.  For example: log_file.Methods_('BackupEventlog')

Tim Golden's WMI module uses these special methods to hide the
details so that you can use natural syntax.
I highly recommend it.



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

Comment By: Ramon Garcia (ramong)
Date: 2008-09-04 02:03

Message:
Logged In: YES 
user_id=2163452
Originator: YES

Thanks for looking at this issue.

In the interest of easy of use I think that pythoncom should behave as
close as posible to windows Wscript interpreter, because it is what the
script developer expects. object.method(arg) would work like under
WScript.

The solution that we are using, adding winerror.DISP_E_EXCEPTION to
ERRORS_BAD_CONTEXT is somewhat quick and dirty, but works for us. What I
would do would be to add a more specific check, like checking that if
winerror.DISP_E_EXCEPTION and the errorcode -2147217400 inside the wrapped
exception object, and if that happens then make object.method return an
object that can be called. The only risk that I can see in our method is
the risk of breaking working code. Using a more specific solution, it
should not have any risk.

(Excuse me if there are any mistakes in this comment. I don't have the
machine at hand, I and writting from what I can remember).


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

Comment By: Roger Upole (rupole)
Date: 2008-09-04 00:05

Message:
Logged In: YES 
user_id=771074
Originator: NO

I think the underlying problem here is that WMI does not make a distiction
between
asking for a method and executing it. Both of these produce the error you
describe:

log_file._oleobj_.Invoke(id, 0, pythoncom.DISPATCH_METHOD, True)
log_file._oleobj_.Invoke(id, 0, pythoncom.DISPATCH_PROPERTYGET, True)

And both succeed if you pass a filename parameter as an extra arg.
This indicates that the error is not produced by attempting to get the
attribute,
but rather from actually calling the method without a filename parameter.

You may want to look at using Tim Golden's WMI module, which provides a
much
easier to use wrapper for these objects.
http://timgolden.me.uk/python/wmi.html




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

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

[pywin32-bugs] [ pywin32-Bugs-2090927 ] interactive window ignores Insert spaces

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

Bugs item #2090927, was opened at 2008-09-03 05:02
Message generated for change (Comment added) made by ramrom
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2090927&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: pythonwin
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: bob gailer (ramrom)
Assigned to: Nobody/Anonymous (nobody)
Summary: interactive window ignores Insert spaces

Initial Comment:
Tabs entered in interactive window are not converted to spaces when Insert spaces has been selected. This has not been a problem per se until copy code without prompts arrived. 

Suggest convert tabs either when entered or in the clipboard when code is copied.

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

>Comment By: bob gailer (ramrom)
Date: 2008-09-04 20:32

Message:
Logged In: YES 
user_id=587593
Originator: YES

Yes I am not debating the interactive window use of tabs just complaining
that copy-paste into a script that uses spaces leaves a bunch of tabs to
clean up. I want the paste process to resolve the tabs.

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

Comment By: Roger Upole (rupole)
Date: 2008-09-03 14:45

Message:
Logged In: YES 
user_id=771074
Originator: NO

Going back to build 209, I still get only tabs in the interactive window.
Pythonwin uses Idle's built-in tab/space conversions, and indeed Idle
shows the same behaviour.
According to this issue on the python tracker:

http://mail.python.org/pipermail/python-bugs-list/2006-October/035603.html

it's configured to always use tabs in the interactive window now.



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

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

[pywin32-bugs] [ pywin32-Bugs-2052253 ] Problem calling WMI method

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

Bugs item #2052253, was opened at 2008-08-15 10:06
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2052253&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: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ramon Garcia (ramong)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem calling WMI method

Initial Comment:
An exception is issued if a WMI method call is attempted. The following code shows it.

	wmiservice = Dispatch("WbemScripting.SWbemLocator")
	wmi = wmiservice.ConnectServer("localhost", "root\cimv2")
	moniker = r"winmgmts:" \
		"{impersonationLevel=impersonate,(Security,Backup)}!\\\\" + \
		computer + r"\root\cimv2"
	wmi = GetObject(moniker)
	log_files = wmi.ExecQuery \
		("SELECT * FROM Win32_NTEventLogFile")
	for log_file in log_files:
		base = re.sub("event$", "", log_file.FileName)
		backup_filename = base + u".evt"
		log_file.BackupEventlog(backup_filename)

The following exception is raised

  File "c:\python25\lib\site-packages\win32com\client\dynamic.py", line 495, in __getattr__
    raise pythoncom.com_error, details
com_error: (-2147352567, 'Ocurri\xf3 una excepci\xf3n.', (0, u'SWbemObjectEx', u'Invalid parameter ', None, 0, -2147217400), None)


We traced this problem to WMI issing an unexecpected return code when it is attempted to get a property that is a method. The function __getattr__ in class CDispatch tries to resolve an attribute request as an attribute first, and then, if an error is raisen by COM, as a method:

if details[0] in ERRORS_BAD_CONTEXT:
    # May be a method.
    self._olerepr_.mapFuncs[attr] = retEntry
    return self._make_method_(attr)
raise pythoncom.com_error, details

But the list of such errors seems not be enough. WMI is returning error code winerror.DISP_E_EXCEPTION in this case. We workarounded the problem adding winerror.DISP_E_EXCEPTION to ERRORS_BAD_CONTEXT in dynamic.py, but perhaps there is a more specific solution.

Best regards

Ramon Garcia
ra...@cn...
Comisión Nacional de Mercado de Valores

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

>Comment By: Mark Hammond (mhammond)
Date: 2008-09-04 23:01

Message:
Logged In: YES 
user_id=14198
Originator: NO

Excellent - nice find - come to think of it, I didn't actually google,
just looked locally in the platform sdk.  If you can come up with a patch
I'd be happy to check it in, otherwise it will need to wait until I get to
it (but hopefully before the next release).  Note I'd be happy for the
patch to include a "local" definition of that error code - eg:

WBEM_E_INVALID_PARAMETER = -2147217400

at the top of the file would be fine (although a patch including all WBEM_
error codes in winerror or somewhere else suitable might be even better ;)

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

Comment By: Ramon Garcia (ramong)
Date: 2008-09-04 22:42

Message:
Logged In: YES 
user_id=2163452
Originator: YES

The constant HRESULT -2147217400 (hexadecimal 0x80041008) is
WBEM_E_INVALID_PARAMETER "One of the parameters to the call is not
correct"

http://msdn.microsoft.com/en-us/library/aa394559.aspx

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

Comment By: Mark Hammond (mhammond)
Date: 2008-09-04 12:18

Message:
Logged In: YES 
user_id=14198
Originator: NO

We should look inside the exception object if we don't already - but we
still need to find a "well known" error code in it.  I can't find an error
definition for -2147217400, but if we can show it is used exclusively by
WMI to mean "invalid param", then I'd be happy to add it to the list.

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

Comment By: Roger Upole (rupole)
Date: 2008-09-04 10:49

Message:
Logged In: YES 
user_id=771074
Originator: NO

The main problem is that there are any number of reasons why
that particular error may be returned, and any number of error codes
that might be returned when an object does not receive required
parameters.  No matter how specific you attempt to make it, it will
still be too general.  The best that can be done is to make a specific
wrapper just for WMI objects.

Also, as demonstrated WMI does not give you a way to actually
retrieve a method object thru normal Invoke semantics.  This is why it
provides Methods_ and ExecMethod_ for dynamic languages such as
Python.  For example: log_file.Methods_('BackupEventlog')

Tim Golden's WMI module uses these special methods to hide the
details so that you can use natural syntax.
I highly recommend it.



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

Comment By: Ramon Garcia (ramong)
Date: 2008-09-04 10:03

Message:
Logged In: YES 
user_id=2163452
Originator: YES

Thanks for looking at this issue.

In the interest of easy of use I think that pythoncom should behave as
close as posible to windows Wscript interpreter, because it is what the
script developer expects. object.method(arg) would work like under
WScript.

The solution that we are using, adding winerror.DISP_E_EXCEPTION to
ERRORS_BAD_CONTEXT is somewhat quick and dirty, but works for us. What I
would do would be to add a more specific check, like checking that if
winerror.DISP_E_EXCEPTION and the errorcode -2147217400 inside the wrapped
exception object, and if that happens then make object.method return an
object that can be called. The only risk that I can see in our method is
the risk of breaking working code. Using a more specific solution, it
should not have any risk.

(Excuse me if there are any mistakes in this comment. I don't have the
machine at hand, I and writting from what I can remember).


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

Comment By: Roger Upole (rupole)
Date: 2008-09-04 08:05

Message:
Logged In: YES 
user_id=771074
Originator: NO

I think the underlying problem here is that WMI does not make a distiction
between
asking for a method and executing it. Both of these produce the error you
describe:

log_file._oleobj_.Invoke(id, 0, pythoncom.DISPATCH_METHOD, True)
log_file._oleobj_.Invoke(id, 0, pythoncom.DISPATCH_PROPERTYGET, True)

And both succeed if you pass a filename parameter as an extra arg.
This indicates that the error is not produced by attempting to get the
attribute,
but rather from actually calling the method without a filename parameter.

You may want to look at using Tim Golden's WMI module, which provides a
much
easier to use wrapper for these objects.
http://timgolden.me.uk/python/wmi.html




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

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

[pywin32-bugs] [ pywin32-Bugs-2052253 ] Problem calling WMI method

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

Bugs item #2052253, was opened at 2008-08-15 02:06
Message generated for change (Comment added) made by ramong
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2052253&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: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ramon Garcia (ramong)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem calling WMI method

Initial Comment:
An exception is issued if a WMI method call is attempted. The following code shows it.

	wmiservice = Dispatch("WbemScripting.SWbemLocator")
	wmi = wmiservice.ConnectServer("localhost", "root\cimv2")
	moniker = r"winmgmts:" \
		"{impersonationLevel=impersonate,(Security,Backup)}!\\\\" + \
		computer + r"\root\cimv2"
	wmi = GetObject(moniker)
	log_files = wmi.ExecQuery \
		("SELECT * FROM Win32_NTEventLogFile")
	for log_file in log_files:
		base = re.sub("event$", "", log_file.FileName)
		backup_filename = base + u".evt"
		log_file.BackupEventlog(backup_filename)

The following exception is raised

  File "c:\python25\lib\site-packages\win32com\client\dynamic.py", line 495, in __getattr__
    raise pythoncom.com_error, details
com_error: (-2147352567, 'Ocurri\xf3 una excepci\xf3n.', (0, u'SWbemObjectEx', u'Invalid parameter ', None, 0, -2147217400), None)


We traced this problem to WMI issing an unexecpected return code when it is attempted to get a property that is a method. The function __getattr__ in class CDispatch tries to resolve an attribute request as an attribute first, and then, if an error is raisen by COM, as a method:

if details[0] in ERRORS_BAD_CONTEXT:
    # May be a method.
    self._olerepr_.mapFuncs[attr] = retEntry
    return self._make_method_(attr)
raise pythoncom.com_error, details

But the list of such errors seems not be enough. WMI is returning error code winerror.DISP_E_EXCEPTION in this case. We workarounded the problem adding winerror.DISP_E_EXCEPTION to ERRORS_BAD_CONTEXT in dynamic.py, but perhaps there is a more specific solution.

Best regards

Ramon Garcia
ra...@cn...
Comisin Nacional de Mercado de Valores

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

>Comment By: Ramon Garcia (ramong)
Date: 2008-09-04 14:42

Message:
Logged In: YES 
user_id=2163452
Originator: YES

The constant HRESULT -2147217400 (hexadecimal 0x80041008) is
WBEM_E_INVALID_PARAMETER "One of the parameters to the call is not
correct"

http://msdn.microsoft.com/en-us/library/aa394559.aspx

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

Comment By: Mark Hammond (mhammond)
Date: 2008-09-04 04:18

Message:
Logged In: YES 
user_id=14198
Originator: NO

We should look inside the exception object if we don't already - but we
still need to find a "well known" error code in it.  I can't find an error
definition for -2147217400, but if we can show it is used exclusively by
WMI to mean "invalid param", then I'd be happy to add it to the list.

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

Comment By: Roger Upole (rupole)
Date: 2008-09-04 02:49

Message:
Logged In: YES 
user_id=771074
Originator: NO

The main problem is that there are any number of reasons why
that particular error may be returned, and any number of error codes
that might be returned when an object does not receive required
parameters.  No matter how specific you attempt to make it, it will
still be too general.  The best that can be done is to make a specific
wrapper just for WMI objects.

Also, as demonstrated WMI does not give you a way to actually
retrieve a method object thru normal Invoke semantics.  This is why it
provides Methods_ and ExecMethod_ for dynamic languages such as
Python.  For example: log_file.Methods_('BackupEventlog')

Tim Golden's WMI module uses these special methods to hide the
details so that you can use natural syntax.
I highly recommend it.



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

Comment By: Ramon Garcia (ramong)
Date: 2008-09-04 02:03

Message:
Logged In: YES 
user_id=2163452
Originator: YES

Thanks for looking at this issue.

In the interest of easy of use I think that pythoncom should behave as
close as posible to windows Wscript interpreter, because it is what the
script developer expects. object.method(arg) would work like under
WScript.

The solution that we are using, adding winerror.DISP_E_EXCEPTION to
ERRORS_BAD_CONTEXT is somewhat quick and dirty, but works for us. What I
would do would be to add a more specific check, like checking that if
winerror.DISP_E_EXCEPTION and the errorcode -2147217400 inside the wrapped
exception object, and if that happens then make object.method return an
object that can be called. The only risk that I can see in our method is
the risk of breaking working code. Using a more specific solution, it
should not have any risk.

(Excuse me if there are any mistakes in this comment. I don't have the
machine at hand, I and writting from what I can remember).


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

Comment By: Roger Upole (rupole)
Date: 2008-09-04 00:05

Message:
Logged In: YES 
user_id=771074
Originator: NO

I think the underlying problem here is that WMI does not make a distiction
between
asking for a method and executing it. Both of these produce the error you
describe:

log_file._oleobj_.Invoke(id, 0, pythoncom.DISPATCH_METHOD, True)
log_file._oleobj_.Invoke(id, 0, pythoncom.DISPATCH_PROPERTYGET, True)

And both succeed if you pass a filename parameter as an extra arg.
This indicates that the error is not produced by attempting to get the
attribute,
but rather from actually calling the method without a filename parameter.

You may want to look at using Tim Golden's WMI module, which provides a
much
easier to use wrapper for these objects.
http://timgolden.me.uk/python/wmi.html




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

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

[pywin32-bugs] [ pywin32-Bugs-1799934 ] easy_install silently fails

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

Bugs item #1799934, was opened at 2007-09-21 22:29
Message generated for change (Comment added) made by htgoebel
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1799934&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: Zooko O'Whielacronx (zooko)
Assigned to: Nobody/Anonymous (nobody)
Summary: easy_install silently fails

Initial Comment:
If I install pywin32 by executing pywin32-210.win32-py2.5.exe , it works.

If I run "easy_install pywin32" then it claims that it is downloading and installing pywin32-210.win32-py2.5.exe , and after a while it claims that it has successfully installed it, but an attempt to use pywin32 yields errors like this:

$ python -c 'import win32process'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: DLL load failed: The specified module could not be found.


I'm not sure whether this should be considered a bug in pywin32 or in easy_install, or both.

Regards,

Zooko

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

Comment By: Hartmut Goebel (htgoebel)
Date: 2008-09-04 12:29

Message:
Logged In: YES 
user_id=376953
Originator: NO

There are actually two problems:

1) pywin32_postinstall.py can not be run manually when using eggs since it
does not use pkg_resources.

   This is fixed by patch 2092722
  
<http://sourceforge.net/tracker/index.php?func=detail&aid=2092722&group_id=78018&atid=551956>.

2) easy_install does not run pywin32_postinstall.py. It looks like there
is no mechanism to do this.

   This problem has been filed at
<http://bugs.python.org/setuptools/issue18>



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

Comment By: Zooko O'Whielacronx (zooko)
Date: 2008-06-02 22:31

Message:
Logged In: YES 
user_id=52562
Originator: YES

This is the ticket on the setuptools issue tracker to track the progress
of fixing this in setuptools:

http://bugs.python.org/setuptools/issue18

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

Comment By: Mark Hammond (mhammond)
Date: 2008-05-03 03:30

Message:
Logged In: YES 
user_id=14198
Originator: NO

That installer is quite recent - you may need to get the latest setuptools
rather than the latest pywin32.  Either way, just grab the CVS sources,
install the Vista SDK, and execute "setup.py" - to get some basic
instructions printed.

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

Comment By: Zooko O'Whielacronx (zooko)
Date: 2008-05-03 02:56

Message:
Logged In: YES 
user_id=52562
Originator: YES

Well, I'm afraid that
starship.python.net/crew/mhammond/pywin32-210.9.win32-py2.5.exe doesn't
work with the current setuptools -- setuptools v0.6 final.  Could you tell
me how to build pywin32 packages from CVS so I can experiment?  Thanks.

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

Comment By: Mark Hammond (mhammond)
Date: 2008-05-03 02:39

Message:
Logged In: YES 
user_id=14198
Originator: NO

Try starship.python.net/crew/mhammond/pywin32-210.9.win32-py2.5.exe.  Note
I'm not sure of the status of the bug I referred to - ie, I'm not sure if a
released version of setuptools has the bug fixed (but I assume you are
ontop of that :)

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

Comment By: Zooko O'Whielacronx (zooko)
Date: 2008-05-02 19:48

Message:
Logged In: YES 
user_id=52562
Originator: YES

Hi, I went to test this so I could definitely close this bug, but it turns
out that pywin32 build 211 isn't downloadable yet.


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

Comment By: SourceForge Robot (sf-robot)
Date: 2008-04-23 04:20

Message:
Logged In: YES 
user_id=1312539
Originator: NO

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

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

Comment By: Mark Hammond (mhammond)
Date: 2008-04-08 23:20

Message:
Logged In: YES 
user_id=14198
Originator: NO

I believe PJE recently fixed a bug in setuptools that was causing problems
with pywin32 as an egg.  Please try again after build 211 is released.

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

Comment By: Zooko O'Whielacronx (zooko)
Date: 2008-01-25 15:17

Message:
Logged In: YES 
user_id=52562
Originator: YES


See also:

http://mail.python.org/pipermail/distutils-sig/2007-July/007823.html


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

Comment By: Mark Hammond (mhammond)
Date: 2007-10-01 01:33

Message:
Logged In: YES 
user_id=14198
Originator: NO

I've no idea - that too is an easy_install question.  I've never used
easy_install to install pywin32, and I've never recommended anyone else do
it either.

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

Comment By: Zooko O'Whielacronx (zooko)
Date: 2007-10-01 00:57

Message:
Logged In: YES 
user_id=52562
Originator: YES

I will see if I can make the pywin32_postinstall.py stuff get done
automatically upon easy_install.

In the meantime, is there some way to make this failure loud instead of
silent?  How do you tell easy_install: yes, there is a package in the
expected format (.zip) in the expected place (pypi), but it isn't actually
going to work?


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

Comment By: Mark Hammond (mhammond)
Date: 2007-09-22 01:57

Message:
Logged In: YES 
user_id=14198
Originator: NO

After install, pywin32_postinstall.py needs to be run, but ezsetup
apparently does not provide a facility to do that.  You may like to ask
them for such a facility.

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

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

[pywin32-bugs] [ pywin32-Patches-2092722 ] pywin32_postinstall.py fails when installing an egg

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

Patches item #2092722, was opened at 2008-09-04 10:09
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=2092722&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: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Hartmut Goebel (htgoebel)
Assigned to: Nobody/Anonymous (nobody)
Summary: pywin32_postinstall.py fails when installing an egg

Initial Comment:
pywin32_postinstall.py fails when installing an egg.

I figured out that LoadSystemModule wants to load
C:\Python25\Lib\site-packages\pywin32_system32\pywintypes25.dll
which doe not exist in an egg.

Enclosed patch used pkg_resources to get the correct directory.

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

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

[pywin32-bugs] [ pywin32-Bugs-2052253 ] Problem calling WMI method

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

Bugs item #2052253, was opened at 2008-08-15 10:06
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2052253&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: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ramon Garcia (ramong)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem calling WMI method

Initial Comment:
An exception is issued if a WMI method call is attempted. The following code shows it.

	wmiservice = Dispatch("WbemScripting.SWbemLocator")
	wmi = wmiservice.ConnectServer("localhost", "root\cimv2")
	moniker = r"winmgmts:" \
		"{impersonationLevel=impersonate,(Security,Backup)}!\\\\" + \
		computer + r"\root\cimv2"
	wmi = GetObject(moniker)
	log_files = wmi.ExecQuery \
		("SELECT * FROM Win32_NTEventLogFile")
	for log_file in log_files:
		base = re.sub("event$", "", log_file.FileName)
		backup_filename = base + u".evt"
		log_file.BackupEventlog(backup_filename)

The following exception is raised

  File "c:\python25\lib\site-packages\win32com\client\dynamic.py", line 495, in __getattr__
    raise pythoncom.com_error, details
com_error: (-2147352567, 'Ocurri\xf3 una excepci\xf3n.', (0, u'SWbemObjectEx', u'Invalid parameter ', None, 0, -2147217400), None)


We traced this problem to WMI issing an unexecpected return code when it is attempted to get a property that is a method. The function __getattr__ in class CDispatch tries to resolve an attribute request as an attribute first, and then, if an error is raisen by COM, as a method:

if details[0] in ERRORS_BAD_CONTEXT:
    # May be a method.
    self._olerepr_.mapFuncs[attr] = retEntry
    return self._make_method_(attr)
raise pythoncom.com_error, details

But the list of such errors seems not be enough. WMI is returning error code winerror.DISP_E_EXCEPTION in this case. We workarounded the problem adding winerror.DISP_E_EXCEPTION to ERRORS_BAD_CONTEXT in dynamic.py, but perhaps there is a more specific solution.

Best regards

Ramon Garcia
ra...@cn...
Comisin Nacional de Mercado de Valores

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

>Comment By: Mark Hammond (mhammond)
Date: 2008-09-04 12:18

Message:
Logged In: YES 
user_id=14198
Originator: NO

We should look inside the exception object if we don't already - but we
still need to find a "well known" error code in it.  I can't find an error
definition for -2147217400, but if we can show it is used exclusively by
WMI to mean "invalid param", then I'd be happy to add it to the list.

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

Comment By: Roger Upole (rupole)
Date: 2008-09-04 10:49

Message:
Logged In: YES 
user_id=771074
Originator: NO

The main problem is that there are any number of reasons why
that particular error may be returned, and any number of error codes
that might be returned when an object does not receive required
parameters.  No matter how specific you attempt to make it, it will
still be too general.  The best that can be done is to make a specific
wrapper just for WMI objects.

Also, as demonstrated WMI does not give you a way to actually
retrieve a method object thru normal Invoke semantics.  This is why it
provides Methods_ and ExecMethod_ for dynamic languages such as
Python.  For example: log_file.Methods_('BackupEventlog')

Tim Golden's WMI module uses these special methods to hide the
details so that you can use natural syntax.
I highly recommend it.



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

Comment By: Ramon Garcia (ramong)
Date: 2008-09-04 10:03

Message:
Logged In: YES 
user_id=2163452
Originator: YES

Thanks for looking at this issue.

In the interest of easy of use I think that pythoncom should behave as
close as posible to windows Wscript interpreter, because it is what the
script developer expects. object.method(arg) would work like under
WScript.

The solution that we are using, adding winerror.DISP_E_EXCEPTION to
ERRORS_BAD_CONTEXT is somewhat quick and dirty, but works for us. What I
would do would be to add a more specific check, like checking that if
winerror.DISP_E_EXCEPTION and the errorcode -2147217400 inside the wrapped
exception object, and if that happens then make object.method return an
object that can be called. The only risk that I can see in our method is
the risk of breaking working code. Using a more specific solution, it
should not have any risk.

(Excuse me if there are any mistakes in this comment. I don't have the
machine at hand, I and writting from what I can remember).


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

Comment By: Roger Upole (rupole)
Date: 2008-09-04 08:05

Message:
Logged In: YES 
user_id=771074
Originator: NO

I think the underlying problem here is that WMI does not make a distiction
between
asking for a method and executing it. Both of these produce the error you
describe:

log_file._oleobj_.Invoke(id, 0, pythoncom.DISPATCH_METHOD, True)
log_file._oleobj_.Invoke(id, 0, pythoncom.DISPATCH_PROPERTYGET, True)

And both succeed if you pass a filename parameter as an extra arg.
This indicates that the error is not produced by attempting to get the
attribute,
but rather from actually calling the method without a filename parameter.

You may want to look at using Tim Golden's WMI module, which provides a
much
easier to use wrapper for these objects.
http://timgolden.me.uk/python/wmi.html




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

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

[pywin32-bugs] [ pywin32-Bugs-2052253 ] Problem calling WMI method

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

Bugs item #2052253, was opened at 2008-08-14 19:06
Message generated for change (Comment added) made by rupole
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2052253&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: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ramon Garcia (ramong)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem calling WMI method

Initial Comment:
An exception is issued if a WMI method call is attempted. The following code shows it.

	wmiservice = Dispatch("WbemScripting.SWbemLocator")
	wmi = wmiservice.ConnectServer("localhost", "root\cimv2")
	moniker = r"winmgmts:" \
		"{impersonationLevel=impersonate,(Security,Backup)}!\\\\" + \
		computer + r"\root\cimv2"
	wmi = GetObject(moniker)
	log_files = wmi.ExecQuery \
		("SELECT * FROM Win32_NTEventLogFile")
	for log_file in log_files:
		base = re.sub("event$", "", log_file.FileName)
		backup_filename = base + u".evt"
		log_file.BackupEventlog(backup_filename)

The following exception is raised

  File "c:\python25\lib\site-packages\win32com\client\dynamic.py", line 495, in __getattr__
    raise pythoncom.com_error, details
com_error: (-2147352567, 'Ocurri\xf3 una excepci\xf3n.', (0, u'SWbemObjectEx', u'Invalid parameter ', None, 0, -2147217400), None)


We traced this problem to WMI issing an unexecpected return code when it is attempted to get a property that is a method. The function __getattr__ in class CDispatch tries to resolve an attribute request as an attribute first, and then, if an error is raisen by COM, as a method:

if details[0] in ERRORS_BAD_CONTEXT:
    # May be a method.
    self._olerepr_.mapFuncs[attr] = retEntry
    return self._make_method_(attr)
raise pythoncom.com_error, details

But the list of such errors seems not be enough. WMI is returning error code winerror.DISP_E_EXCEPTION in this case. We workarounded the problem adding winerror.DISP_E_EXCEPTION to ERRORS_BAD_CONTEXT in dynamic.py, but perhaps there is a more specific solution.

Best regards

Ramon Garcia
ra...@cn...
Comisión Nacional de Mercado de Valores

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

>Comment By: Roger Upole (rupole)
Date: 2008-09-03 19:49

Message:
Logged In: YES 
user_id=771074
Originator: NO

The main problem is that there are any number of reasons why
that particular error may be returned, and any number of error codes
that might be returned when an object does not receive required
parameters.  No matter how specific you attempt to make it, it will
still be too general.  The best that can be done is to make a specific
wrapper just for WMI objects.

Also, as demonstrated WMI does not give you a way to actually
retrieve a method object thru normal Invoke semantics.  This is why it
provides Methods_ and ExecMethod_ for dynamic languages such as
Python.  For example: log_file.Methods_('BackupEventlog')

Tim Golden's WMI module uses these special methods to hide the
details so that you can use natural syntax.
I highly recommend it.



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

Comment By: Ramon Garcia (ramong)
Date: 2008-09-03 19:03

Message:
Logged In: YES 
user_id=2163452
Originator: YES

Thanks for looking at this issue.

In the interest of easy of use I think that pythoncom should behave as
close as posible to windows Wscript interpreter, because it is what the
script developer expects. object.method(arg) would work like under
WScript.

The solution that we are using, adding winerror.DISP_E_EXCEPTION to
ERRORS_BAD_CONTEXT is somewhat quick and dirty, but works for us. What I
would do would be to add a more specific check, like checking that if
winerror.DISP_E_EXCEPTION and the errorcode -2147217400 inside the wrapped
exception object, and if that happens then make object.method return an
object that can be called. The only risk that I can see in our method is
the risk of breaking working code. Using a more specific solution, it
should not have any risk.

(Excuse me if there are any mistakes in this comment. I don't have the
machine at hand, I and writting from what I can remember).


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

Comment By: Roger Upole (rupole)
Date: 2008-09-03 17:05

Message:
Logged In: YES 
user_id=771074
Originator: NO

I think the underlying problem here is that WMI does not make a distiction
between
asking for a method and executing it. Both of these produce the error you
describe:

log_file._oleobj_.Invoke(id, 0, pythoncom.DISPATCH_METHOD, True)
log_file._oleobj_.Invoke(id, 0, pythoncom.DISPATCH_PROPERTYGET, True)

And both succeed if you pass a filename parameter as an extra arg.
This indicates that the error is not produced by attempting to get the
attribute,
but rather from actually calling the method without a filename parameter.

You may want to look at using Tim Golden's WMI module, which provides a
much
easier to use wrapper for these objects.
http://timgolden.me.uk/python/wmi.html




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

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

[pywin32-bugs] [ pywin32-Bugs-2052253 ] Problem calling WMI method

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

Bugs item #2052253, was opened at 2008-08-15 02:06
Message generated for change (Comment added) made by ramong
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2052253&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: None
Group: None
>Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ramon Garcia (ramong)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem calling WMI method

Initial Comment:
An exception is issued if a WMI method call is attempted. The following code shows it.

	wmiservice = Dispatch("WbemScripting.SWbemLocator")
	wmi = wmiservice.ConnectServer("localhost", "root\cimv2")
	moniker = r"winmgmts:" \
		"{impersonationLevel=impersonate,(Security,Backup)}!\\\\" + \
		computer + r"\root\cimv2"
	wmi = GetObject(moniker)
	log_files = wmi.ExecQuery \
		("SELECT * FROM Win32_NTEventLogFile")
	for log_file in log_files:
		base = re.sub("event$", "", log_file.FileName)
		backup_filename = base + u".evt"
		log_file.BackupEventlog(backup_filename)

The following exception is raised

  File "c:\python25\lib\site-packages\win32com\client\dynamic.py", line 495, in __getattr__
    raise pythoncom.com_error, details
com_error: (-2147352567, 'Ocurri\xf3 una excepci\xf3n.', (0, u'SWbemObjectEx', u'Invalid parameter ', None, 0, -2147217400), None)


We traced this problem to WMI issing an unexecpected return code when it is attempted to get a property that is a method. The function __getattr__ in class CDispatch tries to resolve an attribute request as an attribute first, and then, if an error is raisen by COM, as a method:

if details[0] in ERRORS_BAD_CONTEXT:
    # May be a method.
    self._olerepr_.mapFuncs[attr] = retEntry
    return self._make_method_(attr)
raise pythoncom.com_error, details

But the list of such errors seems not be enough. WMI is returning error code winerror.DISP_E_EXCEPTION in this case. We workarounded the problem adding winerror.DISP_E_EXCEPTION to ERRORS_BAD_CONTEXT in dynamic.py, but perhaps there is a more specific solution.

Best regards

Ramon Garcia
ra...@cn...
Comisin Nacional de Mercado de Valores

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

>Comment By: Ramon Garcia (ramong)
Date: 2008-09-04 02:03

Message:
Logged In: YES 
user_id=2163452
Originator: YES

Thanks for looking at this issue.

In the interest of easy of use I think that pythoncom should behave as
close as posible to windows Wscript interpreter, because it is what the
script developer expects. object.method(arg) would work like under
WScript.

The solution that we are using, adding winerror.DISP_E_EXCEPTION to
ERRORS_BAD_CONTEXT is somewhat quick and dirty, but works for us. What I
would do would be to add a more specific check, like checking that if
winerror.DISP_E_EXCEPTION and the errorcode -2147217400 inside the wrapped
exception object, and if that happens then make object.method return an
object that can be called. The only risk that I can see in our method is
the risk of breaking working code. Using a more specific solution, it
should not have any risk.

(Excuse me if there are any mistakes in this comment. I don't have the
machine at hand, I and writting from what I can remember).


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

Comment By: Roger Upole (rupole)
Date: 2008-09-04 00:05

Message:
Logged In: YES 
user_id=771074
Originator: NO

I think the underlying problem here is that WMI does not make a distiction
between
asking for a method and executing it. Both of these produce the error you
describe:

log_file._oleobj_.Invoke(id, 0, pythoncom.DISPATCH_METHOD, True)
log_file._oleobj_.Invoke(id, 0, pythoncom.DISPATCH_PROPERTYGET, True)

And both succeed if you pass a filename parameter as an extra arg.
This indicates that the error is not produced by attempting to get the
attribute,
but rather from actually calling the method without a filename parameter.

You may want to look at using Tim Golden's WMI module, which provides a
much
easier to use wrapper for these objects.
http://timgolden.me.uk/python/wmi.html




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

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

[pywin32-bugs] [ pywin32-Bugs-2052253 ] Problem calling WMI method

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

Bugs item #2052253, was opened at 2008-08-14 19:06
Message generated for change (Comment added) made by rupole
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2052253&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: None
Group: None
>Status: Pending
Resolution: None
Priority: 5
Private: No
Submitted By: Ramon Garcia (ramong)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem calling WMI method

Initial Comment:
An exception is issued if a WMI method call is attempted. The following code shows it.

	wmiservice = Dispatch("WbemScripting.SWbemLocator")
	wmi = wmiservice.ConnectServer("localhost", "root\cimv2")
	moniker = r"winmgmts:" \
		"{impersonationLevel=impersonate,(Security,Backup)}!\\\\" + \
		computer + r"\root\cimv2"
	wmi = GetObject(moniker)
	log_files = wmi.ExecQuery \
		("SELECT * FROM Win32_NTEventLogFile")
	for log_file in log_files:
		base = re.sub("event$", "", log_file.FileName)
		backup_filename = base + u".evt"
		log_file.BackupEventlog(backup_filename)

The following exception is raised

  File "c:\python25\lib\site-packages\win32com\client\dynamic.py", line 495, in __getattr__
    raise pythoncom.com_error, details
com_error: (-2147352567, 'Ocurri\xf3 una excepci\xf3n.', (0, u'SWbemObjectEx', u'Invalid parameter ', None, 0, -2147217400), None)


We traced this problem to WMI issing an unexecpected return code when it is attempted to get a property that is a method. The function __getattr__ in class CDispatch tries to resolve an attribute request as an attribute first, and then, if an error is raisen by COM, as a method:

if details[0] in ERRORS_BAD_CONTEXT:
    # May be a method.
    self._olerepr_.mapFuncs[attr] = retEntry
    return self._make_method_(attr)
raise pythoncom.com_error, details

But the list of such errors seems not be enough. WMI is returning error code winerror.DISP_E_EXCEPTION in this case. We workarounded the problem adding winerror.DISP_E_EXCEPTION to ERRORS_BAD_CONTEXT in dynamic.py, but perhaps there is a more specific solution.

Best regards

Ramon Garcia
ra...@cn...
Comisin Nacional de Mercado de Valores

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

>Comment By: Roger Upole (rupole)
Date: 2008-09-03 17:05

Message:
Logged In: YES 
user_id=771074
Originator: NO

I think the underlying problem here is that WMI does not make a distiction
between
asking for a method and executing it. Both of these produce the error you
describe:

log_file._oleobj_.Invoke(id, 0, pythoncom.DISPATCH_METHOD, True)
log_file._oleobj_.Invoke(id, 0, pythoncom.DISPATCH_PROPERTYGET, True)

And both succeed if you pass a filename parameter as an extra arg.
This indicates that the error is not produced by attempting to get the
attribute,
but rather from actually calling the method without a filename parameter.

You may want to look at using Tim Golden's WMI module, which provides a
much
easier to use wrapper for these objects.
http://timgolden.me.uk/python/wmi.html




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

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

[pywin32-bugs] [ pywin32-Bugs-2033679 ] Easily corrected error cause failure to open debugger

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

Bugs item #2033679, was opened at 2008-07-31 04:44
Message generated for change (Comment added) made by rupole
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2033679&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: pythonwin
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Martin Gfeller (gfe)
Assigned to: Nobody/Anonymous (nobody)
Summary: Easily corrected error cause failure to open debugger

Initial Comment:
Hi,

when entering the debugger through a break-point or post-mortem, I often get the following traceback:

 File "C:\Quantax\trunk\Zope\Python\Lib\site-packages\pythonwin\pywin\debugger\__init__.py", line 110, in post_mortem
    p.done_run()
  File "C:\Quantax\trunk\Zope\Python\Lib\site-packages\pythonwin\pywin\debugger\debugger.py", line 542, in done_run
    self.RespondDebuggerState(DBGSTATE_NOT_DEBUGGING)
  File "C:\Quantax\trunk\Zope\Python\Lib\site-packages\pythonwin\pywin\debugger\debugger.py", line 769, in RespondDebuggerState
    cb.RespondDebuggerState(state)
  File "C:\Quantax\trunk\Zope\Python\Lib\site-packages\pythonwin\pywin\debugger\debugger.py", line 202, in RespondDebuggerState
    self.list.Refresh()
  File "C:\Quantax\trunk\Zope\Python\Lib\site-packages\pythonwin\pywin\tools\hierlist.py", line 215, in Refresh
    self.AddItem(hparent, newItem)
  File "C:\Quantax\trunk\Zope\Python\Lib\site-packages\pythonwin\pywin\tools\hierlist.py", line 140, in AddItem
    text = self.GetText(item)
  File "C:\Quantax\trunk\Zope\Python\Lib\site-packages\pythonwin\pywin\tools\hierlist.py", line 266, in GetText
    return self.DelegateCall( item.GetText )
  File "C:\Quantax\trunk\Zope\Python\Lib\site-packages\pythonwin\pywin\tools\hierlist.py", line 255, in DelegateCall
    return fn()
  File "C:\Quantax\trunk\Zope\Python\Lib\site-packages\pythonwin\pywin\debugger\debugger.py", line 58, in GetText
    name = self.myobject.f_locals['__name__'] + " module"
TypeError: unsupported operand type(s) for +: 'NoneType' and 'str'


This can be corrected easily by putting an str() around
self.myobject.f_locals['__name__'] in debugger.HierFrameItem[58] or a get with check against None instead of the has_key() in the line above. 

I did not investigate why the f_locals exists and is None, just cured the symptoms. 

Best regards, Martin


HierFrameItem 

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

>Comment By: Roger Upole (rupole)
Date: 2008-09-03 16:31

Message:
Logged In: YES 
user_id=771074
Originator: NO

I've run into this myself on rare occasions.  This seems fairly
safe and doesn't break anything, so I've committed it.


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

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

[pywin32-bugs] [ pywin32-Bugs-2090927 ] interactive window ignores Insert spaces

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

Bugs item #2090927, was opened at 2008-09-03 06:02
Message generated for change (Comment added) made by rupole
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2090927&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: pythonwin
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: bob gailer (ramrom)
Assigned to: Nobody/Anonymous (nobody)
Summary: interactive window ignores Insert spaces

Initial Comment:
Tabs entered in interactive window are not converted to spaces when Insert spaces has been selected. This has not been a problem per se until copy code without prompts arrived. 

Suggest convert tabs either when entered or in the clipboard when code is copied.

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

>Comment By: Roger Upole (rupole)
Date: 2008-09-03 15:45

Message:
Logged In: YES 
user_id=771074
Originator: NO

Going back to build 209, I still get only tabs in the interactive window.
Pythonwin uses Idle's built-in tab/space conversions, and indeed Idle
shows the same behaviour.
According to this issue on the python tracker:

http://mail.python.org/pipermail/python-bugs-list/2006-October/035603.html

it's configured to always use tabs in the interactive window now.



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

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

[pywin32-bugs] [ pywin32-Bugs-2090927 ] interactive window ignores Insert spaces

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

Bugs item #2090927, was opened at 2008-09-03 05:02
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2090927&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: pythonwin
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: bob gailer (ramrom)
Assigned to: Nobody/Anonymous (nobody)
Summary: interactive window ignores Insert spaces

Initial Comment:
Tabs entered in interactive window are not converted to spaces when Insert spaces has been selected. This has not been a problem per se until copy code without prompts arrived. 

Suggest convert tabs either when entered or in the clipboard when code is copied.

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

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

[pywin32-bugs] [ pywin32-Bugs-2030170 ] Installer for Python 2.5 / v211 does not work

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

Bugs item #2030170, was opened at 2008-07-28 06:05
Message generated for change (Comment added) made by mighty_joe
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2030170&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: H_B (hb08)
Assigned to: Nobody/Anonymous (nobody)
Summary: Installer for Python 2.5 / v211 does not work

Initial Comment:
After Downloading the Win-Installer for Python 2.5 / v211  and starting it for installation using the current user (not admin), the message "Setup program invalid or damaged" appears and the installer exits.

Tried different mirrors to download (Berlin, Kent) - same results.

Regards, HB




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

Comment By: Mighty Joe (mighty_joe)
Date: 2008-09-02 11:54

Message:
Logged In: YES 
user_id=2202041
Originator: NO

I solved my problem.  I found pywin32-212.win32-py2.5.exe by poking around
sourceforge some more.  This file works.  Why is the default download
targeted for Python 2.6 when that version is still in beta?  Is there any
way to configure the default download page to display more than the 2.6
version?

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

Comment By: Mighty Joe (mighty_joe)
Date: 2008-09-02 10:08

Message:
Logged In: YES 
user_id=2202041
Originator: NO

I am getting a similar error.  I am trying to install
pywin32-212.win32-py2.6.exe on Windows XP and Python 2.5.2 (Python 2.5.2
(r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit (Intel)] on win32). 
When I try to execute the pywin32 installer, I get a dialog with the
message "This application has failed to start because the application
configuration is incorrect.  Reinstalling the application may fix this
problem".  


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

Comment By: H_B (hb08)
Date: 2008-07-28 06:07

Message:
Logged In: YES 
user_id=2160671
Originator: YES

forgot to mention: WinXP, Py 2.5 installed in the usual path
(C:/Python2.5/....

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

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

[pywin32-bugs] [ pywin32-Bugs-2030170 ] Installer for Python 2.5 / v211 does not work

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

Bugs item #2030170, was opened at 2008-07-28 06:05
Message generated for change (Comment added) made by mighty_joe
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2030170&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: H_B (hb08)
Assigned to: Nobody/Anonymous (nobody)
Summary: Installer for Python 2.5 / v211 does not work

Initial Comment:
After Downloading the Win-Installer for Python 2.5 / v211  and starting it for installation using the current user (not admin), the message "Setup program invalid or damaged" appears and the installer exits.

Tried different mirrors to download (Berlin, Kent) - same results.

Regards, HB




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

Comment By: Mighty Joe (mighty_joe)
Date: 2008-09-02 10:08

Message:
Logged In: YES 
user_id=2202041
Originator: NO

I am getting a similar error.  I am trying to install
pywin32-212.win32-py2.6.exe on Windows XP and Python 2.5.2 (Python 2.5.2
(r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit (Intel)] on win32). 
When I try to execute the pywin32 installer, I get a dialog with the
message "This application has failed to start because the application
configuration is incorrect.  Reinstalling the application may fix this
problem".  


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

Comment By: H_B (hb08)
Date: 2008-07-28 06:07

Message:
Logged In: YES 
user_id=2160671
Originator: YES

forgot to mention: WinXP, Py 2.5 installed in the usual path
(C:/Python2.5/....

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

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