pywin32-bugs Mailing List for Python for Windows Extensions (Page 46)
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...> - 2009-02-07 03:10:28
|
Patches item #1937527, was opened at 2008-04-08 19:32 Message generated for change (Settings changed) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1937527&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: ionel (ionel_mc) Assigned to: Nobody/Anonymous (nobody) Summary: win32file.ConnectEx patch Initial Comment: A patch for ConnectEx. called as follows: win32file.ConnectEx(sock, (host, port), overlappedobj [, bufferobj]) here's an example: import socket, win32file, pywintypes s = socket.socket() ol = pywintypes.OVERLAPPED() s.bind(('0.0.0.0', 0)) # connectex requires the socket be bound beforehand print win32file.ConnectEx(s, ("google.com", 80), ol, "GET / HTTP/1.1\r\n\r\n") print win32file.GetOverlappedResult(s.fileno(), ol, 1) ol = pywintypes.OVERLAPPED() buff = win32file.AllocateReadBuffer(20480) print win32file.WSARecv(s, buff, ol, 0) print win32file.GetOverlappedResult(s.fileno(), ol, 1) print buff I've tested this on win xp. I use getaddrinfo to process the (host, port) tuple. Please review. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2009-02-07 12:57 Message: Roger has this in his py3k branch so its now merged to the trunk - thanks for your patience. ---------------------------------------------------------------------- Comment By: ionel (ionel_mc) Date: 2008-05-09 10:36 Message: Logged In: YES user_id=1189761 Originator: YES To be completely honest I don't really know how to use the tuples returned from the socket.getaddrinfo - since they are very far from the C addrinfo struct I need to use in the ConnectEx call, also, i don't think the python function call overhead to get that addrinfo and make whatever conversions back to the struct is worth it. I would add some sort of demo but i need some suggestions (it seems I lack imagination right now). I don't cover the corner cases (like bad params) in the test_connectex. ---------------------------------------------------------------------- Comment By: ionel (ionel_mc) Date: 2008-05-09 10:25 Message: Logged In: YES user_id=1189761 Originator: YES File Added: test_connectex.py ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2008-05-05 20:33 Message: Logged In: YES user_id=14198 Originator: NO This looks pretty good. I'd probably prefer for getaddrinfo() to be called by the user of this function, and the necessary info passed in - is there a reason not to do that? Also, would you be so kind as to add something to the win32\test directory (and maybe even the win32\Demos directory :) that covers this? Thanks! ---------------------------------------------------------------------- Comment By: ionel (ionel_mc) Date: 2008-04-24 18:22 Message: Logged In: YES user_id=1189761 Originator: YES wops, forgot something File Added: win32file.i-4.patch ---------------------------------------------------------------------- Comment By: ionel (ionel_mc) Date: 2008-04-24 18:22 Message: Logged In: YES user_id=1189761 Originator: YES wops, forgot something File Added: win32file.i-4.patch ---------------------------------------------------------------------- Comment By: ionel (ionel_mc) Date: 2008-04-24 17:57 Message: Logged In: YES user_id=1189761 Originator: YES ok i've made some changes: i've moved the wsaioctl in the function body - the msdn docs didn't say if the pointer i'm getting is always the same - wsaioctl requires a wsainit before, i feel win32file is the wrong place to do that and i don't want to force users to import the socket module (for wsainit) before win32file still looking for some feedback on this one though. i've changed the buffer handling parts to use the 'buffer api' File Added: win32file.i-3.patch ---------------------------------------------------------------------- Comment By: ionel (ionel_mc) Date: 2008-04-24 17:57 Message: Logged In: YES user_id=1189761 Originator: YES ok i've made some changes: i've moved the wsaioctl in the function body - the msdn docs didn't say if the pointer i'm getting is always the same - wsaioctl requires a wsainit before, i feel win32file is the wrong place to do that and i don't want to force users to import the socket module (for wsainit) before win32file still looking for some feedback on this one though. i've changed the buffer handling parts to use the 'buffer api' File Added: win32file.i-3.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1937527&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2009-02-07 02:24:53
|
Patches item #1937527, was opened at 2008-04-08 19:32 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1937527&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: ionel (ionel_mc) Assigned to: Nobody/Anonymous (nobody) Summary: win32file.ConnectEx patch Initial Comment: A patch for ConnectEx. called as follows: win32file.ConnectEx(sock, (host, port), overlappedobj [, bufferobj]) here's an example: import socket, win32file, pywintypes s = socket.socket() ol = pywintypes.OVERLAPPED() s.bind(('0.0.0.0', 0)) # connectex requires the socket be bound beforehand print win32file.ConnectEx(s, ("google.com", 80), ol, "GET / HTTP/1.1\r\n\r\n") print win32file.GetOverlappedResult(s.fileno(), ol, 1) ol = pywintypes.OVERLAPPED() buff = win32file.AllocateReadBuffer(20480) print win32file.WSARecv(s, buff, ol, 0) print win32file.GetOverlappedResult(s.fileno(), ol, 1) print buff I've tested this on win xp. I use getaddrinfo to process the (host, port) tuple. Please review. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2009-02-07 12:58 Message: Roger has this in his py3k branch so its now merged to the trunk - thanks for your patience. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2009-02-07 12:57 Message: Roger has this in his py3k branch so its now merged to the trunk - thanks for your patience. ---------------------------------------------------------------------- Comment By: ionel (ionel_mc) Date: 2008-05-09 10:36 Message: Logged In: YES user_id=1189761 Originator: YES To be completely honest I don't really know how to use the tuples returned from the socket.getaddrinfo - since they are very far from the C addrinfo struct I need to use in the ConnectEx call, also, i don't think the python function call overhead to get that addrinfo and make whatever conversions back to the struct is worth it. I would add some sort of demo but i need some suggestions (it seems I lack imagination right now). I don't cover the corner cases (like bad params) in the test_connectex. ---------------------------------------------------------------------- Comment By: ionel (ionel_mc) Date: 2008-05-09 10:25 Message: Logged In: YES user_id=1189761 Originator: YES File Added: test_connectex.py ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2008-05-05 20:33 Message: Logged In: YES user_id=14198 Originator: NO This looks pretty good. I'd probably prefer for getaddrinfo() to be called by the user of this function, and the necessary info passed in - is there a reason not to do that? Also, would you be so kind as to add something to the win32\test directory (and maybe even the win32\Demos directory :) that covers this? Thanks! ---------------------------------------------------------------------- Comment By: ionel (ionel_mc) Date: 2008-04-24 18:22 Message: Logged In: YES user_id=1189761 Originator: YES wops, forgot something File Added: win32file.i-4.patch ---------------------------------------------------------------------- Comment By: ionel (ionel_mc) Date: 2008-04-24 18:22 Message: Logged In: YES user_id=1189761 Originator: YES wops, forgot something File Added: win32file.i-4.patch ---------------------------------------------------------------------- Comment By: ionel (ionel_mc) Date: 2008-04-24 17:57 Message: Logged In: YES user_id=1189761 Originator: YES ok i've made some changes: i've moved the wsaioctl in the function body - the msdn docs didn't say if the pointer i'm getting is always the same - wsaioctl requires a wsainit before, i feel win32file is the wrong place to do that and i don't want to force users to import the socket module (for wsainit) before win32file still looking for some feedback on this one though. i've changed the buffer handling parts to use the 'buffer api' File Added: win32file.i-3.patch ---------------------------------------------------------------------- Comment By: ionel (ionel_mc) Date: 2008-04-24 17:57 Message: Logged In: YES user_id=1189761 Originator: YES ok i've made some changes: i've moved the wsaioctl in the function body - the msdn docs didn't say if the pointer i'm getting is always the same - wsaioctl requires a wsainit before, i feel win32file is the wrong place to do that and i don't want to force users to import the socket module (for wsainit) before win32file still looking for some feedback on this one though. i've changed the buffer handling parts to use the 'buffer api' File Added: win32file.i-3.patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1937527&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2009-02-07 02:24:38
|
Patches item #2092722, was opened at 2008-09-04 18:09 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=2092722&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Hartmut Goebel (htgoebel) Assigned to: Nobody/Anonymous (nobody) Summary: pywin32_postinstall.py fails when installing an egg Initial Comment: pywin32_postinstall.py fails when installing an egg. I figured out that LoadSystemModule wants to load C:\Python25\Lib\site-packages\pywin32_system32\pywintypes25.dll which doe not exist in an egg. Enclosed patch used pkg_resources to get the correct directory. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2009-02-07 12:56 Message: Sorry for the delay in getting to this. I don't think the patch is quite correct - eg, on my machine without a pywin32 egg installed: python -c "from pkg_resources import resource_filename, Requirement;print resource_filename(Requirement.parse('pywin32'), '')" ... File "o:\src\python-2.5-svn\lib\ntpath.py", line 90, in join assert len(path) > 0 TypeError: object of type 'NoneType' has no len() So we probably need a way to reliably detect if we are being installed from an egg or not. Secondly, I'm a little concerned about running the post-install script automatically. I imagine that many users of pywin32 via an egg will be using some kind of 'automated' process, possibly in a virtualenv environment, or stand-alone Zope environment etc. In such cases it doesn't make sense to perform most of those post-install tasks - even copying those DLLs to system32 would be inappropriate - in such cases they should *only* be installed to the python dir and never to system32. Maybe the post-install script needs to change its behaviour based on being in an egg or not - which ties in with my initial comment. Any thoughts? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=2092722&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2009-02-06 04:17:15
|
Bugs item #2571135, was opened at 2009-02-05 21:17 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=2571135&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: George Hebert (g_hebert) Assigned to: Nobody/Anonymous (nobody) Summary: edit with pythonwin - importing issue Initial Comment: There is a feature that I have been using for quite a while in PythonWin that is no longer working the way it once was and that is when you right-click on a .py file and click "edit in pythonwin". Normally when I do this and it opens pythonwin, I can import files within the interpreter that happen to be located in the same folder. After editing this file, if I attempt to import a file in the interpreter it does not find the file. The way I have had to fix this is by running the following command every time I open pythonwin: import sys sys.path.insert(0, '') After I have done this, pythonwin seems to do what it use to do and allows me to import files in the same directory as the file that I right-clicked on and said "edit with pythonwin". Note: This feature worked on version 2.5 and below. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2571135&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2009-02-06 03:25:15
|
Bugs item #2571020, was opened at 2009-02-05 20:25 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=2571020&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: George Hebert (g_hebert) Assigned to: Nobody/Anonymous (nobody) Summary: ADODBAPI - py2exe bug Initial Comment: If a Python application uses adodbapi and is compiled into an exe using Py2exe, that app will fail on importing as soon as it is executed because of the following line: version = __doc__.split('-',2)[0] #v2.1 Cole It appears as though __doc__ is None if being used within a compiled python app (exe). This could be fixed if the version was simply set to a string... ex: version = 'adodbapi 2.x.x'. There may be other ways of fixing this but I believe this would be the easiest. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2571020&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2009-02-03 12:19:36
|
Bugs item #2560493, was opened at 2009-02-03 12:39 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=2560493&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: MizardX (mizardx) Assigned to: Nobody/Anonymous (nobody) Summary: No option to change default background. Initial Comment: In my quest to get a light-on-dark theme in the editor, I found the "Default Background" registry option. But there is no control to change that in the "Pythonwin Options"-dialog. "Default Background" is referenced from pywin\scintilla\formatter.py on line 77: bg = int( self.LoadPreference( "Default Background", -1 ) ) I do not have enough knowledge of C++ and windows-programming to attempt to add a new control to the dialog. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2560493&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2009-02-03 12:17:21
|
Bugs item #2560609, was opened at 2009-02-03 13:17 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=2560609&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: MizardX (mizardx) Assigned to: Nobody/Anonymous (nobody) Summary: Color of the folding margin. Initial Comment: It is currently impossible to change the color of the folding margin. The variables that need changing is 'selbar', and 'selbarlight' in the current instance of 'ViewStyle' (in Pythonwin/Scintilla/src/ViewStyle.cxx). Those two variables does not read their values from a defined style, nor is there any way to update them from python code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2560609&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2009-02-03 12:02:23
|
Bugs item #2560493, was opened at 2009-02-03 12:39 Message generated for change (Comment added) made by mizardx You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2560493&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: MizardX (mizardx) Assigned to: Nobody/Anonymous (nobody) Summary: No option to change default background. Initial Comment: In my quest to get a light-on-dark theme in the editor, I found the "Default Background" registry option. But there is no control to change that in the "Pythonwin Options"-dialog. "Default Background" is referenced from pywin\scintilla\formatter.py on line 77: bg = int( self.LoadPreference( "Default Background", -1 ) ) I do not have enough knowledge of C++ and windows-programming to attempt to add a new control to the dialog. ---------------------------------------------------------------------- >Comment By: MizardX (mizardx) Date: 2009-02-03 13:02 Message: For anyone who would be interested in a light-on-dark theme (rip of the desert theme from gvim), here is a reg-file with the appropriate settings. Folding does not work with this theme (and gets disabled my the reg-file), as it is currently impossible to change the color of the folding-column trough settings alone. Also, it uses the 'Consolas' font instead of the default 'Courier New'. File Added: desert_theme.reg ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2560493&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2009-02-03 11:17:31
|
Bugs item #2560427, was opened at 2009-02-03 12:17 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=2560427&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: MizardX (mizardx) Assigned to: Nobody/Anonymous (nobody) Summary: Line number formatting Initial Comment: I can't change the formatting of the line-numbers. I'm attaching a patch file which adds two more list items to the "Formatting"-tab in the "Pythonwin Options"-dialog. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2560427&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2009-02-03 11:06:54
|
Bugs item #2560391, was opened at 2009-02-03 12:06 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=2560391&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: MizardX (mizardx) Assigned to: Nobody/Anonymous (nobody) Summary: Fold margin default values inconsistent Initial Comment: When you first start the editor the margin is small. If you go to options and change anything in the "Editor"-tab, the margin suddenly gets bigger. This is due to different default values in pywin/framework/editor/color/coloreditor.py and pywin/framework/editor/configui.py I'm attaching a patch which fixes this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2560391&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2009-02-03 10:53:13
|
Bugs item #2560351, was opened at 2009-02-03 11:53 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=2560351&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: MizardX (mizardx) Assigned to: Nobody/Anonymous (nobody) Summary: Can't change Folding Margin width Initial Comment: Changing the value of "Folding" under "Margin Widths" on the "Editor"-tab in the "Pythonwin Options"-dialog have no effect on the editor. I'm attaching a patch-file which fixes this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2560351&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2009-02-01 10:45:58
|
Bugs item #2551530, was opened at 2009-01-31 17:00 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2551530&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: markt (metolone) Assigned to: Nobody/Anonymous (nobody) Summary: hang/crash with Chinese system locales Initial Comment: When the default non-Unicode locale is changed to "Chinese(PRC)", PythonWin hangs when any valid command (for example, "x=1") is entered in the interactive window, and crashes when an invalid command is entered ("x" when the variable isn't defined). The details of the crash dialog are: Error signature: AppName: pythonwin.exe AppVer: 2.6.212.0 ModName scintilla.dll ModVer 1.7.5.0 Offset: 00009a92 To change the default non-Unicode locale on Windows XP, go to Control Panel, Regional and Language Options, Advanced tab, and change the item "Select a language to match the language version of the non-Unicode programs you want to use:" to "Chinese (PRC)". Remember your old setting! Click OK, then reboot for it to take effect. You may be prompted to insert your Windows XP installation disk to install the required Asian support files. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2009-02-01 21:45 Message: Fixed checked in and will be in build 213. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2551530&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2009-02-01 10:43:07
|
Bugs item #2555415, was opened at 2009-02-01 21:43 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=2555415&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: Mark Hammond (mhammond) Assigned to: Nobody/Anonymous (nobody) Summary: backspacing over extended chars is incorrect Initial Comment: >From Mark Tolonen, and is only relevant for build 213 and later: Backspacing over a multibyte character in the file editor doesn't delete the whole character. It deletes the first byte of the multibyte sequence. The result for a single press of backspace over a Chinese character (3 > bytes) prints the graphic byte codes of the two remaining bytes. The interactive window works correctly. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2555415&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2009-02-01 10:41:55
|
Bugs item #2555414, was opened at 2009-02-01 21:41 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2555414&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: Mark Hammond (mhammond) Assigned to: Nobody/Anonymous (nobody) Summary: "save" in the interactive window silently does nothing Initial Comment: >From Mark Tolonen: When the focus is in the interactive window and Save is selected, the file save dialog comes up with Interactive Window" as the default file name. If I then click Save no file is actually created. IIRC, this has been happening even in older versions of PythonWin, but it seems like it should save the contents of the interactive window, or the button should be disabled when the interactive window has focus. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2555414&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2009-01-31 15:08:45
|
Bugs item #2310121, was opened at 2008-11-18 17:04 Message generated for change (Comment added) made by tjgolden You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2310121&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 Private: No Submitted By: Tim Golden (tjgolden) Assigned to: Nobody/Anonymous (nobody) Summary: GetDlgItemText fails with no contents Initial Comment: win32gui.GetDlgItemText returns an error if there is nothing in the control in question. I'm not sure if this is "correct" (since the docs say that zero is returned on failure) but I can't see how else to determine that the control has no contents. I can work around the issue by catching the exception and assuming that there are no contents. ---------------------------------------------------------------------- >Comment By: Tim Golden (tjgolden) Date: 2009-01-31 15:08 Message: Thanks very much ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2009-01-30 23:29 Message: Checking in win32/src/win32gui.i; new revision: 1.124; previous revision: 1.123 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2310121&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2009-01-31 14:03:34
|
Bugs item #1784777, was opened at 2007-08-30 08:12 Message generated for change (Comment added) made by jaraco You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1784777&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: win32 Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bernhard (bernhard_bender) Assigned to: Jason R. Coombs (jaraco) Summary: wrong timezone info returned by GetTimeZoneInformation() Initial Comment: In my setting: Windows XP (German), up-to-date patches applied (including the lated August 2007 timezone database patch) Python 2.4 pywin 2.10 Timezone Europe/Berlin (+0100) with DST enabled win32api.GetTimeZoneInformation() returns seemingly wrong information for the date DST ends. This is shown by the little scripe I have attached, which prints: >>> Daylight time begins : Last Sunday in March Daylight time ends : Last Thursday in October <<< Since I am pretty sure that our DST does not end on a Thursday, I suspect an error in either the implementation of GetTimeZoneInformation() or in the WinXP TZ database. ---------------------------------------------------------------------- >Comment By: Jason R. Coombs (jaraco) Date: 2009-01-31 09:03 Message: I think the solution is to use win32api.GetTimeZoneInformation(True), available in the forthcoming pywin32-213, to get tuples instead of the PyTime structures, which then contain the unaltered elements of a SYSTEMTIME structure. Alternately, the new release has direct support for parsing the result of the API call: win32timezone.TimeZoneInfo.local() ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2009-01-31 00:59 Message: Jason, I think this has been addressed in the most recent win32timezone changes? Bernhard, please keep your eye open for build 213 which has this new version. ---------------------------------------------------------------------- Comment By: Jason R. Coombs (jaraco) Date: 2007-09-04 21:26 Message: Logged In: YES user_id=599869 Originator: NO I'm attaching a patch that demonstrates (perhaps incorrectly) a way to address this issue. I've never done PythonC programming (that is, extensions to python in C/C++). I used to know C++ like the back of my hand, and now it looks Greek to me. What I think I've proposed will change the return value for GetTimeZoneInformation, which will break prior implementations that depend on it. I think Bernhard has demonstrated, however, that any implementations that depend on it are probably flawed anyway, so that's why I'm suggesting changing the interface. I think the patch returns a tuple of 8 ints (they're defined as WORDs in the specs) instead of converting to the PyTime object (via PyWinObject_FromSYSTEMTIME). This could probably better be implemented with a different class (instead of PyTime) to represent SYSTEMTIME when converting to variant time is inadequate such as in this case. Although this is assigned to me, I'd like to defer to Mark as to how he would like to approach this issue. Mark, if you would like me to fully test and implement a full patch, I'll need some assistance on getting a PyWin32 development environment set up. File Added: win32apimodule.cpp.systemtime.patch ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2007-09-04 19:18 Message: Logged In: YES user_id=14198 Originator: NO Hi jason, Thanks for your comments. I've taken the liberty of adding you to the pywin32 project and making you an admin in various places, so now you can be assigned bugs (which I've done here) and should also be able to make any changes to them. Cheers ---------------------------------------------------------------------- Comment By: Jason R. Coombs (jaraco) Date: 2007-09-04 10:45 Message: Logged In: YES user_id=599869 Originator: NO It seems I can't attach files to a bug I did not create. ---------------------------------------------------------------------- Comment By: Jason R. Coombs (jaraco) Date: 2007-09-04 10:43 Message: Logged In: YES user_id=599869 Originator: NO Indeed, that's my finding as well. It's probably not appropriate to construct a PyTime from the SYSTEMTIME structure in GetTimeZoneInformation, as it's using the day of the week value explicitly. In the meantime, Bernhard, you may try using the win32timezone module. I wrote it, and it reads from the registry directly to provide richer timezone support than the Microsoft system calls. >>> import win32timezone >>> my_tz = win32timezone.GetLocalTimeZone() >>> my_tz.GetDSTStartTime(2007) datetime.datetime(2007, 3, 11, 2, 0) Note there are some changes to this module that aren't in the current release of pywin32 (build 210). I will attach the latest win32timezone.py to this bug for convenience. ---------------------------------------------------------------------- Comment By: Bernhard (bernhard_bender) Date: 2007-09-04 10:32 Message: Logged In: YES user_id=1637368 Originator: YES I had been doing some digging in the source code. I may well be that the problem stems from the fact that the date for changing time zones is stored as a float (seconds since the epoch). As such it does not explicitly store the day of week, but rather the day of week is recalculated in the Format() method. Thank you for looking into this. Bernhard ---------------------------------------------------------------------- Comment By: Jason R. Coombs (jaraco) Date: 2007-09-04 10:25 Message: Logged In: YES user_id=599869 Originator: NO I looked into the .NET platform, but it uses a completely different mechanism, apparently, so it was little help. ipy >>> from System import TimeZone >>> localZone = TimeZone.CurrentTimeZone >>> print localZone.StandardName Eastern Standard Time >>> localZone.GetDaylightChanges( 2007 ).Start <System.DateTime object at 0x000000000000002D [11-Mar-2007 02:00:00]> BTW, 11-Mar is correct (not 10-Mar like I mentioned earlier). ---------------------------------------------------------------------- Comment By: Jason R. Coombs (jaraco) Date: 2007-09-04 10:13 Message: Logged In: YES user_id=599869 Originator: NO It's not immediately clear to me what's going on here. It does appear as if GetTimeZoneInformation() is returning the wrong values. >>> win32api.GetTimeZoneInformation() (2, (300, u'Eastern Standard Time', <PyTime:01-Nov-2000 02:00:00>, 0, u'Eastern Daylight Time', <PyTime:02-Mar-2000 02:00:00>, -60)) One interesting point to note is the date is 2000 (not 2007). I don't know why this would be. This year, it should be 04-Nov and 10-Mar. The 01-Nov and 02-Mar does coincide with first and second weeks, so perhaps pywin32 is misinterpreting the structure? It's just a SYSTEMTIME, so that seems unlikely. I suspect this problem emerged with the introduction of dynamic time zones. I'd be interested to see what the results of GetDynamicTimeZoneInformation or GetTimeZoneInformationForYear would produce. I think the next steps are to (a) double-check the source to confirm the fields are being parsed correctly and (b) to call this from another platform (native C++ or .NET) to see what the results of the call are. Bernhard, would you be willing to return the output of the raw GetTimeZoneInformation() call? I think that would help me prove or disprove my theory of the fields being mis-interpreted. ---------------------------------------------------------------------- Comment By: Jason R. Coombs (jaraco) Date: 2007-09-04 09:40 Message: Logged In: YES user_id=599869 Originator: NO I am seeing this behavior on my US Win Vista machine also. I will investigate. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1784777&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2009-01-31 06:00:22
|
Bugs item #2551530, was opened at 2009-01-30 22:00 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=2551530&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: markt (metolone) Assigned to: Nobody/Anonymous (nobody) Summary: hang/crash with Chinese system locales Initial Comment: When the default non-Unicode locale is changed to "Chinese(PRC)", PythonWin hangs when any valid command (for example, "x=1") is entered in the interactive window, and crashes when an invalid command is entered ("x" when the variable isn't defined). The details of the crash dialog are: Error signature: AppName: pythonwin.exe AppVer: 2.6.212.0 ModName scintilla.dll ModVer 1.7.5.0 Offset: 00009a92 To change the default non-Unicode locale on Windows XP, go to Control Panel, Regional and Language Options, Advanced tab, and change the item "Select a language to match the language version of the non-Unicode programs you want to use:" to "Chinese (PRC)". Remember your old setting! Click OK, then reboot for it to take effect. You may be prompted to insert your Windows XP installation disk to install the required Asian support files. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2551530&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2009-01-31 05:59:21
|
Bugs item #1784777, was opened at 2007-08-30 22:12 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1784777&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: win32 Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Bernhard (bernhard_bender) Assigned to: Jason R. Coombs (jaraco) Summary: wrong timezone info returned by GetTimeZoneInformation() Initial Comment: In my setting: Windows XP (German), up-to-date patches applied (including the lated August 2007 timezone database patch) Python 2.4 pywin 2.10 Timezone Europe/Berlin (+0100) with DST enabled win32api.GetTimeZoneInformation() returns seemingly wrong information for the date DST ends. This is shown by the little scripe I have attached, which prints: >>> Daylight time begins : Last Sunday in March Daylight time ends : Last Thursday in October <<< Since I am pretty sure that our DST does not end on a Thursday, I suspect an error in either the implementation of GetTimeZoneInformation() or in the WinXP TZ database. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2009-01-31 16:59 Message: Jason, I think this has been addressed in the most recent win32timezone changes? Bernhard, please keep your eye open for build 213 which has this new version. ---------------------------------------------------------------------- Comment By: Jason R. Coombs (jaraco) Date: 2007-09-05 11:26 Message: Logged In: YES user_id=599869 Originator: NO I'm attaching a patch that demonstrates (perhaps incorrectly) a way to address this issue. I've never done PythonC programming (that is, extensions to python in C/C++). I used to know C++ like the back of my hand, and now it looks Greek to me. What I think I've proposed will change the return value for GetTimeZoneInformation, which will break prior implementations that depend on it. I think Bernhard has demonstrated, however, that any implementations that depend on it are probably flawed anyway, so that's why I'm suggesting changing the interface. I think the patch returns a tuple of 8 ints (they're defined as WORDs in the specs) instead of converting to the PyTime object (via PyWinObject_FromSYSTEMTIME). This could probably better be implemented with a different class (instead of PyTime) to represent SYSTEMTIME when converting to variant time is inadequate such as in this case. Although this is assigned to me, I'd like to defer to Mark as to how he would like to approach this issue. Mark, if you would like me to fully test and implement a full patch, I'll need some assistance on getting a PyWin32 development environment set up. File Added: win32apimodule.cpp.systemtime.patch ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2007-09-05 09:18 Message: Logged In: YES user_id=14198 Originator: NO Hi jason, Thanks for your comments. I've taken the liberty of adding you to the pywin32 project and making you an admin in various places, so now you can be assigned bugs (which I've done here) and should also be able to make any changes to them. Cheers ---------------------------------------------------------------------- Comment By: Jason R. Coombs (jaraco) Date: 2007-09-05 00:45 Message: Logged In: YES user_id=599869 Originator: NO It seems I can't attach files to a bug I did not create. ---------------------------------------------------------------------- Comment By: Jason R. Coombs (jaraco) Date: 2007-09-05 00:43 Message: Logged In: YES user_id=599869 Originator: NO Indeed, that's my finding as well. It's probably not appropriate to construct a PyTime from the SYSTEMTIME structure in GetTimeZoneInformation, as it's using the day of the week value explicitly. In the meantime, Bernhard, you may try using the win32timezone module. I wrote it, and it reads from the registry directly to provide richer timezone support than the Microsoft system calls. >>> import win32timezone >>> my_tz = win32timezone.GetLocalTimeZone() >>> my_tz.GetDSTStartTime(2007) datetime.datetime(2007, 3, 11, 2, 0) Note there are some changes to this module that aren't in the current release of pywin32 (build 210). I will attach the latest win32timezone.py to this bug for convenience. ---------------------------------------------------------------------- Comment By: Bernhard (bernhard_bender) Date: 2007-09-05 00:32 Message: Logged In: YES user_id=1637368 Originator: YES I had been doing some digging in the source code. I may well be that the problem stems from the fact that the date for changing time zones is stored as a float (seconds since the epoch). As such it does not explicitly store the day of week, but rather the day of week is recalculated in the Format() method. Thank you for looking into this. Bernhard ---------------------------------------------------------------------- Comment By: Jason R. Coombs (jaraco) Date: 2007-09-05 00:25 Message: Logged In: YES user_id=599869 Originator: NO I looked into the .NET platform, but it uses a completely different mechanism, apparently, so it was little help. ipy >>> from System import TimeZone >>> localZone = TimeZone.CurrentTimeZone >>> print localZone.StandardName Eastern Standard Time >>> localZone.GetDaylightChanges( 2007 ).Start <System.DateTime object at 0x000000000000002D [11-Mar-2007 02:00:00]> BTW, 11-Mar is correct (not 10-Mar like I mentioned earlier). ---------------------------------------------------------------------- Comment By: Jason R. Coombs (jaraco) Date: 2007-09-05 00:13 Message: Logged In: YES user_id=599869 Originator: NO It's not immediately clear to me what's going on here. It does appear as if GetTimeZoneInformation() is returning the wrong values. >>> win32api.GetTimeZoneInformation() (2, (300, u'Eastern Standard Time', <PyTime:01-Nov-2000 02:00:00>, 0, u'Eastern Daylight Time', <PyTime:02-Mar-2000 02:00:00>, -60)) One interesting point to note is the date is 2000 (not 2007). I don't know why this would be. This year, it should be 04-Nov and 10-Mar. The 01-Nov and 02-Mar does coincide with first and second weeks, so perhaps pywin32 is misinterpreting the structure? It's just a SYSTEMTIME, so that seems unlikely. I suspect this problem emerged with the introduction of dynamic time zones. I'd be interested to see what the results of GetDynamicTimeZoneInformation or GetTimeZoneInformationForYear would produce. I think the next steps are to (a) double-check the source to confirm the fields are being parsed correctly and (b) to call this from another platform (native C++ or .NET) to see what the results of the call are. Bernhard, would you be willing to return the output of the raw GetTimeZoneInformation() call? I think that would help me prove or disprove my theory of the fields being mis-interpreted. ---------------------------------------------------------------------- Comment By: Jason R. Coombs (jaraco) Date: 2007-09-04 23:40 Message: Logged In: YES user_id=599869 Originator: NO I am seeing this behavior on my US Win Vista machine also. I will investigate. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1784777&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2009-01-31 02:43:44
|
Bugs item #2488784, was opened at 2009-01-05 15:11 Message generated for change (Comment added) made by merrami You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2488784&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: com Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mounir (merrami) Assigned to: Nobody/Anonymous (nobody) Summary: Unicode exception when using ie.Navigate after dispatch Initial Comment: The situation: When using a IE browser after dispatch and navigating to a particular URL, the exception at the end of this note is observed Important information: this is from the user of a commercial python program (provided as an executable) called CiteSmart. The error is observed very likely because th user is using a Corean version of Windows XP. This bug couldn't be reproduced on an english plate-form. > Traceback (most recent call last): > File "win32com\server\policy.pyo", line 285, in _Invoke_ > File "win32com\server\policy.pyo", line 290, in _invoke_ > File "win32com\server\policy.pyo", line 658, in _invokeex_ > File "win32com\server\policy.pyo", line 653, in > _transform_args_ > : 'ascii' codec can't encode > characters in position 0-1: ordinal not in ---------------------------------------------------------------------- >Comment By: Mounir (merrami) Date: 2009-01-30 20:43 Message: Mark frankly I don't know what has happened. Again, this happened to the user of our product. He is using a Korean version of XP, so I don't have access to his computer and can't reproduce the problem. I guess there is little that can be done. We will see once the new win32com is out. By the way this has happened with IE, so there may be some reasons there (local configuration of the browser. Go figure...) Anyway thank you very much for taking a loot at this. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2009-01-30 20:36 Message: Oops - I meant policy.py. If you check that file, you should find that core_has_unicode is always True for all supported Python versions - so I don't quite understand how we could have entered that block. The next win32com version will have removed it completely, but that still doesn't explain how you are hitting this. ---------------------------------------------------------------------- Comment By: Mounir (merrami) Date: 2009-01-30 19:17 Message: Mark thank you for taking time to review this issue. Yes the line you mention is there in the file policy.py at the lines 652-3 (and not in transform.py). The python version that was used is 2.5.1 (r251:54863) If there is anything I can do to help, let me know. Thank you for your amazing contribution and the excellent tools you provide us with. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2009-01-30 17:22 Message: This is very strange. That error seems to be: elif not core_has_unicode and arg_type==UnicodeType: arg = str(arg) and 'core_has_unicode' should *always* be True in recent builds. What version of Python are you using? Can you please confirm that line 653 in your transform.py does point at that code? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2488784&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2009-01-31 02:36:30
|
Bugs item #2488784, was opened at 2009-01-06 08:11 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2488784&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: com Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mounir (merrami) Assigned to: Nobody/Anonymous (nobody) Summary: Unicode exception when using ie.Navigate after dispatch Initial Comment: The situation: When using a IE browser after dispatch and navigating to a particular URL, the exception at the end of this note is observed Important information: this is from the user of a commercial python program (provided as an executable) called CiteSmart. The error is observed very likely because th user is using a Corean version of Windows XP. This bug couldn't be reproduced on an english plate-form. > Traceback (most recent call last): > File "win32com\server\policy.pyo", line 285, in _Invoke_ > File "win32com\server\policy.pyo", line 290, in _invoke_ > File "win32com\server\policy.pyo", line 658, in _invokeex_ > File "win32com\server\policy.pyo", line 653, in > _transform_args_ > : 'ascii' codec can't encode > characters in position 0-1: ordinal not in ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2009-01-31 13:36 Message: Oops - I meant policy.py. If you check that file, you should find that core_has_unicode is always True for all supported Python versions - so I don't quite understand how we could have entered that block. The next win32com version will have removed it completely, but that still doesn't explain how you are hitting this. ---------------------------------------------------------------------- Comment By: Mounir (merrami) Date: 2009-01-31 12:17 Message: Mark thank you for taking time to review this issue. Yes the line you mention is there in the file policy.py at the lines 652-3 (and not in transform.py). The python version that was used is 2.5.1 (r251:54863) If there is anything I can do to help, let me know. Thank you for your amazing contribution and the excellent tools you provide us with. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2009-01-31 10:22 Message: This is very strange. That error seems to be: elif not core_has_unicode and arg_type==UnicodeType: arg = str(arg) and 'core_has_unicode' should *always* be True in recent builds. What version of Python are you using? Can you please confirm that line 653 in your transform.py does point at that code? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2488784&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2009-01-31 01:17:26
|
Bugs item #2488784, was opened at 2009-01-05 15:11 Message generated for change (Comment added) made by merrami You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2488784&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: com Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mounir (merrami) Assigned to: Nobody/Anonymous (nobody) Summary: Unicode exception when using ie.Navigate after dispatch Initial Comment: The situation: When using a IE browser after dispatch and navigating to a particular URL, the exception at the end of this note is observed Important information: this is from the user of a commercial python program (provided as an executable) called CiteSmart. The error is observed very likely because th user is using a Corean version of Windows XP. This bug couldn't be reproduced on an english plate-form. > Traceback (most recent call last): > File "win32com\server\policy.pyo", line 285, in _Invoke_ > File "win32com\server\policy.pyo", line 290, in _invoke_ > File "win32com\server\policy.pyo", line 658, in _invokeex_ > File "win32com\server\policy.pyo", line 653, in > _transform_args_ > : 'ascii' codec can't encode > characters in position 0-1: ordinal not in ---------------------------------------------------------------------- >Comment By: Mounir (merrami) Date: 2009-01-30 19:17 Message: Mark thank you for taking time to review this issue. Yes the line you mention is there in the file policy.py at the lines 652-3 (and not in transform.py). The python version that was used is 2.5.1 (r251:54863) If there is anything I can do to help, let me know. Thank you for your amazing contribution and the excellent tools you provide us with. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2009-01-30 17:22 Message: This is very strange. That error seems to be: elif not core_has_unicode and arg_type==UnicodeType: arg = str(arg) and 'core_has_unicode' should *always* be True in recent builds. What version of Python are you using? Can you please confirm that line 653 in your transform.py does point at that code? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2488784&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2009-01-30 23:39:18
|
Bugs item #2118863, was opened at 2008-09-19 16:59 Message generated for change (Settings changed) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2118863&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Works For Me Priority: 5 Private: No Submitted By: Farzin Shakib (acusim) Assigned to: Nobody/Anonymous (nobody) Summary: Error compiling Initial Comment: I just obtained the pywin32-212.zip and attempted to build it, but got the following error: $ python setup.py install Building pywin32 2.4.212.0 running install running build running build_py running build_ext Found version 0x500 in C:\Program Files\Microsoft Visual Studio .NET 2003\VC7\PlatformSDK\include\WinResrc.h building 'pywintypes' extension c:\Program Files\Microsoft Visual Studio .NET 2003\VC7\BIN\cl.exe /c /nologo /Ob2ty /MD /W3 /EHsc /DNDEBUG -DDISTUTILS_BUILD -Icom/win32com/src/include -Iwin32/src -Ic:\Acusim\Win\V1.3\base\include -Ic:\Acusim\Win\V1.3\base\PC /Tpwin32\src\PyACL.cpp /Fobuild\temp.win32-2.4\Release\win32\src\PyACL.obj -DBUILD_PYWINTYPES /YXPyWinTypes.h /Fpbuild\temp.win32-2.4\Release\pywintypes.pch /Zi /Fdbuild\temp.win32-2.4\Release\pywintypes_vc.pdb /EHsc /DMFC_OCC_IMPL_H=\"..\src\occimpl.h\" PyACL.cpp win32\src\PyACL.cpp(4) : fatal error C1083: Cannot open precompiled header file: 'build\temp.win32-2.4\Release\pywintypes.pch': The process cannot access the file because it is being used by another process. This is done on a Windows 2000. Any ideas how to resolve this issue? Farzin ---------------------------------------------------------------------- Comment By: Ziga Seilnacht (zseil) Date: 2008-10-02 09:13 Message: You should update your Platform SDK. Search for: "Microsoft Windows Software Development Kit Update for Windows Vista" on the Microsoft download site. Note that the latest version, "Windows SDK for Windows Server 2008 and .NET Framework 3.5", won't work with Visual Studio 2003. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2118863&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2009-01-30 23:38:33
|
Bugs item #2132639, was opened at 2008-09-28 04:56 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2132639&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: win32 Group: None >Status: Closed >Resolution: Rejected Priority: 5 Private: No Submitted By: Alan Gardner (jiaailun) Assigned to: Nobody/Anonymous (nobody) Summary: win32file.GetCommState incorrect handling of DCB Initial Comment: I believe I have found a bug in win32file.GetCommState and win32file.SetCommState. I have seen it in Python 2.4 and Python 2.5, running an older version of pywin32, as well as the current (212) version. It exists in Win2k and WinXP. I use pyserial 2.4 as a wrapper for the comm ports, though I believe the problem is in win32file. The problem manifests itself when I try to open a com port in Python after having that port open in Procomm (an old, no longer supported terminal program). I have only seen it happen with a particular brand of USB to serial converters (Edgeport, made by Digi). In these conditions the python script will hang at the win32file.SetCommState() command, usually timing out after 5-30 seconds, and quitting with no error message. After having done some probing I think I basically understand the problem, and have a workaround, but I lack the know-how to fix it where it should be fixed, in win32file. When Procomm opens the port, it sets XoffLim to 16128 and the XonLim to 15872. When my script (actually, serialwin32.py from pyserial) tries to open the port it first reads the DCB with GetCommState(), changes baud rate, etc in the local PyDCB object, and then tries to reconfigure the port with SetCommState(). >From what I can tell, SetCommState won't accept a value for XoffLim or XonLim >4096. For example, if I try to execute the following: DCB.XoffLim = 16128 SetCommState(porthandle,DCB) I get an exception: (87, 'SetCommState', 'The parameter is incorrect.') However, if GetCommState gets a DCB which has XoffLim = 16128, and then that DCB is passed to SetCommState, the script hangs for several seconds before exiting without opening the port and with no error message. For example, after having opened and closed the port in Procomm: >>> DCB = GetCommState(porthandle) >>> DCB.XoffLim 16128L >>> SetCommState(porthandle,DCB) (...... hangs here for several seconds ......) If I set XoffLim and XonLim to values from 0-4096 before calling SetCommState, then it works fine. For example, after having opened and closed the port in Procomm: >>> DCB = GetCommState(porthandle) >>> DCB.XoffLim = 128 >>> DCB.XonLim = 512 >>> SetCommState(porthandle,DCB) >>> This works fine, and I can go on to open the port normally. I have incorporated this fix into serialwin32.py which is working for me now, but it's not an elegant solution. I am still baffled by why SetCommState limits Xon/XoffLim to 4096, and by what GetCommState does to the PyDCB to make it cause SetCommState to fail so dramatically. I also don't understand why I only see this problem with the Edgeport USB converters, and not with several other USB converters or hardware serial ports. Maybe someone with a more intimate understanding of Python and Win32 can come up with some answers. Thank you -Alan Gardner Woods Hole Oceanographic Institution Woods Hole, MA 02543 ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2009-01-31 10:38 Message: I think we agree nothing in pywin32 should change due to this. ---------------------------------------------------------------------- Comment By: Alan Gardner (jiaailun) Date: 2008-10-02 23:11 Message: Gentlemen, I appreciate your time helping me work this out. I have been in contact with the vendor, and after trying several things they had started to point the finger at Python. I am feeling pretty confident now that the problem is not related to Python, and I have a reasonably good handle on what's going on. I will follow up with the vendor. Unfortunately Procomm is unsupported now, but I really don't think that it is doing anything "wrong", it just leaves the port in a state that the driver reacts badly to. I will follow up here if I learn anything more. Thank you. -Alan ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2008-10-02 07:23 Message: The code to call SetCommState does not do any retries. If you're seeing multiple attempts to set the configuration parameters, they're probably coming from the driver itself. Since this problem only happens for a particular device, and only after a completely separate program has accessed it, it's most likely due to the device driver, and/or the state in which the other program leaves the port. I really don't think there's anything that can be done in win32file to solve it. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2008-09-30 14:52 Message: If you think pywin32 is doing something incorrect with its DCB handling, the only real way to demonstrate that is a snippet of C code that behaves differently. Given our arg handling looks OK, we will otherwise need to assume the behaviour is just a characteristic of the windows API itself. ---------------------------------------------------------------------- Comment By: Alan Gardner (jiaailun) Date: 2008-09-30 14:41 Message: OK, since I realize this may be a difficult problem to recreate I have annotated some screen captures from the interpreter. In the process I realized that the XonLim and XoffLim are obviously going to be limited by the buffer size, and yes, pyserial does set the buffer to 4096. OK, so now I have another workaround, increasing the buffer size so that the XonLim and XoffLim values are no longer to large. But I still think that there is an underlying bug. When a port is opened with CreateFile it appears to assign a default buffer size, and this can lead to XonLim and XoffLim values which are out of range. If SetCommState then tries to set an out of range value to one of these parameters, it hangs. I have some captures from DebugView and PortMon which show Python.exe repeatedly getting and setting parameters on the serial port in a nearly endless loop. I can upload these if it would be helpful, but they are moderately large and arcane. For now I will upload the annotated screen captures showing what I see at this end. File Added: win32file.SetCommState_interactive.txt ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2008-09-28 06:13 Message: I don't see any problem with the way the DCB is passed to/from SetCommState and GetCommState. The XonLim and XoffLim members consistently have the correct value. If I recall from looking at pyserial a while back, it sets the buffer sizes to 4096. Have you tried increasing them in the call to SetupComm ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2132639&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2009-01-30 23:29:16
|
Bugs item #2310121, was opened at 2008-11-19 04:04 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2310121&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 Private: No Submitted By: Tim Golden (tjgolden) Assigned to: Nobody/Anonymous (nobody) Summary: GetDlgItemText fails with no contents Initial Comment: win32gui.GetDlgItemText returns an error if there is nothing in the control in question. I'm not sure if this is "correct" (since the docs say that zero is returned on failure) but I can't see how else to determine that the control has no contents. I can work around the issue by catching the exception and assuming that there are no contents. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2009-01-31 10:29 Message: Checking in win32/src/win32gui.i; new revision: 1.124; previous revision: 1.123 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2310121&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2009-01-30 23:25:34
|
Bugs item #2370817, was opened at 2008-12-01 23:26 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2370817&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: Wont Fix Priority: 5 Private: No Submitted By: ionel (ionel_mc) Assigned to: Nobody/Anonymous (nobody) Summary: pywin32 doesn't compile on win xp Initial Comment: Due to many constants and missing functions that are only available on vista and not platform-checked. eg: win32/src/win32inetmodule.cpp(1381) : error C2065: 'INTERNET_OPTION_CODEPAGE_PATH' : undeclared identifier win32/src/win32inetmodule.cpp(1381) : error C2051: case expression not constant win32/src/win32inetmodule.cpp(1382) : error C2065: 'INTERNET_OPTION_CODEPAGE_EXTRA' : undeclared identifier win32/src/win32inetmodule.cpp(1382) : error C2051: case expression not constant win32/src/win32inetmodule.cpp(1390) : error C2065: 'INTERNET_OPTION_IDN' : undeclared identifier win32/src/win32inetmodule.cpp(1390) : error C2051: case expression not constant win32/src/win32inetmodule.cpp(1402) : error C2065: 'INTERNET_OPTION_HTTP_DECODING' : undeclared identifier win32/src/win32inetmodule.cpp(1402) : error C2051: case expression not constant win32/src/win32inetmodule.cpp(1582) : error C2065: 'INTERNET_OPTION_CODEPAGE_PATH' : undeclared identifier win32/src/win32inetmodule.cpp(1582) : error C2051: case expression not constant win32/src/win32inetmodule.cpp(1583) : error C2065: 'INTERNET_OPTION_CODEPAGE_EXTRA' : undeclared identifier win32/src/win32inetmodule.cpp(1583) : error C2051: case expression not constant win32/src/win32inetmodule.cpp(1589) : error C2065: 'INTERNET_OPTION_IDN' : undeclared identifier win32/src/win32inetmodule.cpp(1589) : error C2051: case expression not constant win32/src/win32inetmodule.cpp(1614) : error C2065: 'INTERNET_OPTION_HTTP_DECODING' : undeclared identifier win32/src/win32inetmodule.cpp(1614) : error C2051: case expression not constant error: command '"C:\Program Files\Microsoft Visual Studio 9.0\VC\BIN\cl.exe"' failed with exit status 2 or win32\src\win32processmodule_win32.cpp(2604) : error C2065: 'THREAD_MODE_BACKGROUND_BEGIN' : undeclared identifier win32\src\win32processmodule_win32.cpp(2606) : error C2065: 'THREAD_MODE_BACKGROUND_END' : undeclared identifier error: command '"C:\Program Files\Microsoft Visual Studio 9.0\VC\BIN\cl.exe"' failed with exit status 2 ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2009-01-31 10:25 Message: It does build on XP fine - but you do need the Vista platform SDK. This is mentioned in setup.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2370817&group_id=78018 |
2 messages has been excluded from this view by a project administrator.
