pywin32-bugs Mailing List for Python for Windows Extensions (Page 75)
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...> - 2006-04-25 23:58:25
|
Bugs item #1476208, was opened at 2006-04-26 01:58 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1476208&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: Duplicate Priority: 5 Submitted By: kxroberto (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: 208/py2.3: Registry ToolbarDebugging-Bar964 Initial Comment: After some debugging sessions (pywin.debuger.pm()... some irregular "not pumping" states as it happens sometime ..) there are about 1000 of ToolbarDebugging-BarXXX folders filed up in the registry: some 20 in "Pythonwin Debugger" and some 900+ in "Python for Win32" Starting and exiting Pythonwin very slow (thus always saves all?) robert --- PythonWin 2.3.5 (#62, Feb 8 2005, 16:23:02) [MSC v.1200 32 bit (Intel)] on win32. Portions Copyright 1994-2004 Mark Hammond (mha...@sk...) - see 'Help/About PythonWin' for further copyright information. >>> ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2006-04-26 09:58 Message: Logged In: YES user_id=14198 This should have been fixed a few builds ago (but sadly the fix did not include deleting the bad entries). Please try deleting those keys (or just delete the parent key) and try again - you should find only 20 or so are created (which is normal). Please reopen this bug if that is not the case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1476208&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-04-25 15:58:45
|
Bugs item #1476208, was opened at 2006-04-25 17:58 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=1476208&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 Submitted By: kxroberto (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: 208/py2.3: Registry ToolbarDebugging-Bar964 Initial Comment: After some debugging sessions (pywin.debuger.pm()... some irregular "not pumping" states as it happens sometime ..) there are about 1000 of ToolbarDebugging-BarXXX folders filed up in the registry: some 20 in "Pythonwin Debugger" and some 900+ in "Python for Win32" Starting and exiting Pythonwin very slow (thus always saves all?) robert --- PythonWin 2.3.5 (#62, Feb 8 2005, 16:23:02) [MSC v.1200 32 bit (Intel)] on win32. Portions Copyright 1994-2004 Mark Hammond (mha...@sk...) - see 'Help/About PythonWin' for further copyright information. >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1476208&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-04-24 11:47:52
|
Bugs item #1475467, was opened at 2006-04-24 13:47 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=1475467&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 Submitted By: kxroberto (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: win32ui: Internal error-existing object is not of same type? Initial Comment: I get rare reports with this error: "win32ui: Internal error - existing object is not of same type as requested new object" (the last was on a Win XP Prof; build 208 or build205 - not sure) it traces to a bare: tt=win32ui.CreateToolTipCtrl();tt.CreateWindow(parent,0) I don't even find the above error string in the pywin32 sources. Only "Internal error - existing object has type..." in win32assoc.cpp What error is this "existing object is not of same type as requested new object"? Most probably it has to do with (win32tooltip.cpp): return ui_assoc_object::make( PyCToolTipCtrl::type, pTTC ); Many of such ::make's in the win32ui sources have a "->GetGoodRet()" on the line. Some have not. What is the criteria? Is such ->GetGoodRet() maybe necessary in that win32tooltip.cpp location? Can a misbehaviour on such ::make's also cause crashes? (I have occasional mem. access crash reports also; mainly on dual core's) -robert ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1475467&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-04-19 23:50:06
|
Bugs item #1472941, was opened at 2006-04-19 22:32 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1472941&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 Submitted By: Ludvig Strigeus (strigeus) Assigned to: Nobody/Anonymous (nobody) Summary: Build 208 - MAPI COM property doesn't work Initial Comment: I'm trying to change the subject of an email with the MAPI com interface to Outlook: from win32com.client import Dispatch s = Dispatch("Mapi.Session") s.Logon("Outlook") for folder in s.Inbox.Folders: if folder.Name == 'Test': for msg in folder.Messages: print "Changing subject of %s" % msg.Subject msg.Subject = 'Blabla' print "New subject = %s" % msg.Subject msg.Update() But the code does not work. The subject is not changed. It seems like msg.Subject = 'Blabla' has no effect. The same code logic works with Matlab or Visual Basic. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2006-04-20 09:50 Message: Logged In: YES user_id=14198 I'm afraid I don't have the time right now to look into this, but Python and MAPI have been working together well, by many different people for many years. Nothing jumps out at me from the code though... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1472941&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-04-19 12:34:08
|
Bugs item #1472941, was opened at 2006-04-19 14:32 Message generated for change (Settings changed) made by strigeus You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1472941&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 Submitted By: Ludvig Strigeus (strigeus) Assigned to: Nobody/Anonymous (nobody) >Summary: Build 208 - MAPI COM property doesn't work Initial Comment: I'm trying to change the subject of an email with the MAPI com interface to Outlook: from win32com.client import Dispatch s = Dispatch("Mapi.Session") s.Logon("Outlook") for folder in s.Inbox.Folders: if folder.Name == 'Test': for msg in folder.Messages: print "Changing subject of %s" % msg.Subject msg.Subject = 'Blabla' print "New subject = %s" % msg.Subject msg.Update() But the code does not work. The subject is not changed. It seems like msg.Subject = 'Blabla' has no effect. The same code logic works with Matlab or Visual Basic. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1472941&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-04-19 12:33:28
|
Bugs item #1472941, was opened at 2006-04-19 14:32 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=1472941&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 Submitted By: Ludvig Strigeus (strigeus) Assigned to: Nobody/Anonymous (nobody) Summary: Build 208 - MAPI COM function Update doesn't have any effect Initial Comment: I'm trying to change the subject of an email with the MAPI com interface to Outlook: from win32com.client import Dispatch s = Dispatch("Mapi.Session") s.Logon("Outlook") for folder in s.Inbox.Folders: if folder.Name == 'Test': for msg in folder.Messages: print "Changing subject of %s" % msg.Subject msg.Subject = 'Blabla' print "New subject = %s" % msg.Subject msg.Update() But the code does not work. The subject is not changed. It seems like msg.Subject = 'Blabla' has no effect. The same code logic works with Matlab or Visual Basic. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1472941&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-04-18 07:19:26
|
Bugs item #1471918, was opened at 2006-04-18 05:31 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1471918&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: Closed >Resolution: Duplicate Priority: 5 Submitted By: Vail (newts) Assigned to: Nobody/Anonymous (nobody) Summary: COM Makepy for Excel Fails Initial Comment: Here is the output window with 2 attempts for two different excel interface versions (below). The files seem to be in the right places and I haven't taken it much further than that. My system is XP/SP2 with Excel 97 SR2. Thanks, jv PythonWin 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32. Portions Copyright 1994-2004 Mark Hammond (mha...@sk...) - see 'Help/About PythonWin' for further copyright information. >>> Generating to C:\Python24\lib\site-packages\win32com\gen_py\00020813-0000-0000-C000-000000000046x0x1x2.py Building definitions from type library... Generating... Importing module Failed to execute command: from win32com.client import makepy;makepy.main() Traceback (most recent call last): File "C:\Python24\Lib\site-packages\pythonwin\pywin\framework\toolmenu.py", line 103, in HandleToolCommand exec "%s\n" % pyCmd File "<string>", line 1, in ? File "C:\Python24\Lib\site-packages\win32com\client\makepy.py", line 339, in main GenerateFromTypeLibSpec(arg, f, verboseLevel = verboseLevel, bForDemand = bForDemand, bBuildHidden = hiddenSpec) File "C:\Python24\Lib\site-packages\win32com\client\makepy.py", line 250, in GenerateFromTypeLibSpec gencache.AddModuleToCache(info.clsid, info.lcid, info.major, info.minor) File "C:\Python24\Lib\site-packages\win32com\client\gencache.py", line 550, in AddModuleToCache mod = _GetModule(fname) File "C:\Python24\Lib\site-packages\win32com\client\gencache.py", line 629, in _GetModule mod = __import__(mod_name) File "C:\Python24\lib\site-packages\win32com\gen_py\00020813-0000-0000-C000-000000000046x0x1x2.py", line 1393 coclass_clsid = None ^ SyntaxError: invalid syntax Generating to C:\Python24\lib\site-packages\win32com\gen_py\00020813-0000-0000-C000-000000000046x9x1x0.py Building definitions from type library... Generating... Importing module Failed to execute command: from win32com.client import makepy;makepy.main() Traceback (most recent call last): File "C:\Python24\Lib\site-packages\pythonwin\pywin\framework\toolmenu.py", line 103, in HandleToolCommand exec "%s\n" % pyCmd File "<string>", line 1, in ? File "C:\Python24\Lib\site-packages\win32com\client\makepy.py", line 339, in main GenerateFromTypeLibSpec(arg, f, verboseLevel = verboseLevel, bForDemand = bForDemand, bBuildHidden = hiddenSpec) File "C:\Python24\Lib\site-packages\win32com\client\makepy.py", line 250, in GenerateFromTypeLibSpec gencache.AddModuleToCache(info.clsid, info.lcid, info.major, info.minor) File "C:\Python24\Lib\site-packages\win32com\client\gencache.py", line 550, in AddModuleToCache mod = _GetModule(fname) File "C:\Python24\Lib\site-packages\win32com\client\gencache.py", line 629, in _GetModule mod = __import__(mod_name) File "C:\Python24\lib\site-packages\win32com\gen_py\00020813-0000-0000-C000-000000000046x9x1x0.py", line 1672 def VarP(self): return self._ApplyTypes_(16578, 1, (12, 0), (), 'VarP', None,) ^ SyntaxError: invalid syntax ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2006-04-18 17:19 Message: Logged In: YES user_id=14198 Please upgrade to python 2.4.2 or later, then delete your win32com\gen_py directory and it should be resolved (it is a bug in Python 2.4.1) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1471918&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-04-17 19:31:10
|
Bugs item #1471918, was opened at 2006-04-17 15:31 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=1471918&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 Submitted By: Vail (newts) Assigned to: Nobody/Anonymous (nobody) Summary: COM Makepy for Excel Fails Initial Comment: Here is the output window with 2 attempts for two different excel interface versions (below). The files seem to be in the right places and I haven't taken it much further than that. My system is XP/SP2 with Excel 97 SR2. Thanks, jv PythonWin 2.4.1 (#65, Mar 30 2005, 09:13:57) [MSC v.1310 32 bit (Intel)] on win32. Portions Copyright 1994-2004 Mark Hammond (mha...@sk...) - see 'Help/About PythonWin' for further copyright information. >>> Generating to C:\Python24\lib\site-packages\win32com\gen_py\00020813-0000-0000-C000-000000000046x0x1x2.py Building definitions from type library... Generating... Importing module Failed to execute command: from win32com.client import makepy;makepy.main() Traceback (most recent call last): File "C:\Python24\Lib\site-packages\pythonwin\pywin\framework\toolmenu.py", line 103, in HandleToolCommand exec "%s\n" % pyCmd File "<string>", line 1, in ? File "C:\Python24\Lib\site-packages\win32com\client\makepy.py", line 339, in main GenerateFromTypeLibSpec(arg, f, verboseLevel = verboseLevel, bForDemand = bForDemand, bBuildHidden = hiddenSpec) File "C:\Python24\Lib\site-packages\win32com\client\makepy.py", line 250, in GenerateFromTypeLibSpec gencache.AddModuleToCache(info.clsid, info.lcid, info.major, info.minor) File "C:\Python24\Lib\site-packages\win32com\client\gencache.py", line 550, in AddModuleToCache mod = _GetModule(fname) File "C:\Python24\Lib\site-packages\win32com\client\gencache.py", line 629, in _GetModule mod = __import__(mod_name) File "C:\Python24\lib\site-packages\win32com\gen_py\00020813-0000-0000-C000-000000000046x0x1x2.py", line 1393 coclass_clsid = None ^ SyntaxError: invalid syntax Generating to C:\Python24\lib\site-packages\win32com\gen_py\00020813-0000-0000-C000-000000000046x9x1x0.py Building definitions from type library... Generating... Importing module Failed to execute command: from win32com.client import makepy;makepy.main() Traceback (most recent call last): File "C:\Python24\Lib\site-packages\pythonwin\pywin\framework\toolmenu.py", line 103, in HandleToolCommand exec "%s\n" % pyCmd File "<string>", line 1, in ? File "C:\Python24\Lib\site-packages\win32com\client\makepy.py", line 339, in main GenerateFromTypeLibSpec(arg, f, verboseLevel = verboseLevel, bForDemand = bForDemand, bBuildHidden = hiddenSpec) File "C:\Python24\Lib\site-packages\win32com\client\makepy.py", line 250, in GenerateFromTypeLibSpec gencache.AddModuleToCache(info.clsid, info.lcid, info.major, info.minor) File "C:\Python24\Lib\site-packages\win32com\client\gencache.py", line 550, in AddModuleToCache mod = _GetModule(fname) File "C:\Python24\Lib\site-packages\win32com\client\gencache.py", line 629, in _GetModule mod = __import__(mod_name) File "C:\Python24\lib\site-packages\win32com\gen_py\00020813-0000-0000-C000-000000000046x9x1x0.py", line 1672 def VarP(self): return self._ApplyTypes_(16578, 1, (12, 0), (), 'VarP', None,) ^ SyntaxError: invalid syntax ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1471918&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-04-06 16:41:07
|
Bugs item #1465566, was opened at 2006-04-06 09:26 Message generated for change (Comment added) made by pmoore You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1465566&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 Submitted By: Paul Moore (pmoore) Assigned to: Mark Hammond (mhammond) Summary: Build 208 - binary installer doesn't work with Python 2.5a1 Initial Comment: The installer for build 208 - pywin32-208.win32-py2.5.exe - doesn't work with the newly released Python 2.5a1 binaries. (Windows XP Pro, SP2). The installer fails immediately with "Running the pre-installation script failed". I've checked this on 2 machines. There are no other Python packages installed, beyond the base Python 2.5a1. ---------------------------------------------------------------------- >Comment By: Paul Moore (pmoore) Date: 2006-04-06 17:41 Message: Logged In: YES user_id=113328 Looks like preinstall script support might be broken in bdist_wininst. I've tried a simple example, and the resulting installer fails in the same way. I've raised a bug for Python (http://www.python.org/sf/1465834). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1465566&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-04-06 08:26:37
|
Bugs item #1465566, was opened at 2006-04-06 09:26 Message generated for change (Settings changed) made by pmoore You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1465566&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 Submitted By: Paul Moore (pmoore) >Assigned to: Mark Hammond (mhammond) Summary: Build 208 - binary installer doesn't work with Python 2.5a1 Initial Comment: The installer for build 208 - pywin32-208.win32-py2.5.exe - doesn't work with the newly released Python 2.5a1 binaries. (Windows XP Pro, SP2). The installer fails immediately with "Running the pre-installation script failed". I've checked this on 2 machines. There are no other Python packages installed, beyond the base Python 2.5a1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1465566&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-04-06 08:26:16
|
Bugs item #1465566, was opened at 2006-04-06 09:26 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=1465566&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 Submitted By: Paul Moore (pmoore) Assigned to: Nobody/Anonymous (nobody) Summary: Build 208 - binary installer doesn't work with Python 2.5a1 Initial Comment: The installer for build 208 - pywin32-208.win32-py2.5.exe - doesn't work with the newly released Python 2.5a1 binaries. (Windows XP Pro, SP2). The installer fails immediately with "Running the pre-installation script failed". I've checked this on 2 machines. There are no other Python packages installed, beyond the base Python 2.5a1. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1465566&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-04-04 11:33:26
|
Patches item #1464113, was opened at 2006-04-04 11:13 Message generated for change (Settings changed) made by derobins You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1464113&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: 1 Submitted By: Dana Robinson (derobins) Assigned to: Nobody/Anonymous (nobody) Summary: Usage changes and directory creation Initial Comment: This patch updates the usage string so that it corresponds to the getopt processing. I also clarified and slightly reformatted the text so that it's easier to read. For example, all lines are less than 80 characters and the arguments are explained in the order that they appear. I also added a few lines of code that will create missing directories in the output file's path. These can easily be removed if such behavior is not desired. D ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1464113&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-04-04 11:33:07
|
Patches item #1464113, was opened at 2006-04-04 11:13 Message generated for change (Settings changed) made by derobins You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1464113&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: 2 Submitted By: Dana Robinson (derobins) Assigned to: Nobody/Anonymous (nobody) Summary: Usage changes and directory creation Initial Comment: This patch updates the usage string so that it corresponds to the getopt processing. I also clarified and slightly reformatted the text so that it's easier to read. For example, all lines are less than 80 characters and the arguments are explained in the order that they appear. I also added a few lines of code that will create missing directories in the output file's path. These can easily be removed if such behavior is not desired. D ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1464113&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-04-04 11:13:11
|
Patches item #1464113, was opened at 2006-04-04 11:13 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1464113&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 Submitted By: Dana Robinson (derobins) Assigned to: Nobody/Anonymous (nobody) Summary: Usage changes and directory creation Initial Comment: This patch updates the usage string so that it corresponds to the getopt processing. I also clarified and slightly reformatted the text so that it's easier to read. For example, all lines are less than 80 characters and the arguments are explained in the order that they appear. I also added a few lines of code that will create missing directories in the output file's path. These can easily be removed if such behavior is not desired. D ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1464113&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-04-01 22:53:30
|
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 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: 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: 2006-04-02 08:53 Message: Logged In: YES user_id=14198 This was a bug in Python, and works fine in Python 2.4.2 and later. ---------------------------------------------------------------------- Comment By: James Kew (jkew) Date: 2005-04-07 05:26 Message: Logged In: YES user_id=598066 I think I might be experiencing the same bug: on ActiveState Python 2.4.1, and iTunes 4.7.1, running import win32com.client win32com.client.gencache.EnsureDispatch ("iTunes.Application") throws a syntax error: "C:\DOCUME~1\James\LOCALS~1\Temp\gen_py\2.4 \9E93C96F-CF0D-43F6-8BA8-B807A3370712x0x1x2 \IiTunes.py", line 232 "CurrentVisual": (1610743851, 2, (9, 0), (), "CurrentVisual", '{340F3315-ED72-4C09-9ACF- 21EB4BDF9931}'), "EQEnabled": (1610743853, 2, (11, 0), (), "EQEnabled", None), ^ SyntaxError: invalid syntax ---------------------------------------------------------------------- Comment By: janez jere (janezj) Date: 2005-04-01 18:32 Message: Logged In: YES user_id=182593 it must be a python bug, because a single space = ' ' fixes the code and python proceeds. Example: if error is reported on "ret = ..." line bellow, just add one single space at the end of the line before error: in this case at the end def clone....):--> <-- # Result is of type IXMLDOMNode def cloneNode(self, deep=defaultNamedNotOptArg): ret = self._oleobj_.InvokeTypes(19, LCID, 1, (9, 0), ((11, 1),),deep ) In all cases an extra space before error is good workaround ---------------------------------------------------------------------- Comment By: Boris Nazaroff (bor-ka) Date: 2005-03-31 22:16 Message: Logged In: YES user_id=1242633 2.4.1 is out and still the same story :-( ---------------------------------------------------------------------- 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...> - 2006-03-24 11:18:04
|
Patches item #1457673, was opened at 2006-03-24 11:18 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1457673&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 Submitted By: Tony Roberts (tonyroberts) Assigned to: Nobody/Anonymous (nobody) Summary: dispids can go wrong when using typelibs Initial Comment: Hi, In DesignatedWrapPolicy._wrap_, if a typelib is available it's used to populate _name_to_dispid_ the other dispid maps. However, the case of the methods/properties in the type library don't always match the python code as the midl compiler may produce a typelib with differently cased names to the original idl file. When iterating over _public_attrs_, if a dispid already exists for name.lower(), it should be used instead of a new dispid - otherwise there's the posibility of having two dispids for what should be the same attribute. When iterating over _public_methods_, it's not always enough to check that name.lower() already exists in _name_to_dispid_ as the corresponding name in _dispid_to_func_ may have the wrong case. cheers, Tony. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1457673&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-03-24 11:07:40
|
Bugs item #1442426, was opened at 2006-03-03 12:07 Message generated for change (Comment added) made by lukeplant You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1442426&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 Submitted By: Luke Plant (lukeplant) Assigned to: Nobody/Anonymous (nobody) Summary: Crash on startup with Windows 2003 and AMD X2 dual core Initial Comment: I have installed Python 2.4 and Pythonwin build 207 on a brand new Windows Server 2003 system. When I run pythonwin, it crashes after drawing the mainwindow and part way through drawing the interactive window. I get the following error message: > The instruction at "0x00affa6c" referenced memory at > "0x00affa6c". The memory could not be "written" I have installed exactly the same version of pythonwin on an almost identical system, but with different hardware, so I suspect it is something to do with the processor on this one. The processor is an "AMD 64 X2 Dual Core 4400+". Visual Studio attempts to debug it, but of course there isn't any source code. In the disassembly listing, the following line is highlighted: 00AFFA6C pop eax I can give more than this if required, but I don't know whether it would be useful (or how much to include). Thanks. ---------------------------------------------------------------------- >Comment By: Luke Plant (lukeplant) Date: 2006-03-24 11:07 Message: Logged In: YES user_id=621233 Yep, build 208 seems to work fine - with the DEP protection turned on it doesn't crash at the point it did before, and has not crashed at all on me yet. If a similar thing crops up I'll let you know and re-open the bug. Thanks a lot! ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2006-03-22 10:03 Message: Logged In: YES user_id=14198 Can you please try build 208 - it has a new 'dde' module, which was apparently the cause of a DEP problem. I appreciate that "more and more dual core CPUs are on the end user market", but I don't! Anything you can do to remedy the situation would be appreciated (and I could guarantee any relevant bugs would be immediately fixed) <wink> ---------------------------------------------------------------------- Comment By: kxroberto (kxroberto) Date: 2006-03-08 15:38 Message: Logged In: YES user_id=972995 A serious issue. As more and more dual core CPUs are on the end user market I got reports of similar crashes in win32ui apps: See the dual core bugs posted as bug# 1441884 (by mismatch?) in the Python project. http://sourceforge.net/tracker/index.php?func=detail&aid=1441884&group_id=5470&atid=105470 The dual core problems seems more to be in Pythonwin, as there are all those indications to MFC dll's. This problem is different from the crash-bugs 1048355 (unresolved in the normal build since long time; but users with the patch also have the dual core problem) and 1445659 (new bug in 206 & 207). Robert ---------------------------------------------------------------------- Comment By: Luke Plant (lukeplant) Date: 2006-03-03 14:19 Message: Logged In: YES user_id=621233 I've discovered that it is related to 'DEP' (Data Execution Prevention) which is available with some AMD processors. You can disable this on a per-process basis in Windows - go to Control Panel -> System -> 'Advanced' tab -> Performance 'Settings' -> 'DEP' tab It's still a bug in pythonwin though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1442426&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-03-22 22:28:56
|
Patches item #1446700, was opened at 2006-03-10 06:32 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1446700&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 Submitted By: kxroberto (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: 4 (+1) Patches to speed up edit-help-debug-run-cycle Initial Comment: Patches: 4 (+1) Patches to speed up the edit-help-debug-run-cycle significantly ================================ pywin.framework.interact : * Ctrl-RETURN in interactive window executes the command directly in debugger ( very nice to speedup edit-run-cycle 2x; don't know how to live without; very helpful also to enter quickly into source code of imported modules ) pywin.scintilla.view : * Ctrl-E : "Execute region" : runs code snippet (auto-unindented), which is marked currently in editor, in interactive namespace ( very nice to speedup edit-run-cycle 2x; don't know how to live without; ) ( similar to Python mode in XEmacs: "Execute Region" ) ( executes currently in __main__.__dict__ ; to be consistent during debugging the current interp-namespace should be used; found no easy link to get this namespace ) * Ctrl-Y : context senitive Python help for smartly guessed words/funcs around cursor in "c:/python23/Doc/Python23.chm" ( is hardwired as of now :-( . should take the CHM-location out of registry ) ( should be put to Ctrl-F1 and maybe to a framework module; Don't know how to bind keys like Ctrl-F1 ) * Ctrl-Q : context senitive PythonWin help for smartly guessed words/funcs around cursor parallel in hf= "c:/python23/lib/site-packages/pywin32.chm" and hf=r"C:\Programme\Microsoft Visual Studio\MSDN98\98VSa\1033\msdnvs6a.col" (hard wiring still to be virtualized; ) ( win32help.HtmlHelp doesn't raise if file non-existing, but returns 0; not checked/no error action as of now ) pywin.mfc.docview , pywin.framework.intpyapp : * repairs the fatal call from pywin.mfc.docview.DocTemplate._SetupSharedMenu_ into a framework module ( that problem crashed py2exe'd apps without Pythonwin framework, but which use the DocTemplate ) ================= apply: cd C:/python23/lib/site-packages/pythonwin/pywin patch -b -p 4 <pywrk.diff created with: diff -ur . /iBase/python/pywin-framework-patched-files >pywrk.diff ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2006-03-23 09:28 Message: Logged In: YES user_id=14198 OK, thanks. I'll try and get back to this - I obviously have a lot on my plate though, and getting this ready to check in isn't going to be an insignificant amount of time. ---------------------------------------------------------------------- Comment By: kxroberto (kxroberto) Date: 2006-03-22 22:59 Message: Logged In: YES user_id=972995 I'll probably not enhance the patch myself. The main remaining difficulties are to get the right key bindings (Ctrl-F1/Ctrl-Shitf-F1 ..) work and for Ctrl-ENTER-debug to get the virtual interactive globals from somewhere. I didn't grasp the required concepts in reasonable time. ======== Ctrl-Shift-Enter : also acceptable - but pressing [Ctrl]+[Enter] for '\'+'n' - thats a habit or :-) ========= help files from registry: found its just 2 lines: import regutil hf = regutil.GetRegisteredHelpFile("Main Python Documentation") import regutil hf = regutil.GetRegisteredHelpFile("Pythonwin Reference") ========== launching 2 helpfiles Pywin & MSDN in a row: thats maybe not a regular behavior, just practical for me: I often need to lookup the windows constants and other basics in parallel, as they are not in the pywin CHM. For a streamlined pythonwin: Maybe just drop the call to MSDN helpfile - or later a more expensive solution: menu item "Menu/help/Context sensitive help .." to add/see user definable key+helpfile pairs. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2006-03-22 21:00 Message: Logged In: YES user_id=14198 Interesting - this has potential! :) * I'm not that keen on adopting Ctrl+Enter - that is what I personally use for 'insert \n into code' - how about Ctrl+Shift+Enter * OnKeyCtrlE - print statements should be removed, but a nice concept! * hf="c:/python23/Doc/Python23.chm" etc - as you say, "hard wiring still to be virtualized" - please do! :) The block: + else: + hf=r"C:\Programme\Microsoft Visual Studio\MSDN98\98VSa\1033\msdnvs6a.col" + win32help.HtmlHelp(0, hf, win32help.HH_DISPLAY_INDEX, word) + hf= "c:/python23/lib/site-packages/pywin32.chm" + win32help.HtmlHelp(0, hf, win32help.HH_DISPLAY_INDEX, word) doesn't look right as it calls HtmlHelp twice. It would be great to work out how to do that help properly! * re "repairs the fatal call from pywin.mfc.docview.DocTemplate._SetupSharedMenu_" - can you be more specific about the problem you see? I'm not that happy with that patch - a patch that just changes all refernces to _SetupSharedMenu, rather than "injecting" it, would be preferred. I'm happy to see the interest, and hope you can update your patch! Just the .diff file is fine (.patch is my preference, but either is fine :) - no need to .zip, nor to attach the modified files. Cheers, Mark ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1446700&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-03-22 12:00:01
|
Patches item #1446700, was opened at 2006-03-09 20:32 Message generated for change (Comment added) made by kxroberto You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1446700&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 Submitted By: kxroberto (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: 4 (+1) Patches to speed up edit-help-debug-run-cycle Initial Comment: Patches: 4 (+1) Patches to speed up the edit-help-debug-run-cycle significantly ================================ pywin.framework.interact : * Ctrl-RETURN in interactive window executes the command directly in debugger ( very nice to speedup edit-run-cycle 2x; don't know how to live without; very helpful also to enter quickly into source code of imported modules ) pywin.scintilla.view : * Ctrl-E : "Execute region" : runs code snippet (auto-unindented), which is marked currently in editor, in interactive namespace ( very nice to speedup edit-run-cycle 2x; don't know how to live without; ) ( similar to Python mode in XEmacs: "Execute Region" ) ( executes currently in __main__.__dict__ ; to be consistent during debugging the current interp-namespace should be used; found no easy link to get this namespace ) * Ctrl-Y : context senitive Python help for smartly guessed words/funcs around cursor in "c:/python23/Doc/Python23.chm" ( is hardwired as of now :-( . should take the CHM-location out of registry ) ( should be put to Ctrl-F1 and maybe to a framework module; Don't know how to bind keys like Ctrl-F1 ) * Ctrl-Q : context senitive PythonWin help for smartly guessed words/funcs around cursor parallel in hf= "c:/python23/lib/site-packages/pywin32.chm" and hf=r"C:\Programme\Microsoft Visual Studio\MSDN98\98VSa\1033\msdnvs6a.col" (hard wiring still to be virtualized; ) ( win32help.HtmlHelp doesn't raise if file non-existing, but returns 0; not checked/no error action as of now ) pywin.mfc.docview , pywin.framework.intpyapp : * repairs the fatal call from pywin.mfc.docview.DocTemplate._SetupSharedMenu_ into a framework module ( that problem crashed py2exe'd apps without Pythonwin framework, but which use the DocTemplate ) ================= apply: cd C:/python23/lib/site-packages/pythonwin/pywin patch -b -p 4 <pywrk.diff created with: diff -ur . /iBase/python/pywin-framework-patched-files >pywrk.diff ---------------------------------------------------------------------- >Comment By: kxroberto (kxroberto) Date: 2006-03-22 12:59 Message: Logged In: YES user_id=972995 I'll probably not enhance the patch myself. The main remaining difficulties are to get the right key bindings (Ctrl-F1/Ctrl-Shitf-F1 ..) work and for Ctrl-ENTER-debug to get the virtual interactive globals from somewhere. I didn't grasp the required concepts in reasonable time. ======== Ctrl-Shift-Enter : also acceptable - but pressing [Ctrl]+[Enter] for '\'+'n' - thats a habit or :-) ========= help files from registry: found its just 2 lines: import regutil hf = regutil.GetRegisteredHelpFile("Main Python Documentation") import regutil hf = regutil.GetRegisteredHelpFile("Pythonwin Reference") ========== launching 2 helpfiles Pywin & MSDN in a row: thats maybe not a regular behavior, just practical for me: I often need to lookup the windows constants and other basics in parallel, as they are not in the pywin CHM. For a streamlined pythonwin: Maybe just drop the call to MSDN helpfile - or later a more expensive solution: menu item "Menu/help/Context sensitive help .." to add/see user definable key+helpfile pairs. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2006-03-22 11:00 Message: Logged In: YES user_id=14198 Interesting - this has potential! :) * I'm not that keen on adopting Ctrl+Enter - that is what I personally use for 'insert \n into code' - how about Ctrl+Shift+Enter * OnKeyCtrlE - print statements should be removed, but a nice concept! * hf="c:/python23/Doc/Python23.chm" etc - as you say, "hard wiring still to be virtualized" - please do! :) The block: + else: + hf=r"C:\Programme\Microsoft Visual Studio\MSDN98\98VSa\1033\msdnvs6a.col" + win32help.HtmlHelp(0, hf, win32help.HH_DISPLAY_INDEX, word) + hf= "c:/python23/lib/site-packages/pywin32.chm" + win32help.HtmlHelp(0, hf, win32help.HH_DISPLAY_INDEX, word) doesn't look right as it calls HtmlHelp twice. It would be great to work out how to do that help properly! * re "repairs the fatal call from pywin.mfc.docview.DocTemplate._SetupSharedMenu_" - can you be more specific about the problem you see? I'm not that happy with that patch - a patch that just changes all refernces to _SetupSharedMenu, rather than "injecting" it, would be preferred. I'm happy to see the interest, and hope you can update your patch! Just the .diff file is fine (.patch is my preference, but either is fine :) - no need to .zip, nor to attach the modified files. Cheers, Mark ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1446700&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-03-22 11:24:14
|
Bugs item #1445659, was opened at 2006-03-08 15:05 Message generated for change (Comment added) made by kxroberto You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1445659&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 Submitted By: kxroberto (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: build 207 & 206 for py2.3 : pythonwin.exe startup crash Initial Comment: build 207 (and 206) for Python 2.3(.5) on WinXP Home (SR1) / normal single core CPU : Pythonwin.exe doesn't start: Crash: Instruction 0x1e037435 points to memory 0x00000028... MSVC++ Runtime Library : Runtime Error! debugger shows stack: PYTHON23! 1e037435() MFC42! 73d3c10b() MFC42! 73d42167() build 205 for 2.3 is the last build which starts ok. I lived so far with build 203 - also ok. reproducable. ------- Additional Notes: When I start 207/2.3's framework with attached startupframework.py (or start_pythonwin.pyw) instead of pythonwin.exe it works! (?) When I try to use 205/2.3's 5 files pythonwin.exe,win32ui.pyd,win32uiole.pyd,dde.pyd,scintilla.dll in otherwise 207/2.3, the crash is the same. guess its something in the plain python code or win32 modules. build 207 pythonwin.exe for py2.4 works on my machine, the described bug seems specific for py2.3 (/MFC42?). starting build 207/2.4 with start_pythonwin.pyw is (of course) also ok. But when I close the framework, one of that old win32ui close crash bug winks: memory violation at (see also PS below): 011402a0() MFC71! 7c176020() MFC71! 7c16e0b0() MFC71! 7c16e14f() MFC71! 7c16e1b8() MFC71! 7c16e1f6() USER32! 77d18654() USER32! 77d18723() USER32! 77d19153() USER32! 77d19196() NTDLL! 77f65da3() WIN32UI! 1e2c8691() PYTHON24! 1e1ae378() Robert -------- PS: Serious old bug 1048355 (causes crashes) in win32ui is still not addressed in 207. T::OnNotify crashes when e.g. WM_NCDESTROY pulls off the underlying window out of MFC during Python_OnNotify. To get my apps stable i have to patch OnNotify & OnCmdMsg in win32uiExt.h (only 2 lines added) as shown below (suspect CPythonRichEditView::OnNotify and CPythonPropertySheet::OnNotify and CPythonDocTemp<P>::OnCmdMsg and CPythonRichEditView::OnCmdMsg and CPythonPropertySheet::OnCmdMsg to require all the same patch - often when win32ui apps close, strange crashes occure... ): virtual BOOL OnCmdMsg( UINT nID, int nCode, void* pExtra, AFX_CMDHANDLERINFO*pHandlerInfo ) { // yield to Python first if (Python_OnCmdMsg (this, nID, nCode, pExtra, pHandlerInfo)) return TRUE; else { if (!IsWindow( this->m_hWnd )) return TRUE; return T::OnCmdMsg (nID, nCode, pExtra, pHandlerInfo); } } virtual BOOL OnNotify (WPARAM wParam, LPARAM lParam, LRESULT *pResult) { // yield to Python first if (Python_OnNotify (this, wParam, lParam, pResult)) return TRUE; else { if (!IsWindow( this->m_hWnd )) //if (!IsWindow( ((NMHDR*)lParam)->hwndFrom )) return TRUE; return T::OnNotify (wParam, lParam, pResult); } } ---------------------------------------------------------------------- >Comment By: kxroberto (kxroberto) Date: 2006-03-22 12:24 Message: Logged In: YES user_id=972995 208/py2.3 works (both: py2.3 startup and DestroyWindow ) ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2006-03-22 11:36 Message: Logged In: YES user_id=14198 Please let me know how build 208 works! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1445659&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-03-22 10:51:31
|
Bugs item #1444381, was opened at 2006-03-07 07:04 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1444381&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 Submitted By: Erik Andersén (erik_andersen) Assigned to: Nobody/Anonymous (nobody) Summary: lines may be mistaken for exception lines Initial Comment: PythonWin 2.4.2 (#67, Oct 30 2005, 16:11:18) [MSC v. 1310 32 bit (Intel)] on win32. Portions Copyright 1994-2004 Mark Hammond (mha...@sk...) - see 'Help/About PythonWin' for further copyright informatio >>> print 'File "<xxx>", line 1324' System will respond with "Cannot open this file" The cause is in winout.HandleSpecialLine. The input line matches the input line, so the interactive shell thinks is is a traceback line and tries to jump to the file <xxx>. Similarly, >>> s = 'File' + ' "<xxx>", line 1324' >>> s 'File "<xxx>", line 1324' >>> 1+1 gives the same error since HandleSpecialLine also tries the preceeding line. The solution is to add if line.startswith('>>>') or line. startswith('...'): return 0 near the beginning of HandleSpecialLine. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2006-03-22 21:51 Message: Logged In: YES user_id=14198 Fixed (but by changing the regex). Will be in 209 Checking in framework/winout.py; new revision: 1.13; previous revision: 1.12 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1444381&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-03-22 10:41:37
|
Bugs item #1444675, was opened at 2006-03-07 19:21 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1444675&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: win32 Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: helium (helium-sun) Assigned to: Nobody/Anonymous (nobody) Summary: Typo error in netbios.py Initial Comment: netbios.py line 169: FIND_NAME_BUFFER_ITEMS = [ (UCHAR, "length"), (UCHAR, "access_control"), (UCHAR, "frame_control"), ("6s" "destination_addr"), ^^^ ("6s", "source_addr"), ("18s", "routing_info"), ] ',' is lost ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2006-03-22 21:41 Message: Logged In: YES user_id=14198 Thanks! Will be in build 209. Checking in netbios.py; new revision: 1.4; previous revision: 1.3 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1444675&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-03-22 10:37:30
|
Bugs item #1445113, was opened at 2006-03-08 08:02 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1445113&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: win32 Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Chad Austin (aegis) Assigned to: Nobody/Anonymous (nobody) Summary: GetMenu not exported (even though SetMenu is) Initial Comment: I noticed a perhaps obvious omission today: win32gui.SetMenu is exported and works as expected, but there is no corresponding win32gui.GetMenu. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2006-03-22 21:37 Message: Logged In: YES user_id=14198 This is in build 208 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1445113&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-03-22 10:36:37
|
Bugs item #1445659, was opened at 2006-03-09 01:05 Message generated for change (Settings changed) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1445659&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: Pending Resolution: None Priority: 5 Submitted By: kxroberto (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: build 207 & 206 for py2.3 : pythonwin.exe startup crash Initial Comment: build 207 (and 206) for Python 2.3(.5) on WinXP Home (SR1) / normal single core CPU : Pythonwin.exe doesn't start: Crash: Instruction 0x1e037435 points to memory 0x00000028... MSVC++ Runtime Library : Runtime Error! debugger shows stack: PYTHON23! 1e037435() MFC42! 73d3c10b() MFC42! 73d42167() build 205 for 2.3 is the last build which starts ok. I lived so far with build 203 - also ok. reproducable. ------- Additional Notes: When I start 207/2.3's framework with attached startupframework.py (or start_pythonwin.pyw) instead of pythonwin.exe it works! (?) When I try to use 205/2.3's 5 files pythonwin.exe,win32ui.pyd,win32uiole.pyd,dde.pyd,scintilla.dll in otherwise 207/2.3, the crash is the same. guess its something in the plain python code or win32 modules. build 207 pythonwin.exe for py2.4 works on my machine, the described bug seems specific for py2.3 (/MFC42?). starting build 207/2.4 with start_pythonwin.pyw is (of course) also ok. But when I close the framework, one of that old win32ui close crash bug winks: memory violation at (see also PS below): 011402a0() MFC71! 7c176020() MFC71! 7c16e0b0() MFC71! 7c16e14f() MFC71! 7c16e1b8() MFC71! 7c16e1f6() USER32! 77d18654() USER32! 77d18723() USER32! 77d19153() USER32! 77d19196() NTDLL! 77f65da3() WIN32UI! 1e2c8691() PYTHON24! 1e1ae378() Robert -------- PS: Serious old bug 1048355 (causes crashes) in win32ui is still not addressed in 207. T::OnNotify crashes when e.g. WM_NCDESTROY pulls off the underlying window out of MFC during Python_OnNotify. To get my apps stable i have to patch OnNotify & OnCmdMsg in win32uiExt.h (only 2 lines added) as shown below (suspect CPythonRichEditView::OnNotify and CPythonPropertySheet::OnNotify and CPythonDocTemp<P>::OnCmdMsg and CPythonRichEditView::OnCmdMsg and CPythonPropertySheet::OnCmdMsg to require all the same patch - often when win32ui apps close, strange crashes occure... ): virtual BOOL OnCmdMsg( UINT nID, int nCode, void* pExtra, AFX_CMDHANDLERINFO*pHandlerInfo ) { // yield to Python first if (Python_OnCmdMsg (this, nID, nCode, pExtra, pHandlerInfo)) return TRUE; else { if (!IsWindow( this->m_hWnd )) return TRUE; return T::OnCmdMsg (nID, nCode, pExtra, pHandlerInfo); } } virtual BOOL OnNotify (WPARAM wParam, LPARAM lParam, LRESULT *pResult) { // yield to Python first if (Python_OnNotify (this, wParam, lParam, pResult)) return TRUE; else { if (!IsWindow( this->m_hWnd )) //if (!IsWindow( ((NMHDR*)lParam)->hwndFrom )) return TRUE; return T::OnNotify (wParam, lParam, pResult); } } ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2006-03-22 21:36 Message: Logged In: YES user_id=14198 Please let me know how build 208 works! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1445659&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-03-22 10:03:28
|
Bugs item #1442426, was opened at 2006-03-03 23:07 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1442426&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 Submitted By: Luke Plant (lukeplant) Assigned to: Nobody/Anonymous (nobody) Summary: Crash on startup with Windows 2003 and AMD X2 dual core Initial Comment: I have installed Python 2.4 and Pythonwin build 207 on a brand new Windows Server 2003 system. When I run pythonwin, it crashes after drawing the mainwindow and part way through drawing the interactive window. I get the following error message: > The instruction at "0x00affa6c" referenced memory at > "0x00affa6c". The memory could not be "written" I have installed exactly the same version of pythonwin on an almost identical system, but with different hardware, so I suspect it is something to do with the processor on this one. The processor is an "AMD 64 X2 Dual Core 4400+". Visual Studio attempts to debug it, but of course there isn't any source code. In the disassembly listing, the following line is highlighted: 00AFFA6C pop eax I can give more than this if required, but I don't know whether it would be useful (or how much to include). Thanks. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2006-03-22 21:03 Message: Logged In: YES user_id=14198 Can you please try build 208 - it has a new 'dde' module, which was apparently the cause of a DEP problem. I appreciate that "more and more dual core CPUs are on the end user market", but I don't! Anything you can do to remedy the situation would be appreciated (and I could guarantee any relevant bugs would be immediately fixed) <wink> ---------------------------------------------------------------------- Comment By: kxroberto (kxroberto) Date: 2006-03-09 02:38 Message: Logged In: YES user_id=972995 A serious issue. As more and more dual core CPUs are on the end user market I got reports of similar crashes in win32ui apps: See the dual core bugs posted as bug# 1441884 (by mismatch?) in the Python project. http://sourceforge.net/tracker/index.php?func=detail&aid=1441884&group_id=5470&atid=105470 The dual core problems seems more to be in Pythonwin, as there are all those indications to MFC dll's. This problem is different from the crash-bugs 1048355 (unresolved in the normal build since long time; but users with the patch also have the dual core problem) and 1445659 (new bug in 206 & 207). Robert ---------------------------------------------------------------------- Comment By: Luke Plant (lukeplant) Date: 2006-03-04 01:19 Message: Logged In: YES user_id=621233 I've discovered that it is related to 'DEP' (Data Execution Prevention) which is available with some AMD processors. You can disable this on a per-process basis in Windows - go to Control Panel -> System -> 'Advanced' tab -> Performance 'Settings' -> 'DEP' tab It's still a bug in pythonwin though. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1442426&group_id=78018 |
2 messages has been excluded from this view by a project administrator.
