pywin32-bugs Mailing List for Python for Windows Extensions (Page 35)
OLD project page for the Python extensions for Windows
Brought to you by:
mhammond
Menu
▾
▴
pywin32-bugs — Automated tracker notifications (not for bug reports!)
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
(24) |
May
(19) |
Jun
(15) |
Jul
(43) |
Aug
(39) |
Sep
(25) |
Oct
(43) |
Nov
(19) |
Dec
(4) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(21) |
Feb
(18) |
Mar
(14) |
Apr
(80) |
May
(56) |
Jun
(24) |
Jul
(30) |
Aug
(17) |
Sep
(36) |
Oct
(106) |
Nov
(38) |
Dec
(30) |
| 2005 |
Jan
(14) |
Feb
(14) |
Mar
(48) |
Apr
(28) |
May
(49) |
Jun
(23) |
Jul
(9) |
Aug
(13) |
Sep
(28) |
Oct
(21) |
Nov
(8) |
Dec
(26) |
| 2006 |
Jan
(56) |
Feb
(33) |
Mar
(33) |
Apr
(18) |
May
(16) |
Jun
(9) |
Jul
(24) |
Aug
(16) |
Sep
(14) |
Oct
(37) |
Nov
(38) |
Dec
(22) |
| 2007 |
Jan
(7) |
Feb
(16) |
Mar
(11) |
Apr
(15) |
May
(15) |
Jun
(8) |
Jul
(24) |
Aug
(26) |
Sep
(18) |
Oct
(11) |
Nov
(20) |
Dec
(1) |
| 2008 |
Jan
(19) |
Feb
(55) |
Mar
(7) |
Apr
(35) |
May
(66) |
Jun
(38) |
Jul
(26) |
Aug
(5) |
Sep
(25) |
Oct
(25) |
Nov
(18) |
Dec
(18) |
| 2009 |
Jan
(25) |
Feb
(38) |
Mar
(29) |
Apr
(25) |
May
(5) |
Jun
(11) |
Jul
(16) |
Aug
(16) |
Sep
(16) |
Oct
(1) |
Nov
(15) |
Dec
(33) |
| 2010 |
Jan
(13) |
Feb
(11) |
Mar
(1) |
Apr
(24) |
May
(26) |
Jun
(19) |
Jul
(22) |
Aug
(51) |
Sep
(38) |
Oct
(39) |
Nov
(25) |
Dec
(27) |
| 2011 |
Jan
(40) |
Feb
(31) |
Mar
(21) |
Apr
(42) |
May
(11) |
Jun
(16) |
Jul
(20) |
Aug
(14) |
Sep
(6) |
Oct
(8) |
Nov
(34) |
Dec
(7) |
| 2012 |
Jan
(60) |
Feb
(24) |
Mar
(6) |
Apr
(28) |
May
(41) |
Jun
(15) |
Jul
(14) |
Aug
(25) |
Sep
(30) |
Oct
(18) |
Nov
(30) |
Dec
(9) |
| 2013 |
Jan
(3) |
Feb
(8) |
Mar
(17) |
Apr
(23) |
May
(34) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
|
From: SourceForge.net <no...@so...> - 2010-06-04 06:50:34
|
Bugs item #3009827, was opened at 2010-06-01 11:17 Message generated for change (Comment added) made by andersjm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3009827&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: Anders J. Munch (andersjm) Assigned to: Nobody/Anonymous (nobody) Summary: QueryDosDevice fails with error 234 Initial Comment: After attaching an additional USB device, win32file.QueryDosDevice(None) suddenly started failing with the exception: pywintypes.error: (234, 'QueryDosDevice', 'Der er flere data til r\xe5dighed.') Error 234 is ERROR_MORE_DATA, which indicates that the supplied buffer is too small. (The text translates to 'More data is available.) Looking at win32file.i, MyQueryDosDevice expects a too small buffer to result in ERROR_INSUFFICIENT_BUFFER; so presumably treating ERROR_MORE_DATA as synonymous will fix it. (Python 2.4.4, pywin32-208.) ---------------------------------------------------------------------- Comment By: Anders J. Munch (andersjm) Date: 2010-06-04 08:50 Message: I checked on the (previously) failing system: len(win32file.QueryDosDevice(None))==10222 -- so clearly I was wrong to point to the 8192 initial buffer size. Also I can't reproduce it anymore, whether it was the nightly powercycle or a slightly different mix of USB devices that did it, I don't know. That means I can't test a fix, so I suggest you close it as 'works for me'. ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2010-06-03 23:05 Message: It already does on my system: >>> d=win32file.QueryDosDevice(None) >>> len(d) 8593 I also tried hardcoding the initial buffer sizes lower, still succeeds. ---------------------------------------------------------------------- Comment By: Anders J. Munch (andersjm) Date: 2010-06-03 21:35 Message: XP. To reproduce you need for len(win32file.QueryDosDevice(None)) to exceed the initial buffer size of 8192 - or reduce the initial buffer size so that it does. ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2010-06-03 20:49 Message: I can't reproduce this on XP, Vista, or Windows 7. Which OS are you on ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3009827&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-06-03 21:05:05
|
Bugs item #3009827, was opened at 2010-06-01 04:17 Message generated for change (Comment added) made by rupole You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3009827&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: Anders J. Munch (andersjm) Assigned to: Nobody/Anonymous (nobody) Summary: QueryDosDevice fails with error 234 Initial Comment: After attaching an additional USB device, win32file.QueryDosDevice(None) suddenly started failing with the exception: pywintypes.error: (234, 'QueryDosDevice', 'Der er flere data til r\xe5dighed.') Error 234 is ERROR_MORE_DATA, which indicates that the supplied buffer is too small. (The text translates to 'More data is available.) Looking at win32file.i, MyQueryDosDevice expects a too small buffer to result in ERROR_INSUFFICIENT_BUFFER; so presumably treating ERROR_MORE_DATA as synonymous will fix it. (Python 2.4.4, pywin32-208.) ---------------------------------------------------------------------- >Comment By: Roger Upole (rupole) Date: 2010-06-03 16:05 Message: It already does on my system: >>> d=win32file.QueryDosDevice(None) >>> len(d) 8593 I also tried hardcoding the initial buffer sizes lower, still succeeds. ---------------------------------------------------------------------- Comment By: Anders J. Munch (andersjm) Date: 2010-06-03 14:35 Message: XP. To reproduce you need for len(win32file.QueryDosDevice(None)) to exceed the initial buffer size of 8192 - or reduce the initial buffer size so that it does. ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2010-06-03 13:49 Message: I can't reproduce this on XP, Vista, or Windows 7. Which OS are you on ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3009827&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-06-03 19:35:29
|
Bugs item #3009827, was opened at 2010-06-01 11:17 Message generated for change (Comment added) made by andersjm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3009827&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: Anders J. Munch (andersjm) Assigned to: Nobody/Anonymous (nobody) Summary: QueryDosDevice fails with error 234 Initial Comment: After attaching an additional USB device, win32file.QueryDosDevice(None) suddenly started failing with the exception: pywintypes.error: (234, 'QueryDosDevice', 'Der er flere data til r\xe5dighed.') Error 234 is ERROR_MORE_DATA, which indicates that the supplied buffer is too small. (The text translates to 'More data is available.) Looking at win32file.i, MyQueryDosDevice expects a too small buffer to result in ERROR_INSUFFICIENT_BUFFER; so presumably treating ERROR_MORE_DATA as synonymous will fix it. (Python 2.4.4, pywin32-208.) ---------------------------------------------------------------------- Comment By: Anders J. Munch (andersjm) Date: 2010-06-03 21:35 Message: XP. To reproduce you need for len(win32file.QueryDosDevice(None)) to exceed the initial buffer size of 8192 - or reduce the initial buffer size so that it does. ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2010-06-03 20:49 Message: I can't reproduce this on XP, Vista, or Windows 7. Which OS are you on ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3009827&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-06-03 18:49:38
|
Bugs item #3009827, was opened at 2010-06-01 04:17 Message generated for change (Comment added) made by rupole You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3009827&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: Anders J. Munch (andersjm) Assigned to: Nobody/Anonymous (nobody) Summary: QueryDosDevice fails with error 234 Initial Comment: After attaching an additional USB device, win32file.QueryDosDevice(None) suddenly started failing with the exception: pywintypes.error: (234, 'QueryDosDevice', 'Der er flere data til r\xe5dighed.') Error 234 is ERROR_MORE_DATA, which indicates that the supplied buffer is too small. (The text translates to 'More data is available.) Looking at win32file.i, MyQueryDosDevice expects a too small buffer to result in ERROR_INSUFFICIENT_BUFFER; so presumably treating ERROR_MORE_DATA as synonymous will fix it. (Python 2.4.4, pywin32-208.) ---------------------------------------------------------------------- >Comment By: Roger Upole (rupole) Date: 2010-06-03 13:49 Message: I can't reproduce this on XP, Vista, or Windows 7. Which OS are you on ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3009827&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-06-03 18:46:02
|
Bugs item #3010660, was opened at 2010-06-02 14:59 Message generated for change (Comment added) made by rupole You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3010660&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: com Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: ncc (nconrads) Assigned to: Nobody/Anonymous (nobody) Summary: [python312,pywin32] Script in gen_py using missing unicode() Initial Comment: Installed Python 3.1.2 from python.org and rev. 214 of Python Windows for Extensions for python31. Connected to Word 2007, opened a document via COM calls, then attempted to print (via std out) the contents of the document to the console. The operation fails immediately, as the generated python script attempts to call the unicode() built-in command that is not present in (presumably) Python 3.0+. ---------------------------------------------------------------------- >Comment By: Roger Upole (rupole) Date: 2010-06-03 13:46 Message: Fixed in genpy.py, r1.67 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3010660&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-06-02 21:59:20
|
Bugs item #3008512, was opened at 2010-05-28 22:30 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3008512&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: com Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Klaus Noekel (kahlbutz) Assigned to: Nobody/Anonymous (nobody) Summary: COM server built with pythoncom crashes on second call Initial Comment: I am experiencing crashes with Python-based COM servers, if their methods use wxPython. I post the problem to this buglist, because I am not sure whether the effect is caused by wxPython or pywin32. Here is what happens: My COM server is a slight variation of the small example from ch. 12 of Mark's book: import wx class PythonUtilities: _public_methods_ = [ 'SplitString' ] _reg_progid_ = "PythonAddIn.Runner" # NEVER copy the following ID # Use "print pythoncom.CreateGuid()" to make a new one. _reg_clsid_ = "{91D9FEF4-B762-43AF-A0A5-965DA7B6A8EB}" def SplitString(self, val, item=None): import string app = wx.PySimpleApp(0) if item != None: item = str(item) res = string.split(str(val), item) for i,x in enumerate(res): wx.MessageBox(str(x),str(i)) return res # Add code so that when this script is run by # Python.exe, it self-registers. if __name__ == '__main__': print "Registering COM server..." import win32com.server.register win32com.server.register.UseCommandLine(PythonUtilities) No, it does not do anything useful, but I managed to scale back the original example to this toy. Note that the method displays a few strings in a wx.MessageBox. Any call to wx causes the behavior described below. Here is a VBA client for the server: Sub COMTest() Set Runner = CreateObject("PythonAddIn.Runner") x = Runner.SplitString("fgh;jh;oei", ";") Set Runner = Nothing End Sub Can't be much simpler than that. The first run of this client from Excel always succeeds, and three MessageBoxes pop up, as you would expect. The behavior on the second run (from the same Excel session) depends on the OS version running. Under Win 7 64-bit the second (and all subsequent) runs work just fine. Under XP SP2 32-bit the second run always crashes Excel. On OS's in between these two the second run may or may not crash, sometimes it even depends on the machine. Versions used: Python 2.5.4, pywin32 -212, wxPython 2.8.9.1. The Excel version is unimportant, the crashes occur even in clients written in C++. Any clue? I'd appreciate any advice! Thanks, Klaus Noekel ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2010-06-03 07:59 Message: thanks for the update! ---------------------------------------------------------------------- Comment By: Klaus Noekel (kahlbutz) Date: 2010-06-03 05:27 Message: Here is an update. Robin Dunn (wxPython) suspected that the problem occurs, because the wxPython app does not run in its own thread. I experimentally offloaded the body of SplitString into a separate thread, and that worked without crashes on different OS versions. So, this issue seems to be settled on the wxPython side, and the pywin32 issue can be closed. Not sure I am allowed to do such a thing, so I leave it to you. Thanks, Klaus ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2010-05-29 10:00 Message: Starting a wxapp and showing UI as part of a COM object is always going to be tricky. It is even possible to crash a non COM object simply by trying to use wx with other GUI toolkits (eg, I expect you might have the same problem trying to do the same thing from inside pythonwin?) Either way, you are probably going to need to take this to the wx list... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3008512&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-06-02 19:59:22
|
Bugs item #3010660, was opened at 2010-06-02 19:59 Message generated for change (Tracker Item Submitted) made by nconrads You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3010660&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: com Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: ncc (nconrads) Assigned to: Nobody/Anonymous (nobody) Summary: [python312,pywin32] Script in gen_py using missing unicode() Initial Comment: Installed Python 3.1.2 from python.org and rev. 214 of Python Windows for Extensions for python31. Connected to Word 2007, opened a document via COM calls, then attempted to print (via std out) the contents of the document to the console. The operation fails immediately, as the generated python script attempts to call the unicode() built-in command that is not present in (presumably) Python 3.0+. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3010660&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-06-02 19:27:59
|
Bugs item #3008512, was opened at 2010-05-28 14:30 Message generated for change (Comment added) made by kahlbutz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3008512&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: com Group: None >Status: Open Resolution: None Priority: 5 Private: No Submitted By: Klaus Noekel (kahlbutz) Assigned to: Nobody/Anonymous (nobody) Summary: COM server built with pythoncom crashes on second call Initial Comment: I am experiencing crashes with Python-based COM servers, if their methods use wxPython. I post the problem to this buglist, because I am not sure whether the effect is caused by wxPython or pywin32. Here is what happens: My COM server is a slight variation of the small example from ch. 12 of Mark's book: import wx class PythonUtilities: _public_methods_ = [ 'SplitString' ] _reg_progid_ = "PythonAddIn.Runner" # NEVER copy the following ID # Use "print pythoncom.CreateGuid()" to make a new one. _reg_clsid_ = "{91D9FEF4-B762-43AF-A0A5-965DA7B6A8EB}" def SplitString(self, val, item=None): import string app = wx.PySimpleApp(0) if item != None: item = str(item) res = string.split(str(val), item) for i,x in enumerate(res): wx.MessageBox(str(x),str(i)) return res # Add code so that when this script is run by # Python.exe, it self-registers. if __name__ == '__main__': print "Registering COM server..." import win32com.server.register win32com.server.register.UseCommandLine(PythonUtilities) No, it does not do anything useful, but I managed to scale back the original example to this toy. Note that the method displays a few strings in a wx.MessageBox. Any call to wx causes the behavior described below. Here is a VBA client for the server: Sub COMTest() Set Runner = CreateObject("PythonAddIn.Runner") x = Runner.SplitString("fgh;jh;oei", ";") Set Runner = Nothing End Sub Can't be much simpler than that. The first run of this client from Excel always succeeds, and three MessageBoxes pop up, as you would expect. The behavior on the second run (from the same Excel session) depends on the OS version running. Under Win 7 64-bit the second (and all subsequent) runs work just fine. Under XP SP2 32-bit the second run always crashes Excel. On OS's in between these two the second run may or may not crash, sometimes it even depends on the machine. Versions used: Python 2.5.4, pywin32 -212, wxPython 2.8.9.1. The Excel version is unimportant, the crashes occur even in clients written in C++. Any clue? I'd appreciate any advice! Thanks, Klaus Noekel ---------------------------------------------------------------------- >Comment By: Klaus Noekel (kahlbutz) Date: 2010-06-02 21:27 Message: Here is an update. Robin Dunn (wxPython) suspected that the problem occurs, because the wxPython app does not run in its own thread. I experimentally offloaded the body of SplitString into a separate thread, and that worked without crashes on different OS versions. So, this issue seems to be settled on the wxPython side, and the pywin32 issue can be closed. Not sure I am allowed to do such a thing, so I leave it to you. Thanks, Klaus ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2010-05-29 02:00 Message: Starting a wxapp and showing UI as part of a COM object is always going to be tricky. It is even possible to crash a non COM object simply by trying to use wx with other GUI toolkits (eg, I expect you might have the same problem trying to do the same thing from inside pythonwin?) Either way, you are probably going to need to take this to the wx list... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3008512&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-06-01 09:17:34
|
Bugs item #3009827, was opened at 2010-06-01 11:17 Message generated for change (Tracker Item Submitted) made by andersjm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3009827&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: Anders J. Munch (andersjm) Assigned to: Nobody/Anonymous (nobody) Summary: QueryDosDevice fails with error 234 Initial Comment: After attaching an additional USB device, win32file.QueryDosDevice(None) suddenly started failing with the exception: pywintypes.error: (234, 'QueryDosDevice', 'Der er flere data til r\xe5dighed.') Error 234 is ERROR_MORE_DATA, which indicates that the supplied buffer is too small. (The text translates to 'More data is available.) Looking at win32file.i, MyQueryDosDevice expects a too small buffer to result in ERROR_INSUFFICIENT_BUFFER; so presumably treating ERROR_MORE_DATA as synonymous will fix it. (Python 2.4.4, pywin32-208.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3009827&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-05-29 00:00:17
|
Bugs item #3008512, was opened at 2010-05-28 22:30 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3008512&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: com Group: None >Status: Pending Resolution: None Priority: 5 Private: No Submitted By: Klaus Noekel (kahlbutz) Assigned to: Nobody/Anonymous (nobody) Summary: COM server built with pythoncom crashes on second call Initial Comment: I am experiencing crashes with Python-based COM servers, if their methods use wxPython. I post the problem to this buglist, because I am not sure whether the effect is caused by wxPython or pywin32. Here is what happens: My COM server is a slight variation of the small example from ch. 12 of Mark's book: import wx class PythonUtilities: _public_methods_ = [ 'SplitString' ] _reg_progid_ = "PythonAddIn.Runner" # NEVER copy the following ID # Use "print pythoncom.CreateGuid()" to make a new one. _reg_clsid_ = "{91D9FEF4-B762-43AF-A0A5-965DA7B6A8EB}" def SplitString(self, val, item=None): import string app = wx.PySimpleApp(0) if item != None: item = str(item) res = string.split(str(val), item) for i,x in enumerate(res): wx.MessageBox(str(x),str(i)) return res # Add code so that when this script is run by # Python.exe, it self-registers. if __name__ == '__main__': print "Registering COM server..." import win32com.server.register win32com.server.register.UseCommandLine(PythonUtilities) No, it does not do anything useful, but I managed to scale back the original example to this toy. Note that the method displays a few strings in a wx.MessageBox. Any call to wx causes the behavior described below. Here is a VBA client for the server: Sub COMTest() Set Runner = CreateObject("PythonAddIn.Runner") x = Runner.SplitString("fgh;jh;oei", ";") Set Runner = Nothing End Sub Can't be much simpler than that. The first run of this client from Excel always succeeds, and three MessageBoxes pop up, as you would expect. The behavior on the second run (from the same Excel session) depends on the OS version running. Under Win 7 64-bit the second (and all subsequent) runs work just fine. Under XP SP2 32-bit the second run always crashes Excel. On OS's in between these two the second run may or may not crash, sometimes it even depends on the machine. Versions used: Python 2.5.4, pywin32 -212, wxPython 2.8.9.1. The Excel version is unimportant, the crashes occur even in clients written in C++. Any clue? I'd appreciate any advice! Thanks, Klaus Noekel ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2010-05-29 10:00 Message: Starting a wxapp and showing UI as part of a COM object is always going to be tricky. It is even possible to crash a non COM object simply by trying to use wx with other GUI toolkits (eg, I expect you might have the same problem trying to do the same thing from inside pythonwin?) Either way, you are probably going to need to take this to the wx list... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3008512&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-05-28 12:30:36
|
Bugs item #3008512, was opened at 2010-05-28 14:30 Message generated for change (Tracker Item Submitted) made by kahlbutz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3008512&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: com Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Klaus Noekel (kahlbutz) Assigned to: Nobody/Anonymous (nobody) Summary: COM server built with pythoncom crashes on second call Initial Comment: I am experiencing crashes with Python-based COM servers, if their methods use wxPython. I post the problem to this buglist, because I am not sure whether the effect is caused by wxPython or pywin32. Here is what happens: My COM server is a slight variation of the small example from ch. 12 of Mark's book: import wx class PythonUtilities: _public_methods_ = [ 'SplitString' ] _reg_progid_ = "PythonAddIn.Runner" # NEVER copy the following ID # Use "print pythoncom.CreateGuid()" to make a new one. _reg_clsid_ = "{91D9FEF4-B762-43AF-A0A5-965DA7B6A8EB}" def SplitString(self, val, item=None): import string app = wx.PySimpleApp(0) if item != None: item = str(item) res = string.split(str(val), item) for i,x in enumerate(res): wx.MessageBox(str(x),str(i)) return res # Add code so that when this script is run by # Python.exe, it self-registers. if __name__ == '__main__': print "Registering COM server..." import win32com.server.register win32com.server.register.UseCommandLine(PythonUtilities) No, it does not do anything useful, but I managed to scale back the original example to this toy. Note that the method displays a few strings in a wx.MessageBox. Any call to wx causes the behavior described below. Here is a VBA client for the server: Sub COMTest() Set Runner = CreateObject("PythonAddIn.Runner") x = Runner.SplitString("fgh;jh;oei", ";") Set Runner = Nothing End Sub Can't be much simpler than that. The first run of this client from Excel always succeeds, and three MessageBoxes pop up, as you would expect. The behavior on the second run (from the same Excel session) depends on the OS version running. Under Win 7 64-bit the second (and all subsequent) runs work just fine. Under XP SP2 32-bit the second run always crashes Excel. On OS's in between these two the second run may or may not crash, sometimes it even depends on the machine. Versions used: Python 2.5.4, pywin32 -212, wxPython 2.8.9.1. The Excel version is unimportant, the crashes occur even in clients written in C++. Any clue? I'd appreciate any advice! Thanks, Klaus Noekel ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3008512&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-05-21 21:01:20
|
Feature Requests item #3005507, was opened at 2010-05-21 15:01 Message generated for change (Tracker Item Submitted) made by airdrik You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=3005507&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: Airdrik (airdrik) Assigned to: Nobody/Anonymous (nobody) Summary: adodbapi distinguishing of datetime and date Initial Comment: In MS SQL server, there are two date types: datetime and smalldatetime; datetime has a time component and smalldatetime does not. in adodbapi, they both come in as basically the same type and adodbapi converts them both to python's datetime.date if the time component is 0 or to datetime.datetime otherwise. This leads to possible type differences if a datetime column sometimes has a time component of midnight, and sometimes has other times (for some strange reason datetime.date and datetime.datetime are not comparable). I would prefer that sql datetime get converted to python datetime.datetime (regardless of if the time component), and sql smalldatetime get converted to python datetime.date (with the exception that sql null get converted to None regardless). Part of the problem of distinguishing these types is that the type_code of both datetime and smalldatetime is 135 (adDBTimeStamp), however they can be distinguished by the scale field of .description - the scale on datetime is 3, whereas the scale on smalldatetime is 0. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=3005507&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-05-19 14:25:44
|
Bugs item #2934349, was opened at 2010-01-18 15:39 Message generated for change (Comment added) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2934349&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: Eino Mäkitalo (emakital) Assigned to: Nobody/Anonymous (nobody) Summary: python 3.1 and pywin 214 gives some errors when installing Initial Comment: python 3.1 and pywin 214 gives some errors when installing: Traceback (most recent call last): File "<string>", line 601, in <module> File "<string>", line 329, in install File "<string>", line 15, in write AttributeError: 'NoneType' object has no attribute 'write' ---------------------------------------------------------------------- Comment By: http://uniheliodem.livejournal. () Date: 2010-05-19 14:25 Message: I believe the problem has to do with UAC settings. When the failure occurs, pywintypes31.dll is not copied to C:\WINDOWS\System32. Manually copying this DLL to this directory after installation fixes the installation and allows pywin32 modules to be imported. I hope this helps. ---------------------------------------------------------------------- Comment By: Davyd McColl (davydm) Date: 2010-05-17 07:49 Message: I still see this on selected machines. I haven't been able to narrow down what makes these machines different though. I've seen the problem appear (and not appear) on WinXP and Win7 (32 and 64-bit). My machine is win7 64-bit and the error doesn't appear. I have mixed users -- some get the error, some don't. The net result is that certain bits of pywin32 aren't usable. The users all have the pywin32 dll's in the correct places (SysWOW64 for 64-bit and System32 for 32-bit). ---------------------------------------------------------------------- Comment By: easperhe (easperhe) Date: 2010-04-09 18:25 Message: Eino, All, Was this issue resolved?? I'm trying to install pywin 214 with python 3.1.2 on windows 7 (32-bit) and seeing exactly the same problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2934349&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-05-19 06:44:41
|
Bugs item #3003706, was opened at 2010-05-18 22:48 Message generated for change (Comment added) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3003706&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: gz () Assigned to: Nobody/Anonymous (nobody) Summary: pywintypes.error should inherit from WindowsError Initial Comment: Exceptions thrown by system calls in Python functions throw an EnvironmentError subclass, ctypes.WinError creates a WindowsError, extension modules using windows system calls throw some kind of OSError, but pywin32 has its own exception type that can't be caught at the same time as any of these. This means we've got an odd case in our code, where there are two nearly identical implementations of a class, one using ctypes and one using pywin32, but the generic error handling code treated them differently because pywintypes.error isn't an EnvironmentError, see <https://bugs.launchpad.net/bzr/+bug/572201>. The current code in win32/src/PyWinTypesmodule.cpp is like: class error(Exception): def __init__(self, *args, **kw): self.winerror, self.funcname, self.strerror = args[:3] Exception.__init__(self, *args, **kw) It could be changed to something along the lines of: class error(WindowsException): def __init__(self, winerror, strerror, funcname, filename=None): WindowsException.__init__(self, winerror, strerror, filename) self.funcname = funcname This would also mean it got pretty stringifying rather than the ugly 3-tuple repr it has currently. Changing the base type probably would break some code with carefully ordered except blocks, but would be a good thing in the long run. The pywintypes.com_error should probably remain descended from plain Exception, comtypes.COMError is as well. ---------------------------------------------------------------------- >Comment By: gz () Date: 2010-05-19 06:44 Message: You're right, that's the judgement that needs to be made. Looking to see how the exception is handled in real code shows up less obvious breakage than I'd expect, mostly because so little code is doing anything sensible in response to errors. Poking around with: <http://www.google.com/codesearch?q=%22except+pywintypes.error%22> There's the ignore-and-hope approach: <http://www.google.com/codesearch/p#Dm6oHlSzlBo/src/zope/app/winservice/service.py&l=80> except pywintypes.error: # the process may already have been terminated pass <http://twistedmatrix.com/trac/browser/trunk/twisted/internet/_pollingfile.py?rev=27469#L179> except pywintypes.error: # Maybe it's an invalid handle. Who knows. pass <http://www.google.com/codesearch/p#AaFjKoY6UPA/dl/BitTorrent-5.0.5.tar.gz%7CwOfsDlaYENg/BitTorrent-5.0.5/BitTorrent/platform.py&l=445> except pywintypes.error, e: # I've seen: # error: (1784, 'DeviceIoControl', 'The supplied user buffer is not valid for the requested operation.') return Or report, and optionally die: <http://www.google.com/codesearch/p#bXPcfyPP8Uc/trunk/tepache.py&l=366> except pywintypes.error, e: printerr("You haven't installed any GnuWin32 program.") <http://www.google.com/codesearch/p#mXwtIi4wwhA/software/changenav/cnav-1.1.0-src.zip%7Cd_heUe2jE1k/process.py&l=16> except pywintypes.error, e: fatalError('Error launching process\n' '(%s):\n%s' % (command, e[2])) Or, y'know, give me a real exception I can actually work with: <http://svn.python.org/view/python/trunk/Lib/subprocess.py?revision=81179&view=markup> except pywintypes.error, e: # Translate pywintypes.error to WindowsError, which is # a subclass of OSError. FIXME: We should really # translate errno using _sys_errlist (or simliar), but # how can this be done from Python? raise WindowsError(*e.args) <http://www.google.com/codesearch/p#vsRFXGKPaKo/resources/lib/durus/durus/file.py&l=95> except pywintypes.error: raise IOError("Unable to obtain lock") <http://www.google.com/codesearch/p#yqvQ9RM69FY/mercurial/util_win32.py&l=161> except pywintypes.error, details: raise WinOSError(details) Mercurial seem to have removed that last file, 's a good thing, half of it is just trying to fix up error codes as done by WindowsException. Only thing I've found liable to break seriously is tuple-unpacking the exception instance: <http://www.google.com/codesearch/p#1IKf2ZWr9OM/tools/third_party/python/Lib/site-packages/win32/lib/win32serviceutil.py&l=420> except pywintypes.error, (hr, name, msg): if hr!=winerror.ERROR_SERVICE_NOT_ACTIVE: raise win32service.error, (hr, name, msg) And hey, you fixed that! <http://pywin32.cvs.sourceforge.net/viewvc/pywin32/pywin32/win32/Lib/win32serviceutil.py?r1=1.30&r2=1.31> ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2010-05-19 00:45 Message: I agree that if the exception was created today it probably should inherit from WindowsError, but I am skeptical that the pain this causes is worth the pain created by breaking existing code with carefully written exception handlers - particularly as exception handlers are often hard to test, so the breakage may not be obvious until a rarely hit exception is encountered. The work-around for you would seem to simply use 2 except clauses, but handle them in the same way. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3003706&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-05-19 00:45:52
|
Bugs item #3003706, was opened at 2010-05-19 08:48 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3003706&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: gz () Assigned to: Nobody/Anonymous (nobody) Summary: pywintypes.error should inherit from WindowsError Initial Comment: Exceptions thrown by system calls in Python functions throw an EnvironmentError subclass, ctypes.WinError creates a WindowsError, extension modules using windows system calls throw some kind of OSError, but pywin32 has its own exception type that can't be caught at the same time as any of these. This means we've got an odd case in our code, where there are two nearly identical implementations of a class, one using ctypes and one using pywin32, but the generic error handling code treated them differently because pywintypes.error isn't an EnvironmentError, see <https://bugs.launchpad.net/bzr/+bug/572201>. The current code in win32/src/PyWinTypesmodule.cpp is like: class error(Exception): def __init__(self, *args, **kw): self.winerror, self.funcname, self.strerror = args[:3] Exception.__init__(self, *args, **kw) It could be changed to something along the lines of: class error(WindowsException): def __init__(self, winerror, strerror, funcname, filename=None): WindowsException.__init__(self, winerror, strerror, filename) self.funcname = funcname This would also mean it got pretty stringifying rather than the ugly 3-tuple repr it has currently. Changing the base type probably would break some code with carefully ordered except blocks, but would be a good thing in the long run. The pywintypes.com_error should probably remain descended from plain Exception, comtypes.COMError is as well. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2010-05-19 10:45 Message: I agree that if the exception was created today it probably should inherit from WindowsError, but I am skeptical that the pain this causes is worth the pain created by breaking existing code with carefully written exception handlers - particularly as exception handlers are often hard to test, so the breakage may not be obvious until a rarely hit exception is encountered. The work-around for you would seem to simply use 2 except clauses, but handle them in the same way. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3003706&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-05-18 22:48:55
|
Bugs item #3003706, was opened at 2010-05-18 22:48 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3003706&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: gz () Assigned to: Nobody/Anonymous (nobody) Summary: pywintypes.error should inherit from WindowsError Initial Comment: Exceptions thrown by system calls in Python functions throw an EnvironmentError subclass, ctypes.WinError creates a WindowsError, extension modules using windows system calls throw some kind of OSError, but pywin32 has its own exception type that can't be caught at the same time as any of these. This means we've got an odd case in our code, where there are two nearly identical implementations of a class, one using ctypes and one using pywin32, but the generic error handling code treated them differently because pywintypes.error isn't an EnvironmentError, see <https://bugs.launchpad.net/bzr/+bug/572201>. The current code in win32/src/PyWinTypesmodule.cpp is like: class error(Exception): def __init__(self, *args, **kw): self.winerror, self.funcname, self.strerror = args[:3] Exception.__init__(self, *args, **kw) It could be changed to something along the lines of: class error(WindowsException): def __init__(self, winerror, strerror, funcname, filename=None): WindowsException.__init__(self, winerror, strerror, filename) self.funcname = funcname This would also mean it got pretty stringifying rather than the ugly 3-tuple repr it has currently. Changing the base type probably would break some code with carefully ordered except blocks, but would be a good thing in the long run. The pywintypes.com_error should probably remain descended from plain Exception, comtypes.COMError is as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3003706&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-05-17 07:49:35
|
Bugs item #2934349, was opened at 2010-01-18 17:39 Message generated for change (Comment added) made by davydm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2934349&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: Eino Mäkitalo (emakital) Assigned to: Nobody/Anonymous (nobody) Summary: python 3.1 and pywin 214 gives some errors when installing Initial Comment: python 3.1 and pywin 214 gives some errors when installing: Traceback (most recent call last): File "<string>", line 601, in <module> File "<string>", line 329, in install File "<string>", line 15, in write AttributeError: 'NoneType' object has no attribute 'write' ---------------------------------------------------------------------- Comment By: Davyd McColl (davydm) Date: 2010-05-17 09:49 Message: I still see this on selected machines. I haven't been able to narrow down what makes these machines different though. I've seen the problem appear (and not appear) on WinXP and Win7 (32 and 64-bit). My machine is win7 64-bit and the error doesn't appear. I have mixed users -- some get the error, some don't. The net result is that certain bits of pywin32 aren't usable. The users all have the pywin32 dll's in the correct places (SysWOW64 for 64-bit and System32 for 32-bit). ---------------------------------------------------------------------- Comment By: easperhe (easperhe) Date: 2010-04-09 20:25 Message: Eino, All, Was this issue resolved?? I'm trying to install pywin 214 with python 3.1.2 on windows 7 (32-bit) and seeing exactly the same problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2934349&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-05-16 14:13:59
|
Patches item #3002383, was opened at 2010-05-16 10:13 Message generated for change (Tracker Item Submitted) made by olonho You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3002383&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: Nikolay Igotti (olonho) Assigned to: Nobody/Anonymous (nobody) Summary: amd64 COM callbacks Initial Comment: Patch to generate COM wrappers on 64-bit windows. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3002383&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-05-10 22:58:24
|
Bugs item #2999657, was opened at 2010-05-10 22:58 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2999657&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: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: help() failure Initial Comment: This pretty much says it all: help("os.urandom")Firing event 'ProcessEnter' failed. Traceback (most recent call last): File "C:\Python26\Lib\site-packages\pythonwin\pywin\scintilla\bindings.py", line 142, in fire rc = binding.handler(*args) File "C:\Python26\Lib\site-packages\pythonwin\pywin\framework\interact.py", line 453, in ProcessEnterEvent if self.HandleSpecialLine(): return 0 File "C:\Python26\Lib\site-packages\pythonwin\pywin\framework\winout.py", line 152, in HandleSpecialLine line = self.GetLine(lineNo-1) File "C:\Python26\Lib\site-packages\pythonwin\pywin\scintilla\control.py", line 373, in GetLine return self.GetTextRange(start, end) File "C:\Python26\Lib\site-packages\pythonwin\pywin\scintilla\control.py", line 362, in GetTextRange ret = ret.decode(default_scintilla_encoding) File "C:\Python26\lib\encodings\utf_8.py", line 16, in decode return codecs.utf_8_decode(input, errors, True) UnicodeDecodeError: 'utf8' codec can't decode bytes in position 0-2: invalid data Help->About reports pywin32 build214 Running Python 2.6.5 from python.org locally. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2999657&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-05-09 14:18:57
|
Bugs item #2997392, was opened at 2010-05-05 20:39 Message generated for change (Settings changed) made by rupole You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2997392&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: Paul Heinz (zunzster) Assigned to: Nobody/Anonymous (nobody) Summary: Debugger stack trace failure in 213 and later Initial Comment: Running against Python 2.5.4 When debugging the stack trace view only sees the top level stack frame in 213 and later builds when debugging for me. ---------------------------------------------------------------------- >Comment By: Roger Upole (rupole) Date: 2010-05-09 09:18 Message: Fixed in debugger.py r 1.25 ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2010-05-09 05:24 Message: The problem seems to be in \Pythonwin\pywin\tools\browser.py, lines 33 and 34. The name is truncated at 20 chars, and the name is used to check if a new item is being added. For frame stack items, the names all wind up as "<frame object at 0x00...", which of course all compare equal. Looks like this can be overriden by passing a name to HierListItem.__init__ (debugger.py, line 55). ---------------------------------------------------------------------- Comment By: Paul Heinz (zunzster) Date: 2010-05-05 23:47 Message: The list of HierFrameItems returned from HierStackRoot.GetSubList seem to be correct. Also, if I place a breakpoint a few methods in, the initial stack frame is correct. So it appears to be _subsequent_ calls to GetSubList that are mishandled. ---------------------------------------------------------------------- Comment By: Paul Heinz (zunzster) Date: 2010-05-05 23:24 Message: After a bit of debugging the debugger :-), it appears the problem doesn't seem to be the debugger itself but rather the treeview control mishandling the insertion of the frame objects. It seems to keep duplicating the deepest last tree entry rather than inserting the laster stack frame entries at the top. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2997392&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-05-09 10:24:35
|
Bugs item #2997392, was opened at 2010-05-05 20:39 Message generated for change (Comment added) made by rupole You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2997392&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: Paul Heinz (zunzster) Assigned to: Nobody/Anonymous (nobody) Summary: Debugger stack trace failure in 213 and later Initial Comment: Running against Python 2.5.4 When debugging the stack trace view only sees the top level stack frame in 213 and later builds when debugging for me. ---------------------------------------------------------------------- >Comment By: Roger Upole (rupole) Date: 2010-05-09 05:24 Message: The problem seems to be in \Pythonwin\pywin\tools\browser.py, lines 33 and 34. The name is truncated at 20 chars, and the name is used to check if a new item is being added. For frame stack items, the names all wind up as "<frame object at 0x00...", which of course all compare equal. Looks like this can be overriden by passing a name to HierListItem.__init__ (debugger.py, line 55). ---------------------------------------------------------------------- Comment By: Paul Heinz (zunzster) Date: 2010-05-05 23:47 Message: The list of HierFrameItems returned from HierStackRoot.GetSubList seem to be correct. Also, if I place a breakpoint a few methods in, the initial stack frame is correct. So it appears to be _subsequent_ calls to GetSubList that are mishandled. ---------------------------------------------------------------------- Comment By: Paul Heinz (zunzster) Date: 2010-05-05 23:24 Message: After a bit of debugging the debugger :-), it appears the problem doesn't seem to be the debugger itself but rather the treeview control mishandling the insertion of the frame objects. It seems to keep duplicating the deepest last tree entry rather than inserting the laster stack frame entries at the top. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2997392&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-05-07 20:04:54
|
Bugs item #2998318, was opened at 2010-05-07 16:53 Message generated for change (Comment added) made by oscarl-2 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2998318&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: 7 Private: No Submitted By: Oscar Lesta (oscarl-2) Assigned to: Nobody/Anonymous (nobody) Summary: Python doesn't works with Windows Scripting Host anymore. Initial Comment: In a clean WinXP Pro install, I've installed ActivePython-3.1.2.3-win32-x86.msi. Trying to execute the following script: -------- C:\test.vbs ---------- set x = CreateObject("Python") ------------------------------- Fails with the followin information: -------------------------- Windows Scripting Host: Line: 1 Character: 1 Error: ActiveX component can't create object: 'Python' Code: 800A01AD Origen: Microsoft VBScript runtime error -------------------------- Just to be sure, I executed the following lines: C:\Python31\Lib\site-packages\win32comext\axscript\client>pyscript.py Registered: Python C:\Python31\Lib\site-packages\win32comext\axscript\client>cd C:\ Rerunning C:\>test.vbs now doesn't shows the previous error, but a new one stating that: "the application could not be started because MSVCR90.DLL was not found". Installing the Visual C++ 9 Runtime redistributable from Microsoft (file vcredist_x86.exe) does not improves the situation. The same happens with: ActivePython-2.6.5.12-win32-x86.msi and with http://www.python.org/ftp/python/2.7/python-2.7b1.msi But it works OK with: ActivePython-2.5.4.3-win32-x86.msi ---------------------------------------------------------------------- >Comment By: Oscar Lesta (oscarl-2) Date: 2010-05-07 17:04 Message: Trying to run the following code (saved as test.wsf): <Job Id="WshTest"> <script language="Python.AXScript.2"> import sys import win32com.client import win32api ws = win32com.client.Dispatch("WScript.Shell") ws.popup("Hello from Python!") </script> </job> Shows two error messages, the first stating the missing MSVCR90.DLL, the second with the folling info: -------------------------- Windows Scripting Host: Command sequence: C:\test.wsf Line: 0 Character: 1 Error: : Python.AXScript.2 Code: 8007007E Origin: Microsoft VBScript runtime error -------------------------- ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2998318&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-05-07 19:53:01
|
Bugs item #2998318, was opened at 2010-05-07 16:53 Message generated for change (Tracker Item Submitted) made by oscarl-2 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2998318&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: Oscar Lesta (oscarl-2) Assigned to: Nobody/Anonymous (nobody) Summary: Python doesn't works with Windows Scripting Host anymore. Initial Comment: In a clean WinXP Pro install, I've installed ActivePython-3.1.2.3-win32-x86.msi. Trying to execute the following script: -------- C:\test.vbs ---------- set x = CreateObject("Python") ------------------------------- Fails with the followin information: -------------------------- Windows Scripting Host: Line: 1 Character: 1 Error: ActiveX component can't create object: 'Python' Code: 800A01AD Origen: Microsoft VBScript runtime error -------------------------- Just to be sure, I executed the following lines: C:\Python31\Lib\site-packages\win32comext\axscript\client>pyscript.py Registered: Python C:\Python31\Lib\site-packages\win32comext\axscript\client>cd C:\ Rerunning C:\>test.vbs now doesn't shows the previous error, but a new one stating that: "the application could not be started because MSVCR90.DLL was not found". Installing the Visual C++ 9 Runtime redistributable from Microsoft (file vcredist_x86.exe) does not improves the situation. The same happens with: ActivePython-2.6.5.12-win32-x86.msi and with http://www.python.org/ftp/python/2.7/python-2.7b1.msi But it works OK with: ActivePython-2.5.4.3-win32-x86.msi ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2998318&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-05-06 04:47:46
|
Bugs item #2997392, was opened at 2010-05-06 13:39 Message generated for change (Comment added) made by zunzster You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2997392&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: Paul Heinz (zunzster) Assigned to: Nobody/Anonymous (nobody) Summary: Debugger stack trace failure in 213 and later Initial Comment: Running against Python 2.5.4 When debugging the stack trace view only sees the top level stack frame in 213 and later builds when debugging for me. ---------------------------------------------------------------------- Comment By: Paul Heinz (zunzster) Date: 2010-05-06 16:47 Message: The list of HierFrameItems returned from HierStackRoot.GetSubList seem to be correct. Also, if I place a breakpoint a few methods in, the initial stack frame is correct. So it appears to be _subsequent_ calls to GetSubList that are mishandled. ---------------------------------------------------------------------- Comment By: Paul Heinz (zunzster) Date: 2010-05-06 16:24 Message: After a bit of debugging the debugger :-), it appears the problem doesn't seem to be the debugger itself but rather the treeview control mishandling the insertion of the frame objects. It seems to keep duplicating the deepest last tree entry rather than inserting the laster stack frame entries at the top. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2997392&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-05-06 04:25:00
|
Bugs item #2997392, was opened at 2010-05-06 13:39 Message generated for change (Comment added) made by zunzster You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2997392&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: Paul Heinz (zunzster) Assigned to: Nobody/Anonymous (nobody) Summary: Debugger stack trace failure in 213 and later Initial Comment: Running against Python 2.5.4 When debugging the stack trace view only sees the top level stack frame in 213 and later builds when debugging for me. ---------------------------------------------------------------------- >Comment By: Paul Heinz (zunzster) Date: 2010-05-06 16:24 Message: After a bit of debugging the debugger :-), it appears the problem doesn't seem to be the debugger itself but rather the treeview control mishandling the insertion of the frame objects. It seems to keep duplicating the deepest last tree entry rather than inserting the laster stack frame entries at the top. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2997392&group_id=78018 |
2 messages has been excluded from this view by a project administrator.
