pywin32-bugs Mailing List for Python for Windows Extensions (Page 59)
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...> - 2008-02-25 07:49:14
|
Bugs item #938577, was opened at 2004-04-20 08:43 Message generated for change (Comment added) made by rupole You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=938577&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pythonwin Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Denis (abcdenis) Assigned to: Nobody/Anonymous (nobody) Summary: cant change text background to [X] default Initial Comment: Pythonwin win32all build 163 comes with ActiveState Python 2.3.2 When I go to View/Options/Format/String and change background to (for sample) light green, its looks fine. When I tired seeing light green, I go to options and set backround to default, but this not work! My experience results: to restore backround I must delete registry record with address "HKEY_CURRENT_USER\Software\Python 2.3\Python for Win32\Format\String background" So, I think, there must be another algorithm to save background: 1. remove "<element> background" registry record 2. if background not default, then create "<element> background" registry record. Regards, Denis ---------------------------------------------------------------------- >Comment By: Roger Upole (rupole) Date: 2008-02-25 02:49 Message: Logged In: YES user_id=771074 Originator: NO This has been fixed in formatter.py rev 1.13. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=938577&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2008-02-25 05:35:18
|
Bugs item #946996, was opened at 2004-05-03 09:47 Message generated for change (Comment added) made by rupole You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=946996&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pythonwin Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: bob gailer (ramrom) Assigned to: Nobody/Anonymous (nobody) Summary: Options Editor Spinners upside down. Initial Comment: The up and down arrows on the spinners in the Editor tab of the Options dialog do the reverse of what's expected. The other spinners work as expected. ---------------------------------------------------------------------- >Comment By: Roger Upole (rupole) Date: 2008-02-25 00:35 Message: Logged In: YES user_id=771074 Originator: NO Fixed in configui.py r 1.8 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=946996&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2008-02-25 03:37:55
|
Bugs item #1027533, was opened at 2004-09-13 16:34 Message generated for change (Comment added) made by rupole You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1027533&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pythonwin Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: bob gailer (ramrom) Assigned to: Nobody/Anonymous (nobody) Summary: Pythonwin hangs Initial Comment: I have just lost hours of work because I failed to remember to save some modules I was editing. When I ran my program in the debugger I noticed that I had failed to save, so I attempted to halt the porgram. Pythonwin hung and had to be force quit. As a result I lost all my editing. I have reported (at least a year ago) certain cases where pythonwin has either hung (can't stop pump error or endless writing of messages to the interactive window). Could someone take a look at whatever causes these hangups? I woudl if I could but I don't know my way around well enough. ---------------------------------------------------------------------- >Comment By: Roger Upole (rupole) Date: 2008-02-24 22:38 Message: Logged In: YES user_id=771074 Originator: NO This seems to have been the same issue as #1037629, should be fixed now. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1027533&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2008-02-25 03:32:42
|
Bugs item #1037629, was opened at 2004-09-30 05:11 Message generated for change (Comment added) made by rupole You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1037629&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: 9 Private: No Submitted By: kxroberto (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: Framework exception on file save after confirmation Initial Comment: b201 - See the traceback below: after that the file is saved once, but when editing more in the editor window, the document-changed-flag is always OFF (toolbar-icon-disksave grey), thus no more saving is possible/or requested !! I regularly loose code by this! >>> Traceback (most recent call last): File "C:\PYTHON23\Lib\site-packages\pythonwin\pywin\framework\editor\document.py", line 83, in OnSaveDocument self._DocumentStateChanged() File "C:\PYTHON23\Lib\site-packages\pythonwin\pywin\framework\editor\document.py", line 175, in _DocumentStateChanged pywin.debugger.currentDebugger.UpdateDocumentLineStates(self) File "C:\PYTHON23\Lib\site-packages\pythonwin\pywin\debugger\debugger.py", line 880, in UpdateDocumentLineStates doc.MarkerDeleteAll( MARKER_BREAKPOINT ) File "C:\PYTHON23\Lib\site-packages\pythonwin\pywin\scintilla\document.py", line 117, in MarkerDeleteAll self.GetEditorView().SCIMarkerDeleteAll(marker) AttributeError: SCIMarkerDeleteAll win32ui: OnSaveDocument() virtual handler (<bound method SyntEditDocument.OnSaveDocument of <pywin.framework.editor.color.coloreditor.SyntEditDocument instance at 0x01333878>>) raised an exception ---------------------------------------------------------------------- >Comment By: Roger Upole (rupole) Date: 2008-02-24 22:32 Message: Logged In: YES user_id=771074 Originator: NO This should be fixed in frame.py rev 1.6. ---------------------------------------------------------------------- Comment By: kxroberto (kxroberto) Date: 2004-10-13 10:25 Message: Logged In: YES user_id=972995 don|t know if b203 solves it meanwhile. Yet I reproduce the problem most easyly when simply editing a file, CtrlF4 to try close, YES => exception and the changed flag is no more tracked. >>> >>> Traceback (most recent call last): File "C:\PYTHON23\Lib\site-packages\pythonwin\pywin\framework\editor\document.py", line 83, in OnSaveDocument self._DocumentStateChanged() File "C:\PYTHON23\Lib\site-packages\pythonwin\pywin\framework\editor\document.py", line 175, in _DocumentStateChanged pywin.debugger.currentDebugger.UpdateDocumentLineStates(self) File "C:\PYTHON23\Lib\site-packages\pythonwin\pywin\debugger\debugger.py", line 880, in UpdateDocumentLineStates doc.MarkerDeleteAll( MARKER_BREAKPOINT ) File "C:\PYTHON23\Lib\site-packages\pythonwin\pywin\scintilla\document.py", line 117, in MarkerDeleteAll self.GetEditorView().SCIMarkerDeleteAll(marker) AttributeError: SCIMarkerDeleteAll win32ui: OnSaveDocument() virtual handler (<bound method SyntEditDocument.OnSaveDocument of <pywin.framework.editor.color.coloreditor.SyntEditDocument instance at 0x01134A80>>) raised an exception >>> ---------------------------------------------------------------------- Comment By: kxroberto (kxroberto) Date: 2004-10-08 04:56 Message: Logged In: YES user_id=972995 I found how to reproduce (& getting lots of exception going on): - open clean pywin - open a .py file / no more editing (dont set save-request flag) - set breakpoint somewhere (on top) - F5-run into breakpoint - when debugger stops: in that line editi something (e.g. enter SPACEs) - then immediately Ctrl-F4 to try close-window - on Save-Confirm: Cancel - ==> exceptions like above going on - Shift - F5 to stop debugging - Save file once - Edit more in the file - ===> no more change of save-request-flag (grey save toolbar button) ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2004-10-08 01:26 Message: Logged In: YES user_id=14198 That is very strange, and I certainly can't reproduce it. That method does exist (in 'control.py' in that same directory) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1037629&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2008-02-22 04:31:53
|
Bugs item #1083545, was opened at 2004-12-11 13:20 Message generated for change (Comment added) made by rupole You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1083545&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: Duplicate Priority: 5 Private: No Submitted By: gpascenso (gpascenso) Assigned to: Nobody/Anonymous (nobody) Summary: Can't load Python for pre-install script Initial Comment: I have the same problem mr_moose reported in Request ID 1066510: Can't load Python for pre-install script. Everuthing went the same. However, I looked into my C:\Windows\System32 folder to check how many pythonxx.dll I had, as suggested by Mark Hammomd in his "Installation Troubleshooting" page at http://starship.python.net/crew/mhammond/win32/InstallationProblems.html, and to my surprise I found only python23.dll and pythoncom23.dll. This is weird, since I completely uninstalled Python 2.3.4 before installing Python 2.4 ---------------------------------------------------------------------- >Comment By: Roger Upole (rupole) Date: 2008-02-21 23:31 Message: Logged In: YES user_id=771074 Originator: NO This is same issue as bug 1066510. ---------------------------------------------------------------------- Comment By: gpascenso (gpascenso) Date: 2004-12-19 06:01 Message: Logged In: YES user_id=1176324 Thank you for your kind reply. However, I solved the problem through a different path. I installed ActiveState Python 2.4 and it worked immediately. Since I use Python only on Win32, it seemed a good alternative. Bye, --gpascenso ---------------------------------------------------------------------- Comment By: Hypotaxis (hypotaxis) Date: 2004-12-16 17:00 Message: Logged In: YES user_id=900292 Yup, same problem and I found the same solution worked. ---------------------------------------------------------------------- Comment By: Andy Elvey (mr_moose) Date: 2004-12-15 21:34 Message: Logged In: YES user_id=1116790 Hi gpascenso! Good news on this - I followed the tips posted by spjenni (on my bug report that you mention), and success! PythonWin 2.4 is now up and running .... :-) One small glitch - you may get a message saying that the dll mfc71.dll can't be found. You can get that dll at the following URL - http://www.dll-files.com/dllindex/dll-files.shtml?mfc71 So, do the following - 1 - Uninstall Python 2.4, then do a fresh install, making sure you install it for all users, not just yourself. 2 - Get the mfc71.dll file , and copy it into windows/system. 3 - Install the Python for Windows extensions. 4 - Fire up PythonWin. It should now work :-) Bye for now - mr_moose ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1083545&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2008-02-22 04:12:40
|
Bugs item #1173025, was opened at 2005-03-30 00:42 Message generated for change (Comment added) made by rupole You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1173025&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: installation Group: None >Status: Closed >Resolution: Duplicate Priority: 8 Private: No Submitted By: tms (tms43) Assigned to: Nobody/Anonymous (nobody) Summary: Can't load Python for pre-install script Initial Comment: I see others have had this problem. Has it been resolved? I need these files for a class I am taking. Thank you for your attention. ---------------------------------------------------------------------- >Comment By: Roger Upole (rupole) Date: 2008-02-21 23:12 Message: Logged In: YES user_id=771074 Originator: NO This is same issue as bug 1066510. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1173025&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2008-02-22 04:07:00
|
Bugs item #1048325, was opened at 2004-10-16 09:23 Message generated for change (Comment added) made by rupole You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1048325&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pythonwin Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Erik Anders(erik_andersen) Assigned to: Nobody/Anonymous (nobody) Summary: Firing event '<<paren-open>>' failed Initial Comment: Try typing a closing parentesis after file.__init__. __class__ PythonWin 2.4a3 (#56, Sep 2 2004, 20:50:21) [MSC v.1310 32 bit (Intel)] on win32. Portions Copyright 1994-2004 Mark Hammond (mha...@sk...) - see 'Help/About PythonWin' for further copyright information. >>> file.__init__.__class__Firing event '<<paren- open>>' failed. Traceback (most recent call last): File "C:\Python24\Lib\site- packages\pythonwin\pywin\scintilla\bindings.py", line 141, in fire rc = apply(binding.handler, args) File "C:\Python24\Lib\site- packages\pythonwin\pywin\idle\CallTips.py", line 51, in paren_open_event arg_text = get_arg_text(self. get_object_at_cursor()) File "C:\Python24\Lib\site- packages\pythonwin\pywin\idle\CallTips.py", line 147, in get_arg_text pos = string.find(ob.__doc__, "\n") File "C:\Python24\Lib\string.py", line 293, in find return s.find(*args) AttributeError: 'getset_descriptor' object has no attribute 'find' ) By the way, isn't it strange that we get event '<<paren-open>>' when we type a closing parentesis? ---------------------------------------------------------------------- >Comment By: Roger Upole (rupole) Date: 2008-02-21 23:07 Message: Logged In: YES user_id=771074 Originator: NO Fixed in CallTips.py r 1.2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1048325&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2008-02-22 01:58:08
|
Bugs item #1094803, was opened at 2005-01-03 01:13 Message generated for change (Settings changed) made by rupole You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1094803&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: installation Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Kim Davies (kjd) Assigned to: Nobody/Anonymous (nobody) Summary: postinstall failure: access denied to registry writes Initial Comment: Installing pythonwin build 203 for Python 2.4 under Windows XP, I receive the following. The installation is nonfunctioning if I try and run it (i.e. pythonw.exe) at this point. The user is an administrator, I can't think of any reason why the program would be administratively denied access to the registry. This is what the install script gave: Copied pythoncom24.dll to F:\WINDOWS\System32 \pythoncom24.dll Copied pywintypes24.dll to F:\WINDOWS\System32 \pywintypes24.dll Registered: Python.Interpreter Registered: Python.Dictionary Registered: Python Traceback (most recent call last): File "F:\Python24\Scripts\pywin32_postinstall.py", line 358, in ? install() File "F:\Python24\Scripts\pywin32_postinstall.py", line 231, in install SetPyKeyVal("Help", None, None) File "F:\Python24\Scripts\pywin32_postinstall.py", line 103, in SetPyKeyVal _winreg.SetValueEx(my_key, value_name, 0, _winreg.REG_SZ, value) WindowsError: [Errno 5] Access is denied *** run_installscript: internal error 0xFFFFFFFF *** ---------------------------------------------------------------------- >Comment By: Roger Upole (rupole) Date: 2008-02-21 20:58 Message: Logged In: YES user_id=771074 Originator: NO Since this was due to misconfiguration of a specific machine, closing as Won't Fix. ---------------------------------------------------------------------- Comment By: Andy Philpotts (sirxyzzy) Date: 2005-10-11 14:10 Message: Logged In: YES user_id=1203071 The workround given above evades the symtom, but the help files do not get registered (bad) I can see why this happens, checking with regedit I see that permission is indeed denied to the adminstrator (at least on my machine) This seems to be specific to Python24, and is possibly the result of a bug in some version of the Python24 install script. If I check the permissions in my registy for Python24, SYSTEM has full control, but administrator has only READ (my keys for Python23 had full control for administrator). The failure ought to be caught and a meaningful message displayed, or possibly the post install script has to run as SYSTEM, although that sounds wrong As a workround, I changed the permissions on the registry key at the Python24 level (apply to all subkeys) and ran the script again, all fixed up now. ---------------------------------------------------------------------- Comment By: Kim Davies (kjd) Date: 2005-01-03 01:26 Message: Logged In: YES user_id=168657 I note there is a comment in pywin32_postinstall.py that probably explains it, and I just put an exception handler around it, and it installed okay (presumably missing some help functionality..) New code fragment: # Register the .chm help file. chm_file = os.path.join(lib_dir, "PyWin32.chm") if os.path.isfile(chm_file): # This isn't recursive, so if 'Help' doesn't exist, we croak try: SetPyKeyVal("Help", None, None) SetPyKeyVal("Help\\Pythonwin Reference", None, chm_file) except: pass else: print "NOTE: PyWin32.chm can not be located, so has not " \ "been registered" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1094803&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2008-02-22 01:28:15
|
Bugs item #1002587, was opened at 2004-08-03 08:02 Message generated for change (Comment added) made by rupole You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1002587&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pythonwin Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Indanur (indanur) Assigned to: Nobody/Anonymous (nobody) Summary: Editor window background colour ignores system setting Initial Comment: The background colour of the PythonWin Editor is statically set to white. I suggest to use the colour selected in the Windows systems settings, as usually done by programs, or allow configuration in the Options dialog. Reason: I prefer to select light gray as text background, as this improves biocompatibility with my eyes (Anyone who has not yet tried this: Do! 16 hours screen work? No problem). Thx, regards. ---------------------------------------------------------------------- >Comment By: Roger Upole (rupole) Date: 2008-02-21 20:28 Message: Logged In: YES user_id=771074 Originator: NO formatter.py r 1.12 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1002587&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2008-02-21 03:51:42
|
Bugs item #794728, was opened at 2003-08-25 09:43 Message generated for change (Comment added) made by rupole You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=794728&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: Out of Date Priority: 5 Private: No Submitted By: Chema Cort(chemacortes) Assigned to: Nobody/Anonymous (nobody) Summary: Installation fails with win95 Initial Comment: I use a win95 box within an old pentium. Installing win32all 155 or 157 into python 2.3 fails to load win32ui.pyd (FindDuplicates.py). After some deinstall/clean/reinstall cycles, I tried to install the versi53 with sucessful. I don't have any Visual C++ to try, but it seems as a compiler's optimization incompatible with my box. ---------------------------------------------------------------------- >Comment By: Roger Upole (rupole) Date: 2008-02-20 22:51 Message: Logged In: YES user_id=771074 Originator: NO Win95 no longer supported ---------------------------------------------------------------------- Comment By: Chema Cort(chemacortes) Date: 2004-05-12 06:53 Message: Logged In: YES user_id=78289 I saw the same error when I'm installing PythonCard. I suspect there is a problem with the wise installer at win95. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=794728&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2008-02-21 00:14:12
|
Bugs item #1160437, was opened at 2005-03-10 02:27 Message generated for change (Comment added) made by rupole You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1160437&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: Fixed Priority: 5 Private: No 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: Roger Upole (rupole) Date: 2008-02-20 19:14 Message: Logged In: YES user_id=771074 Originator: NO This should be fixed with odbc.cpp rev 1.20. ---------------------------------------------------------------------- Comment By: 江文 (jiangwen365) Date: 2005-03-23 02:42 Message: Logged In: YES user_id=1147025 Mhanmond, Sorry, at last I'm not able to find a server for you, as I'm no longer in university and my PC is only using telephone line to connect to the internet. But if your PC has enough room for installing a PostgreSQL win32 server(I mean if you are willing to:-)), I would be glad to give you the URL for download, it's about 17.5M, and comes with both ODBC Driver & GUI data browser: http://wwwmaster.postgresql.org/download/mirrors-ftp?file=win32%2Fpostgresql-8.0.1.zip Below is the script which leads to crash: (But sometimes it crashes a lot at first and somehow becomes pretty stable later, I can't explain why, so I'm just hoping you can luckily and successfully crash your python when running tests:)) import dbi,odbc while True: print 'connecting Postgres' b=odbc.odbc("HScode") # another DSN print 'getting postgres cursor' bc=b.cursor() bc.execute('select * from latest_parts limit 1') #do some operations #print bc.fetchall() bc.close() b.close() It would be great if you can find and fix the problem, after all, odbc is such a important module for any programming languages. Thanks, Henry ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-03-16 18: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 03: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 03: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...> - 2008-02-20 22:53:08
|
Bugs item #1476208, was opened at 2006-04-25 10:58 Message generated for change (Comment added) made by rupole 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: Fixed Priority: 5 Private: No 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: Roger Upole (rupole) Date: 2008-02-20 17:53 Message: Logged In: YES user_id=771074 Originator: NO This should be fixed now. The ToolbarDebugging keys won't be created at all now, and will be ignored if they already exist. Not sure if it's worth the trouble to change the setup scripts to delete any existing keys. ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2008-02-19 17:07 Message: Logged In: YES user_id=771074 Originator: NO I ran into this recently myself. It appears the calls to LoadBarState and SaveBarState using "ToolbarDebugging" are completely superfluous, since the state of the Debug toolbar is already saved in the "ToolbarDefault" section. Has anyone seen an excessive number of ToolbarDefault keys being created ? ---------------------------------------------------------------------- Comment By: kxroberto (kxroberto) Date: 2006-04-26 03:39 Message: Logged In: YES user_id=972995 that massive accumulation happened definitely during using 208 yesterday - within one or some sessions within hours. The debugger was a few times in strange states. See below. Maybe the difference is also, that they accumulate in "Python for Win32" and not in "Pythonwin Debugger"? Yet, I used the debugger (also) with pywin.debugger.pm()/.run() from the Interactive pane. Yes, I may have tried to reenter the debugger while debugging. There are usually "alread pumping" warings and not allowed and so - as no sub-debugging is possible like in pdb. The debugger also enters sometime into states, where it freezes somehow on all attempts to run or step something and just says "not pumping" - also while the debugger is obviously not anymore active and I want to just run things. Then I have to restart Pythonwin. Thus there may be a mode confusion problem behind that bug or Pywin doesn't know correctly if its debugging or not ... As the debugger is a complex thing, especially when windowing apps are debugged, the debugger freeze / confusion is acceptable. Yet the protection against that massive accumulation of registry should maybe work on a lower level. Reopened it - though the bug obviously happens only upon intense use of the debugger. It took long to find out why Pywin startup _and_ exits _and_ enters/leaves the debugger very slow. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2006-04-25 18: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...> - 2008-02-19 22:32:22
|
Bugs item #1092592, was opened at 2004-12-29 04:09 Message generated for change (Settings changed) made by rupole You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1092592&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pythonwin Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: marc412 (marc412) Assigned to: Nobody/Anonymous (nobody) Summary: win32ui: LoadFrame failed Initial Comment: I installed python-2.4.msi and pywin32-203.win32- py2.4.exe on a windows XP system. At the beginning, everything worked fine, until I started to use the debugger. Since then, pythonwin seems to be broken. I can't call it any more from the context menu, when selecting a python file in the windows explorer. Calling a file from the context menu, I am getting the error messages, attached below. A reinstallation had no effect. No effect as well as when I used pywin32- 202.win32-py2.4.exe, i.e. build no 202 instead of 203. >>> Traceback (most recent call last): File "C:\Python24\Lib\site- packages\pythonwin\pywin\mfc\docview.py", line 91, in CreateNewFrame wnd.LoadFrame(self.GetResourceID(), -1, None, context) # triggers OnCreateClient... win32ui: LoadFrame failed win32ui: CreateNewFrame() virtual handler (<bound method SyntEditTemplate.CreateNewFrame of <pywin.framework.editor.color.coloreditor.SyntEditTempla te instance at 0x01153530>>) raised an exception TypeError: PyCTemplate::CreateNewFrame must return a PyCFrameWnd object. ---------------------------------------------------------------------- >Comment By: Roger Upole (rupole) Date: 2008-02-19 17:32 Message: Logged In: YES user_id=771074 Originator: NO This should be fixed in the next build. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1092592&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2008-02-19 22:06:57
|
Bugs item #1476208, was opened at 2006-04-25 10:58 Message generated for change (Comment added) made by rupole 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 Private: No 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: Roger Upole (rupole) Date: 2008-02-19 17:07 Message: Logged In: YES user_id=771074 Originator: NO I ran into this recently myself. It appears the calls to LoadBarState and SaveBarState using "ToolbarDebugging" are completely superfluous, since the state of the Debug toolbar is already saved in the "ToolbarDefault" section. Has anyone seen an excessive number of ToolbarDefault keys being created ? ---------------------------------------------------------------------- Comment By: kxroberto (kxroberto) Date: 2006-04-26 03:39 Message: Logged In: YES user_id=972995 that massive accumulation happened definitely during using 208 yesterday - within one or some sessions within hours. The debugger was a few times in strange states. See below. Maybe the difference is also, that they accumulate in "Python for Win32" and not in "Pythonwin Debugger"? Yet, I used the debugger (also) with pywin.debugger.pm()/.run() from the Interactive pane. Yes, I may have tried to reenter the debugger while debugging. There are usually "alread pumping" warings and not allowed and so - as no sub-debugging is possible like in pdb. The debugger also enters sometime into states, where it freezes somehow on all attempts to run or step something and just says "not pumping" - also while the debugger is obviously not anymore active and I want to just run things. Then I have to restart Pythonwin. Thus there may be a mode confusion problem behind that bug or Pywin doesn't know correctly if its debugging or not ... As the debugger is a complex thing, especially when windowing apps are debugged, the debugger freeze / confusion is acceptable. Yet the protection against that massive accumulation of registry should maybe work on a lower level. Reopened it - though the bug obviously happens only upon intense use of the debugger. It took long to find out why Pywin startup _and_ exits _and_ enters/leaves the debugger very slow. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2006-04-25 18: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...> - 2008-02-19 08:00:56
|
Bugs item #1896670, was opened at 2008-02-19 17:16 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1896670&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alexandr Zamaraev (shura_zam) Assigned to: Nobody/Anonymous (nobody) Summary: Universal gateway do not work with COM Records Initial Comment: I try use win32com for realize interface: [code lang='IDL'] ... typedef [...] struct tagMatrix3d { Point3d RowX; Point3d RowY; Point3d RowZ; } Matrix3d; ... interface ILocateCommandEvents : IDispatch { ... HRESULT LocateFilter([in] _Element* Element, [in, out] Point3d* Point, [in, out] VARIANT_BOOL* Accepted); ... }; ... [/code] I'd made it in such way: [code lang='python'] class LocateCommandEvents(object): _com_interfaces_ = [IID_ILocateCommandEvents] _typelib_guid_ = '{CF9F97BF-39F2-4B8E-835C-8BE9E99DAF5B}' _typelib_version_ = 8, 0 _typelib_lcid_ = 0 _public_methods_ = [] _dispid_to_func_ = {..., 0x60020002: 'LocateFilter', ...} def LocateFilter(self, Element, Point, Accepted): print 'LocateFilter' print Element, Point, Accepted return S_OK, None, True ... [/code] Now errors occur in calls to LocateCommandEvents.LocateFilter function from MicroStation: [code] LocateFilter <win32com.gen_py.Bentley MicroStation DGN 8.0 Object Library._Element instance at 0x12737352> 2223916 True pythoncom error: Failed to call the universal dispatcher Traceback (most recent call last): File "C:\Lang\Python\25\lib\site-packages\win32com\universal.py", line 193, in dispatch WriteFromOutTuple(retVal, meth._gw_out_args, argPtr) <type 'exceptions.TypeError'>: The VARIANT type is unknown (0x24). pythoncom error: Unexpected gateway error Traceback (most recent call last): File "C:\Lang\Python\25\lib\site-packages\win32com\universal.py", line 193, in dispatch WriteFromOutTuple(retVal, meth._gw_out_args, argPtr) <type 'exceptions.TypeError'>: The VARIANT type is unknown (0x24). [/code] ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2008-02-19 19:01 Message: Logged In: YES user_id=14198 Originator: NO win32com\src\univgw_dataconv.cpp needs to learn about the VT_RECORD type. PyRecord.cpp contains a function: BOOL PyObject_AsVARIANTRecordInfo(PyObject *ob, VARIANT *pv) which oleargs.cpp uses to convert records in the IDispatch case. This function fills the 'pv' element of a variant - you may like to refactor this into 2 functions - one to give the raw pointer and one to set the pointer in the variant. On the other hand, it may be that 'pyrec->pdata' is all you need to pass - I'm not sure how records are passed to vtable based functions. Let me know if that makes sense... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1896670&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2008-02-19 06:16:23
|
Bugs item #1896670, was opened at 2008-02-19 12:16 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=1896670&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alexandr Zamaraev (shura_zam) Assigned to: Nobody/Anonymous (nobody) Summary: Universal gateway do not work with COM Records Initial Comment: I try use win32com for realize interface: [code lang='IDL'] ... typedef [...] struct tagMatrix3d { Point3d RowX; Point3d RowY; Point3d RowZ; } Matrix3d; ... interface ILocateCommandEvents : IDispatch { ... HRESULT LocateFilter([in] _Element* Element, [in, out] Point3d* Point, [in, out] VARIANT_BOOL* Accepted); ... }; ... [/code] I'd made it in such way: [code lang='python'] class LocateCommandEvents(object): _com_interfaces_ = [IID_ILocateCommandEvents] _typelib_guid_ = '{CF9F97BF-39F2-4B8E-835C-8BE9E99DAF5B}' _typelib_version_ = 8, 0 _typelib_lcid_ = 0 _public_methods_ = [] _dispid_to_func_ = {..., 0x60020002: 'LocateFilter', ...} def LocateFilter(self, Element, Point, Accepted): print 'LocateFilter' print Element, Point, Accepted return S_OK, None, True ... [/code] Now errors occur in calls to LocateCommandEvents.LocateFilter function from MicroStation: [code] LocateFilter <win32com.gen_py.Bentley MicroStation DGN 8.0 Object Library._Element instance at 0x12737352> 2223916 True pythoncom error: Failed to call the universal dispatcher Traceback (most recent call last): File "C:\Lang\Python\25\lib\site-packages\win32com\universal.py", line 193, in dispatch WriteFromOutTuple(retVal, meth._gw_out_args, argPtr) <type 'exceptions.TypeError'>: The VARIANT type is unknown (0x24). pythoncom error: Unexpected gateway error Traceback (most recent call last): File "C:\Lang\Python\25\lib\site-packages\win32com\universal.py", line 193, in dispatch WriteFromOutTuple(retVal, meth._gw_out_args, argPtr) <type 'exceptions.TypeError'>: The VARIANT type is unknown (0x24). [/code] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1896670&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2008-02-19 02:50:36
|
Bugs item #745699, was opened at 2003-05-29 14:27 Message generated for change (Settings changed) made by rupole You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=745699&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: Invalid Priority: 5 Private: No Submitted By: Philip Reed (philipreed) Assigned to: Nobody/Anonymous (nobody) Summary: Error handling: not playing nice with Tkinter? (W98) Initial Comment: When PythonWin is executing a TKInter script and something goes wrong, things apparently get left in queue for the next (correct) execution. This causes weirdness in the GUI interaction eventually leading PythonWin to crash. Not 100% sure it's PyWin and not TkInter's problem, but I started with the more likely suspect IMO. TO REPRODUCE: 1. start PythonWin 2. New python script 3. Paste in Example 3.1 from <http://www.pythonware.com/library/tkinter/introducti on/hello-again.htm> (a TkInter "Hello World" example). 4. Add some line that's guaranteed to error, like "import dummy", BEFORE the call to root.mainloop () 5. Save the file somewhere not in the Python path, e.g. under a subdir of My Documents . 6. Run with an <F5> OBSERVE: normal exception message in interactive window. 6. Fix the "problem" by deleting the bogus import line. 7. Run again with <F5> ACTUAL RESULT: Now you get two TKInter dialog boxes! Pressing Quit on the 2nd one doesn't really quit, and pressing a few more buttons (e.g. Quit on the first, Hello on the second, Quit on the second -- I think that was my order) will cause an error: Runtime Error! Program <path to pythonwin> PYTHONWIN.EXE abnormal program termination EXPECTED RESULT: PythonWin should be robust enough to handle this. I think. :-) If possible, it should clear out the queue of windows so the first dialog never gets displayed. Certainly they shouldn't both display at the same time. ---------------------------------------------------------------------- >Comment By: Roger Upole (rupole) Date: 2008-02-18 21:50 Message: Logged In: YES user_id=771074 Originator: NO Running 2 GUI frameworks at the same time will almost always cause problems of this kind. There's really no resolution except to not run Tkintker from within pythonwin. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=745699&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2008-02-19 02:41:12
|
Bugs item #1361822, was opened at 2005-11-19 19:36 Message generated for change (Settings changed) made by rupole You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1361822&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: Out of Date Priority: 5 Private: No Submitted By: Colin J. Williams (cjwhrh) Assigned to: Nobody/Anonymous (nobody) Summary: crash when or after importing scipy - Build 205 Initial Comment: This has happened a number of times but I haven't been able to pin it down to more than the fact it occurs when attempting to debug a program using scipy. If the code is executed first, then one can step through it. In this case a crash often occurs eventually. The crash report is the instruction "0x7c168f1d" could not read "0x0000001c" Colin W. ---------------------------------------------------------------------- >Comment By: Roger Upole (rupole) Date: 2008-02-18 21:41 Message: Logged In: YES user_id=771074 Originator: NO It seems the newer versions of scipy have a different package structure. I get this with scipy 0.6.0: ImportError: No module named base.umath. Please reopen if you can still reproduce this with updated version of scipy. ---------------------------------------------------------------------- Comment By: kxroberto (kxroberto) Date: 2006-11-18 06:55 Message: Logged In: YES user_id=972995 Originator: NO sounds more like a memory leak problem of scipy itself. But see a small probabilty that patch/solution for #1590399 solves it (in binary build >=211). ---------------------------------------------------------------------- Comment By: Colin J. Williams (cjwhrh) Date: 2006-01-11 20:09 Message: Logged In: YES user_id=285587 Mark, Attached is the script ugh1.py If I Run, the results are as expected. If I Step into, stepover (the print command) Step into the import command and continue stepping into, we crash on the umath reference. I've had similar problems with Boa-Contructor and PyScripter. I hope that this helps. Best wishes, Colin W. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2006-01-10 00:07 Message: Logged In: YES user_id=14198 Can you please provide instructions on how I can reproduce it? Cheers. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1361822&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2008-02-19 01:50:08
|
Bugs item #1219726, was opened at 2005-06-13 09:19 Message generated for change (Settings changed) made by rupole You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1219726&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: Works For Me Priority: 5 Private: No Submitted By: wpostma (wpostma) Assigned to: Nobody/Anonymous (nobody) Summary: PythonWin run-script opens file-open-dialogs in a tight loop Initial Comment: On my system, python2.4+win32all build 204, as well as on the previous build build203 of win32all, pythonwin is unable to run any script and the Run Script dialog seems severely borked. When I hit Ctrl+R it opens the Run Script dialog, and then it is like something has clicked the Browse button. The file-open dialog opens. I can not cancel this dialog, or move it, for every time I move the current file-open dialog, or cancel it, orclick okay, another one opens. I can get dozens of File Open dialogs open at once. Once I am stuck here the only option is to kill PythonWin from the task manager. I don't know how to debug this situation, but if anyone can tell me how to further investigate this, I'll look into the best I can. In scriptutils.py, I made the changes marked by asterisks below: class DlgRunScript(dialog.Dialog): ..... def OnBrowse(self, id, cmd): ** if self.browsing: ** return 0 ** self.browsing = 1 openFlags = win32con.OFN_OVERWRITEPROMPT|win32con.OFN_FILEMUSTEXIST dlg = win32ui.CreateFileDialog(1,None,None,openFlags, "Python Scripts (*.py)|*.py||", self) dlg.SetOFNTitle("Run Script") if dlg.DoModal()!=win32con.IDOK: return 0 self['script'] = dlg.GetPathName() self.UpdateData(0) ** self.browsing = 0 return 0 This was intended to prevent any endless showing of the dialog in a loop, which makes the problem less nasty but doesn't fix the problem. I have no idea how to really fix it. Also getting rid of the hook command: self.HookCommand(self.OnBrowse, win32ui.IDC_BUTTON2) Which would disable the browse button completely also fixes the problem. My system is Windows XP Service Pack 2, with 2 gb ram. ---------------------------------------------------------------------- >Comment By: Roger Upole (rupole) Date: 2008-02-18 20:50 Message: Logged In: YES user_id=771074 Originator: NO I can't reproduce this either. Please reopen if you still see this problem elsewhere. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-06-27 06:36 Message: Logged In: YES user_id=14198 I'm afraid I can't repro this and have never had anything similar reported. Can you try on another machine? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1219726&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2008-02-19 01:39:13
|
Bugs item #1520060, was opened at 2006-07-10 11:21 Message generated for change (Comment added) made by rupole You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1520060&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pythonwin Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Mark E (markenglish) Assigned to: Nobody/Anonymous (nobody) Summary: .py file "IndentationError" corrupts appearance Initial Comment: Opening a .py file like the one attached causes a long stack trace to appear in the Interactive Window (appended at base of this description), and a number of strange characters to appear in the script window (particularly breakpoint characters on every line). The file must have triple quotes at the top, some kind of code construct like a class or a file with a triple- quoted doc string who's second line is indented. For example: ---Start--- """ """ def foo(): """This line is fine This line makes PythonWin unhappy. """ pass ---End--- Removing the triple quotes from the top of the file makes the problem vanish. Removing the second line from the function doc-string also makes the problem vanish. Tried on Windows 2000 installation built from source, and Windows XP SP2 installation installed from ActiveState. ---Error Log--- >>> Traceback (most recent call last): File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\framework\editor\color\colored itor.py", line 51, in OnInitialUpdate SyntEditViewParent.OnInitialUpdate(self) File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\scintilla\view.py", line 210, in OnInitialUpdate self.OnWinIniChange(None) File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\scintilla\view.py", line 223, in OnWinIniChange self.DoConfigChange() File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\framework\editor\color\colored itor.py", line 162, in DoConfigChange ext.set_indentation_params(1) File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\idle\AutoIndent.py", line 140, in set_indentation_params i = self.guess_indent() File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\idle\AutoIndent.py", line 473, in guess_indent opener, indented = IndentSearcher(self.text, self.tabwidth).run() File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\idle\AutoIndent.py", line 546, in run _tokenize.tokenize(self.readline, self.tokeneater) File "C:\Program Files\Python242\Lib\tokenize.py", line 153, in tokenize tokenize_loop(readline, tokeneater) File "C:\Program Files\Python242\Lib\tokenize.py", line 159, in tokenize_loop for token_info in generate_tokens(readline): File "C:\Program Files\Python242\Lib\tokenize.py", line 229, in generate_tokens raise IndentationError( IndentationError: unindent does not match any outer indentation level for line: """ win32ui: OnInitialUpdate() virtual handler (<bound method SyntEditView.OnInitialUpdate of <pywin.framework.editor.color.coloreditor.SyntEditView instance at 0x010F4DA0>>) raised an exception Traceback (most recent call last): File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\framework\editor\color\colored itor.py", line 51, in OnInitialUpdate SyntEditViewParent.OnInitialUpdate(self) File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\scintilla\view.py", line 210, in OnInitialUpdate self.OnWinIniChange(None) File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\scintilla\view.py", line 223, in OnWinIniChange self.DoConfigChange() File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\framework\editor\color\colored itor.py", line 162, in DoConfigChange ext.set_indentation_params(1) File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\idle\AutoIndent.py", line 140, in set_indentation_params i = self.guess_indent() File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\idle\AutoIndent.py", line 473, in guess_indent opener, indented = IndentSearcher(self.text, self.tabwidth).run() File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\idle\AutoIndent.py", line 546, in run _tokenize.tokenize(self.readline, self.tokeneater) File "C:\Program Files\Python242\Lib\tokenize.py", line 153, in tokenize tokenize_loop(readline, tokeneater) File "C:\Program Files\Python242\Lib\tokenize.py", line 159, in tokenize_loop for token_info in generate_tokens(readline): File "C:\Program Files\Python242\Lib\tokenize.py", line 229, in generate_tokens raise IndentationError( IndentationError: unindent does not match any outer indentation level for line: """ win32ui: OnInitialUpdate() virtual handler (<bound method SyntEditView.OnInitialUpdate of <pywin.framework.editor.color.coloreditor.SyntEditView instance at 0x010F4EB8>>) raised an exception ---------------------------------------------------------------------- >Comment By: Roger Upole (rupole) Date: 2008-02-18 20:39 Message: Logged In: YES user_id=771074 Originator: NO This no longer occurs with recent builds. Not sure at what point it was fixed, though. ---------------------------------------------------------------------- Comment By: Mark E (markenglish) Date: 2006-07-10 11:29 Message: Logged In: YES user_id=1174185 To see the problem save a file with the code, then re-open it. ---------------------------------------------------------------------- Comment By: Mark E (markenglish) Date: 2006-07-10 11:28 Message: Logged In: YES user_id=1174185 To see the problem save a file with the code, then re-open it. ---------------------------------------------------------------------- Comment By: Mark E (markenglish) Date: 2006-07-10 11:27 Message: Logged In: YES user_id=1174185 Apparently follow-up posts get to keep indentation, so here's hoping: ---Start--- """ """ def foo(): """This line is fine This line makes PythonWin unhappy. """ pass ---End--- ---------------------------------------------------------------------- Comment By: Mark E (markenglish) Date: 2006-07-10 11:23 Message: Logged In: YES user_id=1174185 Unfortunately the code loses indentation inline in the report, so use the attached indnterr.py file to see the problem ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1520060&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2008-02-19 01:25:28
|
Bugs item #1541724, was opened at 2006-08-16 22:51 Message generated for change (Settings changed) made by rupole You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1541724&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pythonwin Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Glenn-Meister (ploneglenn) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot Import File Initial Comment: Some python files run fine but when you click the Import/Reload button (or the File...Import menu), a error dialog message appears (see attachment). The text of the dialog says "Could not load the file from directory <auto import>". ---------------------------------------------------------------------- >Comment By: Roger Upole (rupole) Date: 2008-02-18 20:25 Message: Logged In: YES user_id=771074 Originator: NO You can get this if the filename isn't a valid literal for import. This will now set the status bar text to indicate the problem. (scriptutils.py rev 1.14) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1541724&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2008-02-15 18:45:13
|
Patches item #1894593, was opened at 2008-02-16 00:45 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=1894593&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alexandr Zamaraev (shura_zam) Assigned to: Nobody/Anonymous (nobody) Summary: Convert regex to re in makegwparse.py Initial Comment: In makegwparse.diff 1) Convert old regex to re. 2) Adopt to parse new midl output 3) All interface from parsed file added to AllConverters dict as interface. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1894593&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2008-02-14 19:31:28
|
Bugs item #1483482, was opened at 2006-05-07 14:31 Message generated for change (Comment added) made by rupole You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1483482&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: 8 Private: No Submitted By: kxroberto (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: losts assocs Initial Comment: build 208 PythonWin 2.3.5 (#62, Feb 8 2005, 16:23:02) [MSC v.1200 32 bit (Intel)] on win32. Get occasionally a trace in the Pythonwin interactive pane - like this one recently when pressing Ctrl-F (find tool): Traceback (most recent call last): File "C:\PYTHON23\Lib\site-packages\pythonwin\pywin\scintilla\find.py", line 169, in OnInitDialog self.butKeepDialogOpen = self.GetDlgItem(115) win32ui: Internal error - existing object has type 'PyCWinThread', but 'PyCButton' was requested. win32ui: OnInitDialog() virtual handler (<bound method FindDialog.OnInitDialog of <pywin.scintilla.find.FindDialog instance at 0x0157FA30>>) raised an exception I'm noticing this ["win32ui: Internal error - existing object has type 'PyCWinThread', but 'PyC...' was requested."] occasionally in very random situations. Also in other standalone win32ui apps. This problem may relate to #1475467 (win32ui: Internal error-existing object is not of same type?). a "->GetGoodRet()" issue or similar problem? ---------------------------------------------------------------------- >Comment By: Roger Upole (rupole) Date: 2008-02-14 14:31 Message: Logged In: YES user_id=771074 Originator: NO I've added skipLookup=TRUE to several places where I've seen this most often. However, when trying to address the underlying issue with the assocs, it seems as if PyCWinThread's destructor is not getting called. Circular references may keep it alive, but I haven't dug into it that far yet. There is also another problem with CPythonWinThread::ExitInstance. virtual int ExitInstance() { CVirtualHelper helper("ExitInstance", this); if (helper.HaveHandler() && helper.call()) { int ret; helper.retval(ret); return ret; } else return CWinThread::ExitInstance(); } If there is a python method defined, the base class ExitInstance is not called. According to this: http://msdn2.microsoft.com/en-us/library/1afc1fkh.aspx CWinThread::ExitInstance should alway be called even when it is overridden, since this is what actually deletes the class. ---------------------------------------------------------------------- Comment By: kxroberto (kxroberto) Date: 2006-11-21 06:40 Message: Logged In: YES user_id=972995 Originator: YES I'm reopening this bug. Just got this with build 210 (patch of GIL bug 1590399 already in): >>> Traceback (most recent call last): File "C:\Python23\Lib\site-packages\pythonwin\pywin\scintilla\view.py", line 430, in OnCmdEditFind find.ShowFindDialog() File "C:\Python23\Lib\site-packages\pythonwin\pywin\scintilla\find.py", line 36, in ShowFindDialog _ShowDialog(FindDialog) File "C:\Python23\Lib\site-packages\pythonwin\pywin\scintilla\find.py", line 50, in _ShowDialog curDialog = dlgClass() File "C:\Python23\Lib\site-packages\pythonwin\pywin\scintilla\find.py", line 162, in __init__ dialog.Dialog.__init__(self,self._GetDialogTemplate()) File "C:\Python23\Lib\site-packages\pythonwin\pywin\mfc\dialog.py", line 32, in __init__ dlg=win32ui.CreateDialogIndirect(id) win32ui: Internal error - existing object has type 'PyCWinThread', but 'PyCDialog' was requested. win32ui: Error in Command Message handler for command ID 57636, Code 0 Most probable its either still the unaddressed problem with CPythonWinThread::ExitInstance (destructor not cleaning up its assoc) problem as described below. Or its another lost object found randomly by ui_assoc_object::make (within win32ui.CreateDialogIndirect; as most of the ::make calls are not forcing to create objects anew but are likely to pick up on random sticky assocs to dead objects, which have not cleaned their assoc accidentally. (Thus big problems arises as consequence of "small" bug) -robert ---------------------------------------------------------------------- Comment By: kxroberto (kxroberto) Date: 2006-11-18 06:42 Message: Logged In: YES user_id=972995 Originator: YES bugs as far as concretely visible are solved now with patch of bug #1590399 The comment regarding the danger of typical ui_assoc_object::make usage "map lookups are very likely to pick up undeleted junk objects in the map" still could be interesting to avoid latent bugs in future. ---------------------------------------------------------------------- Comment By: kxroberto (kxroberto) Date: 2006-06-06 12:10 Message: Logged In: YES user_id=972995 Think, I found some of the sources for theses kind of bugs. I got many other such bugs reported. e.g.: File "app.pyo", line 2033, in WmSize\\n\', "win32ui: Internal error - existing object has type \'PyCWnd\', but \'PyCTabCtrl\' was requested.\\n"] I have these strong guesses for bugs: * CPythonWinThread::ExitInstance the MFC destroys the this pointer, but the assoc is not deleted! ==> junk items are pickup ==> bug in OP (see skipLookup problem below) * ui_propsheet_get_tab_ctrl: permanent ui_assoc_object::make is called on temporary pTab = pPS->GetTabControl() !! (MFC uses FromHandle !) PyCWnd::make should be used or something similar to make it permanent as required for a Python-Object * (for example!): PyCWinThread::create, PyCFormView::create, PyCEditView::create, ... (and in most ::create functions) ui_assoc_object::make( PyCWinThread::type, pThread ) is called with default skipLookup=FALSE even if the C object was created brandnew (with 'new' - which is in done in 95% of cases) ! ==> Those map lookups are very likely to pick up undeleted junk objects in the map ! ==> when Objects are created new, skipLookup=TRUE should be used - or FALSE the default and TRUE only for GetXXX things - or best a new ui_assoc_object::makenew should be used. Think this is very important and I attribute many other strange win32ui - Internal errors to this risky map management. * ui_assoc_object::GetGoodRet DODECREF better to be done after DOINCREF !? -robert ---------------------------------------------------------------------- Comment By: kxroberto (kxroberto) Date: 2006-05-07 14:32 Message: Logged In: YES user_id=972995 trace again (as initial posting removes whitespace): Traceback (most recent call last): File "C:\PYTHON23\Lib\site-packages\pythonwin\pywin\scintilla\find.py", line 169, in OnInitDialog self.butKeepDialogOpen = self.GetDlgItem(115) win32ui: Internal error - existing object has type 'PyCWinThread', but 'PyCButton' was requested. win32ui: OnInitDialog() virtual handler (<bound method FindDialog.OnInitDialog of <pywin.scintilla.find.FindDialog instance at 0x0157FA30>>) raised an exception ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1483482&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2008-02-13 22:18:23
|
Patches item #1892592, was opened at 2008-02-13 21:38 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1892592&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: Fixed Priority: 5 Private: No Submitted By: Alexandr Zamaraev (shura_zam) Assigned to: Nobody/Anonymous (nobody) Summary: Forget context of the Invoke call flag Initial Comment: Function DesignatedWrapPolicy._wrap_ If interface name mark DISPATCH_PROPERTYPUTREF i see exception: ValueError, "unexpected invkind: %d (%s)" % (invkind,name) If change line 494 : elif invkind in (DISPATCH_PROPERTYPUT, DISPATCH_PROPERTYPUTREF): All work ok. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2008-02-14 09:18 Message: Logged In: YES user_id=14198 Originator: NO Thanks! Checking in policy.py; new revision: 1.23; previous revision: 1.22 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1892592&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2008-02-13 10:38:51
|
Patches item #1892592, was opened at 2008-02-13 16:38 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=1892592&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alexandr Zamaraev (shura_zam) Assigned to: Nobody/Anonymous (nobody) Summary: Forget context of the Invoke call flag Initial Comment: Function DesignatedWrapPolicy._wrap_ If interface name mark DISPATCH_PROPERTYPUTREF i see exception: ValueError, "unexpected invkind: %d (%s)" % (invkind,name) If change line 494 : elif invkind in (DISPATCH_PROPERTYPUT, DISPATCH_PROPERTYPUTREF): All work ok. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1892592&group_id=78018 |
2 messages has been excluded from this view by a project administrator.
