pywin32-bugs Mailing List for Python for Windows Extensions (Page 89)
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...> - 2005-03-22 23:52:49
|
Bugs item #1168761, was opened at 2005-03-23 00:52 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=1168761&group_id=78018 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: ingesson (ingesson) Assigned to: Nobody/Anonymous (nobody) Summary: win32gui.EnumChildWindows() crashes when no children Initial Comment: When the method win32gui.EnumChildWindows(hwnd, callback, extra) finds the window for which to return children but the window doesn't have any children it crashes with the error: "pywintypes.error: (0, 'EnumChildWindows', 'No error message is available')". The correct behavior should be to return a empty list. However as Mark has pointed out on python-win32 mail list this may be an unsafe change for already written code expecting an exception if a empty list is returned instead. In which case, at least an exception with a error description should be thrown. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1168761&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-03-22 18:41:14
|
Bugs item #1168575, was opened at 2005-03-22 13:41 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=1168575&group_id=78018 Category: pythonwin Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthew Harelick (mharelick) Assigned to: Nobody/Anonymous (nobody) Summary: makepy crashes pythonwin Initial Comment: Makepy crashes pythonwin when attempting to make the python com for Microsoft Excel 10.0 library. OS: Microsoft XP Professional "Error Signature" information AppName: pythonwin.exe ModVer: 5.1.2600.2180 AppVer: 0.0.0.0 Modname: ntdlldll Offset: 00011e58 Here is the version information from the pythonwin prompt: PythonWin 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit (Intel)] on win32. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1168575&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-03-21 14:21:11
|
Bugs item #1167608, was opened at 2005-03-21 15:21 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=1167608&group_id=78018 Category: win32 Group: None Status: Open Resolution: None Priority: 5 Submitted By: Giovanni Bajo (giovannibajo) Assigned to: Nobody/Anonymous (nobody) Summary: win32gui.GetCapture seems broken Initial Comment: Hello, it looks like win32gui.GetCapture is broken: >>> import win32gui >>> win32gui.GetCapture() Traceback (most recent call last): File "<stdin>", line 1, in ? pywintypes.error: (0, 'GetCapture', 'No error message is available') >>> import ctypes >>> ctypes.windll.user32.GetCapture() 0 As you can see, it always reports an exception with win32gui, I don't know why. My workaround of using ctypes for it seems to fix the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1167608&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-03-21 12:27:33
|
Bugs item #1166627, was opened at 2005-03-20 07:30 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1166627&group_id=78018 Category: com Group: None Status: Open >Resolution: Accepted >Priority: 8 Submitted By: Boris Nazaroff (bor-ka) >Assigned to: Mark Hammond (mhammond) Summary: Makepy do not work for python-2.4.1c2 Initial Comment: I've tried to install python-2.4.1c2 and pywin32 - (build 203 for 2.4). And when trying to use makepy on MSXML-4 or MSXML-3 it just bailed out with syntax error somewhere in the generated py-file. (Moreover, i've tried com tests - many of them have failed). Also I've tried latest CVS snapshot as of 10:00 (GMT+3) 19-Mar, have built it with MSVS 7.1 - no luck. I cannot decide if this is related to the "long code" bug, since (1) python do not crash, it just report syntax error and (2) this "long code" appears to be fixed at this moment. So I desided to add this issue as a new bug. Unfortunately I cannot check it with python 2.4 now, I'll report on this later. (Since latest ActiveState Python build works fine for me with python 2.4, and, as I think with pywin January snapshot - there were some pathches for overflows in the generation). I'll attach generated gen-py file and the error message, may be it'll help. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2005-03-21 23:27 Message: Logged In: YES user_id=14198 I can repro this - thanks! See http://www.python.org/sf/1163244 ---------------------------------------------------------------------- Comment By: Boris Nazaroff (bor-ka) Date: 2005-03-21 20:03 Message: Logged In: YES user_id=1242633 Ok, I've tried it on python 2.4 and 2.4.1c2. Generated {CLSID}.py file on 2.4.1c2. 2.4 imports it Ok 2.4.1c2 reports error in this module I do not know Python enough ot decide if this is a bug in 2.4.1c2 (or in 2.4 contrary, that parsed errorneous file Ok instead of producing an error). If this is a bug in 2.4.1c2, should it be reported to python project? ---------------------------------------------------------------------- Comment By: Boris Nazaroff (bor-ka) Date: 2005-03-21 04:07 Message: Logged In: YES user_id=1242633 It appears that it 'errs' in random place, at least I have tried several COMs and haven't succeeded in finding a patter, except that it always in the comment after some function. I'll try to reproduce it on another computer at work. May be it is 2.4.1 that is broken... ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-03-20 21:28 Message: Logged In: YES user_id=14198 That is a very strange error - I can see no problem with the generated file, and the error in the traceback is clearly referencing a 'return' in a comment. I've never seen anything like it :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1166627&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-03-21 09:03:02
|
Bugs item #1166627, was opened at 2005-03-19 23:30 Message generated for change (Comment added) made by bor-ka You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1166627&group_id=78018 Category: com Group: None Status: Open Resolution: None Priority: 5 Submitted By: Boris Nazaroff (bor-ka) Assigned to: Nobody/Anonymous (nobody) Summary: Makepy do not work for python-2.4.1c2 Initial Comment: I've tried to install python-2.4.1c2 and pywin32 - (build 203 for 2.4). And when trying to use makepy on MSXML-4 or MSXML-3 it just bailed out with syntax error somewhere in the generated py-file. (Moreover, i've tried com tests - many of them have failed). Also I've tried latest CVS snapshot as of 10:00 (GMT+3) 19-Mar, have built it with MSVS 7.1 - no luck. I cannot decide if this is related to the "long code" bug, since (1) python do not crash, it just report syntax error and (2) this "long code" appears to be fixed at this moment. So I desided to add this issue as a new bug. Unfortunately I cannot check it with python 2.4 now, I'll report on this later. (Since latest ActiveState Python build works fine for me with python 2.4, and, as I think with pywin January snapshot - there were some pathches for overflows in the generation). I'll attach generated gen-py file and the error message, may be it'll help. ---------------------------------------------------------------------- >Comment By: Boris Nazaroff (bor-ka) Date: 2005-03-21 12:03 Message: Logged In: YES user_id=1242633 Ok, I've tried it on python 2.4 and 2.4.1c2. Generated {CLSID}.py file on 2.4.1c2. 2.4 imports it Ok 2.4.1c2 reports error in this module I do not know Python enough ot decide if this is a bug in 2.4.1c2 (or in 2.4 contrary, that parsed errorneous file Ok instead of producing an error). If this is a bug in 2.4.1c2, should it be reported to python project? ---------------------------------------------------------------------- Comment By: Boris Nazaroff (bor-ka) Date: 2005-03-20 20:07 Message: Logged In: YES user_id=1242633 It appears that it 'errs' in random place, at least I have tried several COMs and haven't succeeded in finding a patter, except that it always in the comment after some function. I'll try to reproduce it on another computer at work. May be it is 2.4.1 that is broken... ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-03-20 13:28 Message: Logged In: YES user_id=14198 That is a very strange error - I can see no problem with the generated file, and the error in the traceback is clearly referencing a 'return' in a comment. I've never seen anything like it :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1166627&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-03-20 17:07:16
|
Bugs item #1166627, was opened at 2005-03-19 23:30 Message generated for change (Comment added) made by bor-ka You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1166627&group_id=78018 Category: com Group: None Status: Open Resolution: None Priority: 5 Submitted By: Boris Nazaroff (bor-ka) Assigned to: Nobody/Anonymous (nobody) Summary: Makepy do not work for python-2.4.1c2 Initial Comment: I've tried to install python-2.4.1c2 and pywin32 - (build 203 for 2.4). And when trying to use makepy on MSXML-4 or MSXML-3 it just bailed out with syntax error somewhere in the generated py-file. (Moreover, i've tried com tests - many of them have failed). Also I've tried latest CVS snapshot as of 10:00 (GMT+3) 19-Mar, have built it with MSVS 7.1 - no luck. I cannot decide if this is related to the "long code" bug, since (1) python do not crash, it just report syntax error and (2) this "long code" appears to be fixed at this moment. So I desided to add this issue as a new bug. Unfortunately I cannot check it with python 2.4 now, I'll report on this later. (Since latest ActiveState Python build works fine for me with python 2.4, and, as I think with pywin January snapshot - there were some pathches for overflows in the generation). I'll attach generated gen-py file and the error message, may be it'll help. ---------------------------------------------------------------------- >Comment By: Boris Nazaroff (bor-ka) Date: 2005-03-20 20:07 Message: Logged In: YES user_id=1242633 It appears that it 'errs' in random place, at least I have tried several COMs and haven't succeeded in finding a patter, except that it always in the comment after some function. I'll try to reproduce it on another computer at work. May be it is 2.4.1 that is broken... ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-03-20 13:28 Message: Logged In: YES user_id=14198 That is a very strange error - I can see no problem with the generated file, and the error in the traceback is clearly referencing a 'return' in a comment. I've never seen anything like it :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1166627&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-03-20 10:28:51
|
Bugs item #1166627, was opened at 2005-03-20 07:30 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1166627&group_id=78018 Category: com Group: None Status: Open Resolution: None Priority: 5 Submitted By: Boris Nazaroff (bor-ka) Assigned to: Nobody/Anonymous (nobody) Summary: Makepy do not work for python-2.4.1c2 Initial Comment: I've tried to install python-2.4.1c2 and pywin32 - (build 203 for 2.4). And when trying to use makepy on MSXML-4 or MSXML-3 it just bailed out with syntax error somewhere in the generated py-file. (Moreover, i've tried com tests - many of them have failed). Also I've tried latest CVS snapshot as of 10:00 (GMT+3) 19-Mar, have built it with MSVS 7.1 - no luck. I cannot decide if this is related to the "long code" bug, since (1) python do not crash, it just report syntax error and (2) this "long code" appears to be fixed at this moment. So I desided to add this issue as a new bug. Unfortunately I cannot check it with python 2.4 now, I'll report on this later. (Since latest ActiveState Python build works fine for me with python 2.4, and, as I think with pywin January snapshot - there were some pathches for overflows in the generation). I'll attach generated gen-py file and the error message, may be it'll help. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2005-03-20 21:28 Message: Logged In: YES user_id=14198 That is a very strange error - I can see no problem with the generated file, and the error in the traceback is clearly referencing a 'return' in a comment. I've never seen anything like it :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1166627&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-03-19 20:30:48
|
Bugs item #1166627, was opened at 2005-03-19 23:30 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=1166627&group_id=78018 Category: com Group: None Status: Open Resolution: None Priority: 5 Submitted By: Boris Nazaroff (bor-ka) Assigned to: Nobody/Anonymous (nobody) Summary: Makepy do not work for python-2.4.1c2 Initial Comment: I've tried to install python-2.4.1c2 and pywin32 - (build 203 for 2.4). And when trying to use makepy on MSXML-4 or MSXML-3 it just bailed out with syntax error somewhere in the generated py-file. (Moreover, i've tried com tests - many of them have failed). Also I've tried latest CVS snapshot as of 10:00 (GMT+3) 19-Mar, have built it with MSVS 7.1 - no luck. I cannot decide if this is related to the "long code" bug, since (1) python do not crash, it just report syntax error and (2) this "long code" appears to be fixed at this moment. So I desided to add this issue as a new bug. Unfortunately I cannot check it with python 2.4 now, I'll report on this later. (Since latest ActiveState Python build works fine for me with python 2.4, and, as I think with pywin January snapshot - there were some pathches for overflows in the generation). I'll attach generated gen-py file and the error message, may be it'll help. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1166627&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-03-16 23:01:42
|
Bugs item #1160437, was opened at 2005-03-10 18:27 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1160437&group_id=78018 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: 江文 (jiangwen365) Assigned to: Nobody/Anonymous (nobody) Summary: Connect different DSNs servial times and Python would crash. Initial Comment: Hi, When I run the script listed below, Python VM would crash, and usually within 20 seconds. "HScode_MDB" is the ODBC DSN pointing to an Access MDB file, "HScode" is the ODBC DSN pointing to a PostgreSQL Server. Dunno it's a bug of ODBC module or the ODBC drivers. But somehow it seems more like the ODBC module's bug. import dbi,odbc while True: print 'connecting MDB' a=odbc.odbc("HScode_MDB") # a DSN print 'getting MDB cursor' ac=a.cursor() ac.execute('SELECT * FROM [latest_parts]') # some operations ac.fetchall() ac.close() a.close() print 'connecting Postgres' b=odbc.odbc("HScode") # another DSN print 'getting postgres cursor' bc=b.cursor() bc.execute('select * from latest_parts limit 1') # some operations #print bc.fetchall() bc.close() b.close() ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2005-03-17 10:01 Message: Logged In: YES user_id=14198 I don't have a postgres DB server available to me, so am unable to reproduce this crash. If you can make a connection available to me and give me a complete script that demonstrates the error against the connection, I'd be happy to help diagnose it. ---------------------------------------------------------------------- Comment By: 江文 (jiangwen365) Date: 2005-03-10 19:58 Message: Logged In: YES user_id=1147025 Another strangeness found: Increase the number after LIMIT, say 7, and Python could go further, maybe 60 loops; increase it to 100, and Python could almost pass the loop block successfully! Maybe it's still Python's bug? I'm confused. 'select * from latest_parts limit 100' ---------------------------------------------------------------------- Comment By: 江文 (jiangwen365) Date: 2005-03-10 19:19 Message: Logged In: YES user_id=1147025 Oh, when commenting out the MDB block and leaving the Postgres block, Python would crash much sooner. Exactly the fifith loop, aftter printing out "connecting Postgres" on my machine! But it seems to work pretty smoothly with the MDB block only. So it's more likly a Postgres ODBC driver bug. I'v submitted this to the postgres odbc developer group: http://gborg.postgresql.org/project/psqlodbc/bugs/bugupdate.php?1207 I don't know if it would be helpful if somebody here can provide some debug info to the postgres ODBC team? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1160437&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-03-15 08:19:11
|
Bugs item #1163188, was opened at 2005-03-14 18:44 Message generated for change (Comment added) made by andyrathbone You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1163188&group_id=78018 Category: installation Group: None Status: Open Resolution: None Priority: 7 Submitted By: bob gailer (ramrom) Assigned to: Nobody/Anonymous (nobody) Summary: Can't load Python for preinstalled script Initial Comment: Attempting to load build 203 gives this (to me meaningless) error "Can't load Python for preinstalled script". ---------------------------------------------------------------------- Comment By: Ratters (andyrathbone) Date: 2005-03-15 08:19 Message: Logged In: YES user_id=1239441 The same thing has happened to me - how does one get around this? ---------------------------------------------------------------------- Comment By: bob gailer (ramrom) Date: 2005-03-14 18:50 Message: Logged In: YES user_id=587593 I also notice that none of the prior bug reports have been resolved. I'm upping this to priority 7. ---------------------------------------------------------------------- Comment By: bob gailer (ramrom) Date: 2005-03-14 18:46 Message: Logged In: YES user_id=587593 I see prior bug reports pointing to same problem. Can this error text be changed to be more meaningful? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1163188&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-03-14 18:50:21
|
Bugs item #1163188, was opened at 2005-03-14 11:44 Message generated for change (Comment added) made by ramrom You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1163188&group_id=78018 Category: installation Group: None Status: Open Resolution: None >Priority: 7 Submitted By: bob gailer (ramrom) Assigned to: Nobody/Anonymous (nobody) Summary: Can't load Python for preinstalled script Initial Comment: Attempting to load build 203 gives this (to me meaningless) error "Can't load Python for preinstalled script". ---------------------------------------------------------------------- >Comment By: bob gailer (ramrom) Date: 2005-03-14 11:50 Message: Logged In: YES user_id=587593 I also notice that none of the prior bug reports have been resolved. I'm upping this to priority 7. ---------------------------------------------------------------------- Comment By: bob gailer (ramrom) Date: 2005-03-14 11:46 Message: Logged In: YES user_id=587593 I see prior bug reports pointing to same problem. Can this error text be changed to be more meaningful? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1163188&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-03-14 18:46:37
|
Bugs item #1163188, was opened at 2005-03-14 11:44 Message generated for change (Comment added) made by ramrom You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1163188&group_id=78018 Category: installation Group: None Status: Open Resolution: None Priority: 5 Submitted By: bob gailer (ramrom) Assigned to: Nobody/Anonymous (nobody) Summary: Can't load Python for preinstalled script Initial Comment: Attempting to load build 203 gives this (to me meaningless) error "Can't load Python for preinstalled script". ---------------------------------------------------------------------- >Comment By: bob gailer (ramrom) Date: 2005-03-14 11:46 Message: Logged In: YES user_id=587593 I see prior bug reports pointing to same problem. Can this error text be changed to be more meaningful? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1163188&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-03-14 18:44:12
|
Bugs item #1163188, was opened at 2005-03-14 11:44 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=1163188&group_id=78018 Category: installation Group: None Status: Open Resolution: None Priority: 5 Submitted By: bob gailer (ramrom) Assigned to: Nobody/Anonymous (nobody) Summary: Can't load Python for preinstalled script Initial Comment: Attempting to load build 203 gives this (to me meaningless) error "Can't load Python for preinstalled script". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1163188&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-03-13 15:24:01
|
Bugs item #935071, was opened at 2004-04-14 11:14 Message generated for change (Comment added) made by jaraco You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=935071&group_id=78018 Category: win32 Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Jason R. Coombs (jaraco) Assigned to: Nobody/Anonymous (nobody) Summary: testall.py fails with space in install path Initial Comment: When I run testall.py, some of the tests run, but others fail opening the file. It appears to be a bug with the install location and the presence of a space. Below is the output of testall on my machine. After the output below, the program hangs. Note, I have removed all non-standard modules from the test folder. Build is 200 for Python 2.3. C:\Program Files\Python\Lib\site-packages\win32 \test>testall .......................Time zone in effect is Mountain Daylight Time Next timezone change happens at 04/01/00 02:00:00 .............python.exe: can't open file 'C:\Program' python.exe: can't open file 'C:\Program' python.exe: can't open file 'C:\Program' python.exe: can't open file 'C:\Program' python.exe: can't open file 'C:\Program' ---------------------------------------------------------------------- >Comment By: Jason R. Coombs (jaraco) Date: 2005-03-13 08:23 Message: Logged In: YES user_id=599869 I apologize for any time you might have wasted on this. The problem did indeed exist on that install. The problem does not exist on a Python 2.4 install with build 203 of the win32 extensions. For that reason, and since no one else has reported this problem, I suggest the ticket just be closed. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-03-04 22:18 Message: Logged In: YES user_id=14198 Can you please try and work out which specific test is failing here? I can't see where in the test suite this could happen. Just run each .py file in that directory individually Thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=935071&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-03-10 08:58:35
|
Bugs item #1160437, was opened at 2005-03-10 07:27 Message generated for change (Comment added) made by jiangwen365 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1160437&group_id=78018 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: 江文 (jiangwen365) Assigned to: Nobody/Anonymous (nobody) Summary: Connect different DSNs servial times and Python would crash. Initial Comment: Hi, When I run the script listed below, Python VM would crash, and usually within 20 seconds. "HScode_MDB" is the ODBC DSN pointing to an Access MDB file, "HScode" is the ODBC DSN pointing to a PostgreSQL Server. Dunno it's a bug of ODBC module or the ODBC drivers. But somehow it seems more like the ODBC module's bug. import dbi,odbc while True: print 'connecting MDB' a=odbc.odbc("HScode_MDB") # a DSN print 'getting MDB cursor' ac=a.cursor() ac.execute('SELECT * FROM [latest_parts]') # some operations ac.fetchall() ac.close() a.close() print 'connecting Postgres' b=odbc.odbc("HScode") # another DSN print 'getting postgres cursor' bc=b.cursor() bc.execute('select * from latest_parts limit 1') # some operations #print bc.fetchall() bc.close() b.close() ---------------------------------------------------------------------- >Comment By: 江文 (jiangwen365) Date: 2005-03-10 08:58 Message: Logged In: YES user_id=1147025 Another strangeness found: Increase the number after LIMIT, say 7, and Python could go further, maybe 60 loops; increase it to 100, and Python could almost pass the loop block successfully! Maybe it's still Python's bug? I'm confused. 'select * from latest_parts limit 100' ---------------------------------------------------------------------- Comment By: 江文 (jiangwen365) Date: 2005-03-10 08:19 Message: Logged In: YES user_id=1147025 Oh, when commenting out the MDB block and leaving the Postgres block, Python would crash much sooner. Exactly the fifith loop, aftter printing out "connecting Postgres" on my machine! But it seems to work pretty smoothly with the MDB block only. So it's more likly a Postgres ODBC driver bug. I'v submitted this to the postgres odbc developer group: http://gborg.postgresql.org/project/psqlodbc/bugs/bugupdate.php?1207 I don't know if it would be helpful if somebody here can provide some debug info to the postgres ODBC team? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1160437&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-03-10 08:19:42
|
Bugs item #1160437, was opened at 2005-03-10 07:27 Message generated for change (Comment added) made by jiangwen365 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1160437&group_id=78018 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: 江文 (jiangwen365) Assigned to: Nobody/Anonymous (nobody) Summary: Connect different DSNs servial times and Python would crash. Initial Comment: Hi, When I run the script listed below, Python VM would crash, and usually within 20 seconds. "HScode_MDB" is the ODBC DSN pointing to an Access MDB file, "HScode" is the ODBC DSN pointing to a PostgreSQL Server. Dunno it's a bug of ODBC module or the ODBC drivers. But somehow it seems more like the ODBC module's bug. import dbi,odbc while True: print 'connecting MDB' a=odbc.odbc("HScode_MDB") # a DSN print 'getting MDB cursor' ac=a.cursor() ac.execute('SELECT * FROM [latest_parts]') # some operations ac.fetchall() ac.close() a.close() print 'connecting Postgres' b=odbc.odbc("HScode") # another DSN print 'getting postgres cursor' bc=b.cursor() bc.execute('select * from latest_parts limit 1') # some operations #print bc.fetchall() bc.close() b.close() ---------------------------------------------------------------------- >Comment By: 江文 (jiangwen365) Date: 2005-03-10 08:19 Message: Logged In: YES user_id=1147025 Oh, when commenting out the MDB block and leaving the Postgres block, Python would crash much sooner. Exactly the fifith loop, aftter printing out "connecting Postgres" on my machine! But it seems to work pretty smoothly with the MDB block only. So it's more likly a Postgres ODBC driver bug. I'v submitted this to the postgres odbc developer group: http://gborg.postgresql.org/project/psqlodbc/bugs/bugupdate.php?1207 I don't know if it would be helpful if somebody here can provide some debug info to the postgres ODBC team? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1160437&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-03-10 07:27:19
|
Bugs item #1160437, was opened at 2005-03-10 07:27 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=1160437&group_id=78018 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: 江文 (jiangwen365) Assigned to: Nobody/Anonymous (nobody) Summary: Connect different DSNs servial times and Python would crash. Initial Comment: Hi, When I run the script listed below, Python VM would crash, and usually within 20 seconds. "HScode_MDB" is the ODBC DSN pointing to an Access MDB file, "HScode" is the ODBC DSN pointing to a PostgreSQL Server. Dunno it's a bug of ODBC module or the ODBC drivers. But somehow it seems more like the ODBC module's bug. import dbi,odbc while True: print 'connecting MDB' a=odbc.odbc("HScode_MDB") # a DSN print 'getting MDB cursor' ac=a.cursor() ac.execute('SELECT * FROM [latest_parts]') # some operations ac.fetchall() ac.close() a.close() print 'connecting Postgres' b=odbc.odbc("HScode") # another DSN print 'getting postgres cursor' bc=b.cursor() bc.execute('select * from latest_parts limit 1') # some operations #print bc.fetchall() bc.close() b.close() ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1160437&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-03-07 11:26:23
|
Bugs item #1119908, was opened at 2005-02-10 09:06 Message generated for change (Comment added) made by oleaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1119908&group_id=78018 Category: win32 Group: None Status: Open Resolution: None Priority: 5 Submitted By: oleaw (oleaw) Assigned to: Nobody/Anonymous (nobody) Summary: CastTo/QueryInterface problem Initial Comment: In the COM API I am using, the following is provided: To create a new patient object I have to cast the Patient manager interface to the IDIContstructor interface. PatMgr: IDIPatientMgr; NewPat: IDIPatient; ... PatMgr := DISession.GetManagerById(miPatient) as IDIPatientMgr; NewPat := (PatMgr as IDIConstructor).CreateNew as IDIPatient; //edit the patient... //Save the changes (NewPat as IDIEdit).Save; In python I have written the following code. miPerson = 26 try: PersonMgr except NameError: PersonMgr = self.__dips_api.GetManagerById(miPerson) else: print "PersonMgr eksisterer" NewPerson = CastTo(PersonMgr, 'IDIPersonMgr') This casts PersonMgr to the right Interface. My problem is that once I use the CastTo function all of my other functions cease to work. Apparently all the objects are wrapped in PyIUnkown, and python is no longer able to find their appropriate type. This problem will persist until delete the automatically generated python COM code and restart IDLE. All the interfaces I am using are IDispatch. I have also tried to alternatively cast the interface with PersonMgr.QueryObject(IDIConstructor) and Dispatch(PersonMgr , None, 'IDIContructor'), but these functions are unable to find the interface. Have also tried with makepy Can anyone provide information on how to make CastTo work, (can I unwrap the PyIUnknown wrapper?) Ole A ---------------------------------------------------------------------- >Comment By: oleaw (oleaw) Date: 2005-03-07 11:26 Message: Logged In: YES user_id=1216110 I sill have the problem (but I have been on a two week vacation, so I haven't been working on it...). I seem to be able to get the right Interface, but get the following error when I try CreateNew(): line 327, in CreateNew ret = self._oleobj_.InvokeTypes(1, LCID, 1, (13, 0), (),) com_error: (-2147352562, 'Ugyldig antall parametere.(Invalid number of parameters)', None, None) ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-03-04 22:25 Message: Logged In: YES user_id=14198 are you still having this problem? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-02-17 22:11 Message: Logged In: YES user_id=14198 You indicate you get back an IUnknown - can you call QueryInterface on this IUnknown for IDispatch? ---------------------------------------------------------------------- Comment By: oleaw (oleaw) Date: 2005-02-16 13:07 Message: Logged In: YES user_id=1216110 The COM objects are written in Delphi ---------------------------------------------------------------------- Comment By: oleaw (oleaw) Date: 2005-02-16 13:05 Message: Logged In: YES user_id=1216110 The following code corrects the problem in a similar function, but it does not help with the CreateNew function: Patient = PatientMgr.GetPatientById ('aakajf+0000005001392') Person = Dispatch(Patient, 'IDIPerson', '{F6C0D843- DEC8-4C31-A766-12CBE59F3184}', UnicodeToString=0) Person = Person._oleobj_.QueryInterface (pythoncom.IID_IDispatch) Person = Dispatch(Person) print Person.LastName ---------------------------------------------------------------------- Comment By: oleaw (oleaw) Date: 2005-02-10 09:14 Message: Logged In: YES user_id=1216110 The line NewPerson = CastTo(PersonMgr, 'IDIPersonMgr') is NewPerson = CastTo(PersonMgr, 'IDIConstructor') and IDIContructor should be IDIConstructor This however is not the problem Ole A ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1119908&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-03-06 18:05:24
|
Bugs item #1157829, was opened at 2005-03-06 20:05 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=1157829&group_id=78018 Category: installation Group: None Status: Open Resolution: None Priority: 5 Submitted By: xet7 (xet7) Assigned to: Nobody/Anonymous (nobody) Summary: postinstall failure: LoadSystemModule on Win95 Initial Comment: On Win95 B (finnish), installed today from scratch using vmware: - IE 5.5 SP2 - Dcom for Win95 (DC95Inst) - Office 97 - Updates from WindowsUpdate.microsoft.com - python2.4.msi - wxPython2.5-win32-unicode-2.5.3.1-py24 - wxPython2.5-win32-docs-demos-2.5.3.1 - MySQL-python.exe-1.2.0.win32-py2.4 - pywin32-203.win32-py2.4 (same error with build 202) wxPython demo and all others installed and run fine, but when installing pywin32 I got error: Traceback (most recent call last): File "C:\Python24\Scripts\pywin32_postinstall.py", line 358, in ? install() File "C:\Python24\Scripts\pywin32_postinstall.py", line 155, in install LoadSystemModule(lib_dir, "pywintypes") File "C:\Python24\Scripts\pywin32_postinstall.py", line 94, in LoadSystemModule ('.dll', 'rb', imp.C_EXTENSION)) ImportError: DLL load failed: Järjestelmään kytketty laite ei toimi. (=>translation: device attached to system does not work) *** run_installscript: internal error 0xFFFFFFFF *** ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1157829&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-03-06 00:54:54
|
Bugs item #1017504, was opened at 2004-08-27 20:44 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1017504&group_id=78018 Category: pythonwin Group: None Status: Closed Resolution: Fixed Priority: 4 Submitted By: Martin Gfeller (gfe) Assigned to: Nobody/Anonymous (nobody) Summary: Debugger fills Registry with 100s of ToolbarDefault-Bar-n Initial Comment: On Windows 2000, PythonWin creates many hundreds of ToolbarDefault-Bar-n keys in the registry once the debugger is invoked (either by debug or post-mortem) and the 'go' or 'close' button is clicked. It seems to be specific to Windows 2000, where it occurs each time, and makes the debugger pretty unusable, because the registry slows down Windows to the point of unusability and instability. I could not reproduce it on Windows XP Pro. Environment: PythonWin Build 202 PythonWin 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)] on win32. Windows 2000, SP4, Build 2195 Best regards, Martin ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2005-03-06 11:54 Message: Logged In: YES user_id=14198 The problem probably appeared ok in 2.4 due to another bug which caused a crash at shutdown, possibly preventing the toolbar state from being saved (and thereby not hitting the problem). That bug was also recently fixed. ---------------------------------------------------------------------- Comment By: Colin J. Williams (cjwhrh) Date: 2005-03-06 02:12 Message: Logged In: YES user_id=285587 Thanks Mark, I'll be watching for 204. Incidentally, with very limited usage so far, I have the impression that the problem did not exist with Python 2.4.2 Colin W. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-03-05 16:07 Message: Logged In: YES user_id=14198 Fixed - will be in build 204 ---------------------------------------------------------------------- Comment By: Martin Gfeller (gfe) Date: 2005-01-10 20:25 Message: Logged In: YES user_id=884167 I never encountered this AssertionError, nevertheless the registry gets filled regularly. I zap the PyWin part of the registry now routinely after using the debugger. ---------------------------------------------------------------------- Comment By: Colin J. Williams (cjwhrh) Date: 2005-01-09 07:48 Message: Logged In: YES user_id=285587 The following traceback appears to be connected with the flood of toolbar entries to the registry of Windows XP with PythonWin build 203. The work around is to uninstall PythonWin and then remove the Python for win32 entry in the registry (uninstall doesn't do this). Finally, reinstall PythonWin. >>> Traceback (most recent call last): File "C:\Python23\Lib\site-packages\pythonwin\pywin\framework\dbgcommands.py", line 65, in OnStepOver self._DoOrStart("do_set_next", scriptutils.RS_DEBUGGER_STEP) File "C:\Python23\Lib\site-packages\pythonwin\pywin\framework\dbgcommands.py", line 57, in _DoOrStart method() File "C:\Python23\Lib\site-packages\pythonwin\pywin\debugger\debugger.py", line 632, in do_set_next if self.GUIAboutToRun(): File "C:\Python23\Lib\site-packages\pythonwin\pywin\debugger\debugger.py", line 791, in GUIAboutToRun if not self.StopDebuggerPump(): File "C:\Python23\Lib\site-packages\pythonwin\pywin\debugger\debugger.py", line 487, in StopDebuggerPump assert self.pumping, "Can't stop the debugger pump if Im not pumping!" AssertionError: Can't stop the debugger pump if Im not pumping! win32ui: Error in Command Message handler for command ID 15021, Code 0 Best wishes, Colin W. ---------------------------------------------------------------------- Comment By: Martin Gfeller (gfe) Date: 2004-12-23 08:48 Message: Logged In: YES user_id=884167 It also happens to me on Windows XP SP2 now (with PyWin 203). ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2004-10-09 15:52 Message: Logged In: YES user_id=14198 As I said in 944506: I've failed again to solve this. It sounds alot like Q151446, but that is pre MFC6, and doesn't solve the problem. It *nearly* does. I'm closing this and will keep "[ 1017504 ] Debugger fills Registry with 100s of ToolbarDefault-Bar-n" open (only as it has a better name) The next release will have that SaveBarState() call commented out. Dropping priority as this should mean the bug is much less severe. ---------------------------------------------------------------------- Comment By: bob gailer (ramrom) Date: 2004-08-28 23:19 Message: Logged In: YES user_id=587593 *This problem has also been entered under 894191 and 944506. It definitely causes problems, and has not, to my knowledge been addressed. 944506 has never been assigned! Please, someone who knows the details of what should happen help us. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1017504&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-03-05 15:12:05
|
Bugs item #1017504, was opened at 2004-08-27 06:44 Message generated for change (Comment added) made by cjwhrh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1017504&group_id=78018 Category: pythonwin Group: None Status: Closed Resolution: Fixed Priority: 4 Submitted By: Martin Gfeller (gfe) Assigned to: Nobody/Anonymous (nobody) Summary: Debugger fills Registry with 100s of ToolbarDefault-Bar-n Initial Comment: On Windows 2000, PythonWin creates many hundreds of ToolbarDefault-Bar-n keys in the registry once the debugger is invoked (either by debug or post-mortem) and the 'go' or 'close' button is clicked. It seems to be specific to Windows 2000, where it occurs each time, and makes the debugger pretty unusable, because the registry slows down Windows to the point of unusability and instability. I could not reproduce it on Windows XP Pro. Environment: PythonWin Build 202 PythonWin 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)] on win32. Windows 2000, SP4, Build 2195 Best regards, Martin ---------------------------------------------------------------------- Comment By: Colin J. Williams (cjwhrh) Date: 2005-03-05 10:12 Message: Logged In: YES user_id=285587 Thanks Mark, I'll be watching for 204. Incidentally, with very limited usage so far, I have the impression that the problem did not exist with Python 2.4.2 Colin W. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-03-05 00:07 Message: Logged In: YES user_id=14198 Fixed - will be in build 204 ---------------------------------------------------------------------- Comment By: Martin Gfeller (gfe) Date: 2005-01-10 04:25 Message: Logged In: YES user_id=884167 I never encountered this AssertionError, nevertheless the registry gets filled regularly. I zap the PyWin part of the registry now routinely after using the debugger. ---------------------------------------------------------------------- Comment By: Colin J. Williams (cjwhrh) Date: 2005-01-08 15:48 Message: Logged In: YES user_id=285587 The following traceback appears to be connected with the flood of toolbar entries to the registry of Windows XP with PythonWin build 203. The work around is to uninstall PythonWin and then remove the Python for win32 entry in the registry (uninstall doesn't do this). Finally, reinstall PythonWin. >>> Traceback (most recent call last): File "C:\Python23\Lib\site-packages\pythonwin\pywin\framework\dbgcommands.py", line 65, in OnStepOver self._DoOrStart("do_set_next", scriptutils.RS_DEBUGGER_STEP) File "C:\Python23\Lib\site-packages\pythonwin\pywin\framework\dbgcommands.py", line 57, in _DoOrStart method() File "C:\Python23\Lib\site-packages\pythonwin\pywin\debugger\debugger.py", line 632, in do_set_next if self.GUIAboutToRun(): File "C:\Python23\Lib\site-packages\pythonwin\pywin\debugger\debugger.py", line 791, in GUIAboutToRun if not self.StopDebuggerPump(): File "C:\Python23\Lib\site-packages\pythonwin\pywin\debugger\debugger.py", line 487, in StopDebuggerPump assert self.pumping, "Can't stop the debugger pump if Im not pumping!" AssertionError: Can't stop the debugger pump if Im not pumping! win32ui: Error in Command Message handler for command ID 15021, Code 0 Best wishes, Colin W. ---------------------------------------------------------------------- Comment By: Martin Gfeller (gfe) Date: 2004-12-22 16:48 Message: Logged In: YES user_id=884167 It also happens to me on Windows XP SP2 now (with PyWin 203). ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2004-10-09 01:52 Message: Logged In: YES user_id=14198 As I said in 944506: I've failed again to solve this. It sounds alot like Q151446, but that is pre MFC6, and doesn't solve the problem. It *nearly* does. I'm closing this and will keep "[ 1017504 ] Debugger fills Registry with 100s of ToolbarDefault-Bar-n" open (only as it has a better name) The next release will have that SaveBarState() call commented out. Dropping priority as this should mean the bug is much less severe. ---------------------------------------------------------------------- Comment By: bob gailer (ramrom) Date: 2004-08-28 09:19 Message: Logged In: YES user_id=587593 *This problem has also been entered under 894191 and 944506. It definitely causes problems, and has not, to my knowledge been addressed. 944506 has never been assigned! Please, someone who knows the details of what should happen help us. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1017504&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-03-05 05:18:09
|
Bugs item #935071, was opened at 2004-04-15 03:14 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=935071&group_id=78018 Category: win32 Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason R. Coombs (jaraco) Assigned to: Nobody/Anonymous (nobody) Summary: testall.py fails with space in install path Initial Comment: When I run testall.py, some of the tests run, but others fail opening the file. It appears to be a bug with the install location and the presence of a space. Below is the output of testall on my machine. After the output below, the program hangs. Note, I have removed all non-standard modules from the test folder. Build is 200 for Python 2.3. C:\Program Files\Python\Lib\site-packages\win32 \test>testall .......................Time zone in effect is Mountain Daylight Time Next timezone change happens at 04/01/00 02:00:00 .............python.exe: can't open file 'C:\Program' python.exe: can't open file 'C:\Program' python.exe: can't open file 'C:\Program' python.exe: can't open file 'C:\Program' python.exe: can't open file 'C:\Program' ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2005-03-05 16:18 Message: Logged In: YES user_id=14198 Can you please try and work out which specific test is failing here? I can't see where in the test suite this could happen. Just run each .py file in that directory individually Thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=935071&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-03-05 05:08:02
|
Bugs item #1017504, was opened at 2004-08-27 20:44 Message generated for change (Settings changed) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1017504&group_id=78018 Category: pythonwin Group: None >Status: Closed >Resolution: Fixed Priority: 4 Submitted By: Martin Gfeller (gfe) Assigned to: Nobody/Anonymous (nobody) Summary: Debugger fills Registry with 100s of ToolbarDefault-Bar-n Initial Comment: On Windows 2000, PythonWin creates many hundreds of ToolbarDefault-Bar-n keys in the registry once the debugger is invoked (either by debug or post-mortem) and the 'go' or 'close' button is clicked. It seems to be specific to Windows 2000, where it occurs each time, and makes the debugger pretty unusable, because the registry slows down Windows to the point of unusability and instability. I could not reproduce it on Windows XP Pro. Environment: PythonWin Build 202 PythonWin 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)] on win32. Windows 2000, SP4, Build 2195 Best regards, Martin ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2005-03-05 16:07 Message: Logged In: YES user_id=14198 Fixed - will be in build 204 ---------------------------------------------------------------------- Comment By: Martin Gfeller (gfe) Date: 2005-01-10 20:25 Message: Logged In: YES user_id=884167 I never encountered this AssertionError, nevertheless the registry gets filled regularly. I zap the PyWin part of the registry now routinely after using the debugger. ---------------------------------------------------------------------- Comment By: Colin J. Williams (cjwhrh) Date: 2005-01-09 07:48 Message: Logged In: YES user_id=285587 The following traceback appears to be connected with the flood of toolbar entries to the registry of Windows XP with PythonWin build 203. The work around is to uninstall PythonWin and then remove the Python for win32 entry in the registry (uninstall doesn't do this). Finally, reinstall PythonWin. >>> Traceback (most recent call last): File "C:\Python23\Lib\site-packages\pythonwin\pywin\framework\dbgcommands.py", line 65, in OnStepOver self._DoOrStart("do_set_next", scriptutils.RS_DEBUGGER_STEP) File "C:\Python23\Lib\site-packages\pythonwin\pywin\framework\dbgcommands.py", line 57, in _DoOrStart method() File "C:\Python23\Lib\site-packages\pythonwin\pywin\debugger\debugger.py", line 632, in do_set_next if self.GUIAboutToRun(): File "C:\Python23\Lib\site-packages\pythonwin\pywin\debugger\debugger.py", line 791, in GUIAboutToRun if not self.StopDebuggerPump(): File "C:\Python23\Lib\site-packages\pythonwin\pywin\debugger\debugger.py", line 487, in StopDebuggerPump assert self.pumping, "Can't stop the debugger pump if Im not pumping!" AssertionError: Can't stop the debugger pump if Im not pumping! win32ui: Error in Command Message handler for command ID 15021, Code 0 Best wishes, Colin W. ---------------------------------------------------------------------- Comment By: Martin Gfeller (gfe) Date: 2004-12-23 08:48 Message: Logged In: YES user_id=884167 It also happens to me on Windows XP SP2 now (with PyWin 203). ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2004-10-09 15:52 Message: Logged In: YES user_id=14198 As I said in 944506: I've failed again to solve this. It sounds alot like Q151446, but that is pre MFC6, and doesn't solve the problem. It *nearly* does. I'm closing this and will keep "[ 1017504 ] Debugger fills Registry with 100s of ToolbarDefault-Bar-n" open (only as it has a better name) The next release will have that SaveBarState() call commented out. Dropping priority as this should mean the bug is much less severe. ---------------------------------------------------------------------- Comment By: bob gailer (ramrom) Date: 2004-08-28 23:19 Message: Logged In: YES user_id=587593 *This problem has also been entered under 894191 and 944506. It definitely causes problems, and has not, to my knowledge been addressed. 944506 has never been assigned! Please, someone who knows the details of what should happen help us. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1017504&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-03-05 05:06:53
|
Bugs item #1051453, was opened at 2004-10-21 22:53 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1051453&group_id=78018 Category: win32 Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Nobody/Anonymous (nobody) Summary: win32pdhutil.browse broken (intentionally?) Initial Comment: The win32pdhutil.browse function no longer displays a dialog as documented in the "Python Programming on Win32" book. Looking at the CVS history, revision 1.6 removed the call to win32pdh.BrowseCounters and the subsequent "def test():" declaration, so that the code which was in the test function is now in browse. I'm wondering if this was an accident, since browse still takes the same parameters, but it doesn't use them. If the change was intentional, I think some comment explaining it is in order, especially since BrowseCounters still seems to work just fine given the parameters browse was giving it. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2005-03-05 16:06 Message: Logged In: YES user_id=14198 Thanks - that was indeed a mistake! Checking in win32pdhutil.py; new revision: 1.9; previous revision: 1.8 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1051453&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-03-05 04:57:25
|
Bugs item #1037571, was opened at 2004-09-30 17:52 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1037571&group_id=78018 Category: pythonwin Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Robert Kiendl (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: PyCFont should have .GetSafeHandle() Initial Comment: PyCFont should have .GetSafeHandle() like PyCBrush etc. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2005-03-05 15:57 Message: Logged In: YES user_id=14198 Checking in win32font.cpp; new revision: 1.3; previous revision: 1.2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1037571&group_id=78018 |
2 messages has been excluded from this view by a project administrator.
