pywin32-bugs Mailing List for Python for Windows Extensions (Page 62)
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...> - 2007-10-18 02:26:40
|
Bugs item #1815499, was opened at 2007-10-18 12:23 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1815499&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: zou guangxian (weck) Assigned to: Nobody/Anonymous (nobody) Summary: SetWindowPos can't work with activex control Initial Comment: In win32app.cpp:2166, BOOL ok = ::SetWindowPos( pWnd->GetSafeHwnd(), insertAfter, x, y, cx, cy, flags); should be changed to the following lines: CWnd wndInsertAfter; wndInsertAfter.Attach(insertAfter); BOOL ok = pWnd->SetWindowPos( &wndInsertAfter, x, y, cx, cy, flags); wndInsertAfter.Detach(); ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2007-10-18 12:26 Message: Logged In: YES user_id=14198 Originator: NO Can you please show an example of some code that is broken now, but is fixed with this change? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1815499&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2007-10-18 02:23:12
|
Bugs item #1815499, was opened at 2007-10-18 02:23 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=1815499&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: zou guangxian (weck) Assigned to: Nobody/Anonymous (nobody) Summary: SetWindowPos can't work with activex control Initial Comment: In win32app.cpp:2166, BOOL ok = ::SetWindowPos( pWnd->GetSafeHwnd(), insertAfter, x, y, cx, cy, flags); should be changed to the following lines: CWnd wndInsertAfter; wndInsertAfter.Attach(insertAfter); BOOL ok = pWnd->SetWindowPos( &wndInsertAfter, x, y, cx, cy, flags); wndInsertAfter.Detach(); ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1815499&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2007-10-11 21:00:24
|
Patches item #1806435, was opened at 2007-10-02 18:17 Message generated for change (Comment added) made by rlangmeier You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1806435&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: Robert Langmeier (rlangmeier) Assigned to: Nobody/Anonymous (nobody) Summary: registring a win32com server with non admin privilges only Initial Comment: I produced this patch to be able to register and use a COM server with insufficient privileges. A little explanation: - As a non admin user, you cannot write HKEY_CLASSES_ROOT, but you can register a COM server into HKEY_CURRENT_USER - HKEY_CLASSES_ROOT is a consolidated view of HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER (see MSDN) - The client can always read the registry keys in HKEY_CLASSES_ROOT It would be great if it can be integrated in a future build. Some check has to be done for parts i'm not using. Registring and unregistring "Standard" servers is correct and functionning. ---------------------------------------------------------------------- >Comment By: Robert Langmeier (rlangmeier) Date: 2007-10-11 23:00 Message: Logged In: YES user_id=75471 Originator: YES just corrected a bug in _get_classe_hkey and modified RegisterServer File Added: register-patch.py ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1806435&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2007-10-02 16:17:26
|
Patches item #1806435, was opened at 2007-10-02 18:17 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=1806435&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: Robert Langmeier (rlangmeier) Assigned to: Nobody/Anonymous (nobody) Summary: registring a win32com server with non admin privilges only Initial Comment: I produced this patch to be able to register and use a COM server with insufficient privileges. A little explanation: - As a non admin user, you cannot write HKEY_CLASSES_ROOT, but you can register a COM server into HKEY_CURRENT_USER - HKEY_CLASSES_ROOT is a consolidated view of HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER (see MSDN) - The client can always read the registry keys in HKEY_CLASSES_ROOT It would be great if it can be integrated in a future build. Some check has to be done for parts i'm not using. Registring and unregistring "Standard" servers is correct and functionning. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1806435&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2007-10-01 22:01:58
|
Bugs item #1805619, was opened at 2007-10-01 22:30 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1805619&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: Rejected Priority: 5 Private: No Submitted By: Dan Rawson (drawson1) Assigned to: Nobody/Anonymous (nobody) Summary: Tk.iconbitmap fails in debugger window Initial Comment: I'm setting the icon for my Tk application with: root.iconbitmap(default=icofile) which works perfectly outside the debugger, but fails when run from the debugger with: File "C:\localdata\Python25\lib\lib-tk\Tkinter.py", line 1513, in wm_iconbitmap return self.tk.call('wm', 'iconbitmap', self._w, '-default', default) TclError: bitmap "foo.ico" not defined Occassionally, this will work if I run it as soon as it is loaded into the debugger, but then will fail on subsequent runs. Python is 2.5 (pywin32 build 209.2) ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2007-10-02 08:02 Message: Logged In: YES user_id=14198 Originator: NO This has nothing to do with pywin32 - you probably want to open this in a Tk collector. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1805619&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2007-10-01 12:30:15
|
Bugs item #1805619, was opened at 2007-10-01 08:30 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1805619&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: Dan Rawson (drawson1) Assigned to: Nobody/Anonymous (nobody) Summary: Tk.iconbitmap fails in debugger window Initial Comment: I'm setting the icon for my Tk application with: root.iconbitmap(default=icofile) which works perfectly outside the debugger, but fails when run from the debugger with: File "C:\localdata\Python25\lib\lib-tk\Tkinter.py", line 1513, in wm_iconbitmap return self.tk.call('wm', 'iconbitmap', self._w, '-default', default) TclError: bitmap "foo.ico" not defined Occassionally, this will work if I run it as soon as it is loaded into the debugger, but then will fail on subsequent runs. Python is 2.5 (pywin32 build 209.2) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1805619&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2007-09-30 23:33:46
|
Bugs item #1799934, was opened at 2007-09-22 06:29 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1799934&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: installation Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Zooko O'Whielacronx (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: easy_install silently fails Initial Comment: If I install pywin32 by executing pywin32-210.win32-py2.5.exe , it works. If I run "easy_install pywin32" then it claims that it is downloading and installing pywin32-210.win32-py2.5.exe , and after a while it claims that it has successfully installed it, but an attempt to use pywin32 yields errors like this: $ python -c 'import win32process' Traceback (most recent call last): File "<string>", line 1, in <module> ImportError: DLL load failed: The specified module could not be found. I'm not sure whether this should be considered a bug in pywin32 or in easy_install, or both. Regards, Zooko ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2007-10-01 09:33 Message: Logged In: YES user_id=14198 Originator: NO I've no idea - that too is an easy_install question. I've never used easy_install to install pywin32, and I've never recommended anyone else do it either. ---------------------------------------------------------------------- Comment By: Zooko O'Whielacronx (zooko) Date: 2007-10-01 08:57 Message: Logged In: YES user_id=52562 Originator: YES I will see if I can make the pywin32_postinstall.py stuff get done automatically upon easy_install. In the meantime, is there some way to make this failure loud instead of silent? How do you tell easy_install: yes, there is a package in the expected format (.zip) in the expected place (pypi), but it isn't actually going to work? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2007-09-22 09:57 Message: Logged In: YES user_id=14198 Originator: NO After install, pywin32_postinstall.py needs to be run, but ezsetup apparently does not provide a facility to do that. You may like to ask them for such a facility. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1799934&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2007-09-30 22:57:01
|
Bugs item #1799934, was opened at 2007-09-21 20:29 Message generated for change (Comment added) made by zooko You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1799934&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: installation Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Zooko O'Whielacronx (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: easy_install silently fails Initial Comment: If I install pywin32 by executing pywin32-210.win32-py2.5.exe , it works. If I run "easy_install pywin32" then it claims that it is downloading and installing pywin32-210.win32-py2.5.exe , and after a while it claims that it has successfully installed it, but an attempt to use pywin32 yields errors like this: $ python -c 'import win32process' Traceback (most recent call last): File "<string>", line 1, in <module> ImportError: DLL load failed: The specified module could not be found. I'm not sure whether this should be considered a bug in pywin32 or in easy_install, or both. Regards, Zooko ---------------------------------------------------------------------- >Comment By: Zooko O'Whielacronx (zooko) Date: 2007-09-30 22:57 Message: Logged In: YES user_id=52562 Originator: YES I will see if I can make the pywin32_postinstall.py stuff get done automatically upon easy_install. In the meantime, is there some way to make this failure loud instead of silent? How do you tell easy_install: yes, there is a package in the expected format (.zip) in the expected place (pypi), but it isn't actually going to work? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2007-09-21 23:57 Message: Logged In: YES user_id=14198 Originator: NO After install, pywin32_postinstall.py needs to be run, but ezsetup apparently does not provide a facility to do that. You may like to ask them for such a facility. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1799934&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2007-09-24 02:20:07
|
Feature Requests item #1791127, was opened at 2007-09-09 09:43 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1791127&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: None Priority: 5 Private: No Submitted By: baerschen (baerschen) Assigned to: Nobody/Anonymous (nobody) Summary: Support for High Baud Rate Serial Port Initial Comment: Maybe this is a bug but by now I call i feature request. It seems it's not possible to acces the serial port at higher baudrates, e.g. 1000000bps which is theoretically possible because some terminal progs do this successful on my system. ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2007-09-23 19:20 Message: Logged In: YES user_id=1312539 Originator: NO This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2007-09-09 16:16 Message: Logged In: YES user_id=14198 Originator: NO What do you think pywin32 needs to do to enable that? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1791127&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2007-09-21 23:57:54
|
Bugs item #1799934, was opened at 2007-09-22 06:29 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1799934&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: installation Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Zooko O'Whielacronx (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: easy_install silently fails Initial Comment: If I install pywin32 by executing pywin32-210.win32-py2.5.exe , it works. If I run "easy_install pywin32" then it claims that it is downloading and installing pywin32-210.win32-py2.5.exe , and after a while it claims that it has successfully installed it, but an attempt to use pywin32 yields errors like this: $ python -c 'import win32process' Traceback (most recent call last): File "<string>", line 1, in <module> ImportError: DLL load failed: The specified module could not be found. I'm not sure whether this should be considered a bug in pywin32 or in easy_install, or both. Regards, Zooko ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2007-09-22 09:57 Message: Logged In: YES user_id=14198 Originator: NO After install, pywin32_postinstall.py needs to be run, but ezsetup apparently does not provide a facility to do that. You may like to ask them for such a facility. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1799934&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2007-09-21 20:29:58
|
Bugs item #1799934, was opened at 2007-09-21 20:29 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=1799934&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: installation Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Zooko O'Whielacronx (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: easy_install silently fails Initial Comment: If I install pywin32 by executing pywin32-210.win32-py2.5.exe , it works. If I run "easy_install pywin32" then it claims that it is downloading and installing pywin32-210.win32-py2.5.exe , and after a while it claims that it has successfully installed it, but an attempt to use pywin32 yields errors like this: $ python -c 'import win32process' Traceback (most recent call last): File "<string>", line 1, in <module> ImportError: DLL load failed: The specified module could not be found. I'm not sure whether this should be considered a bug in pywin32 or in easy_install, or both. Regards, Zooko ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1799934&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2007-09-19 20:18:17
|
Feature Requests item #1798328, was opened at 2007-09-19 22:18 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1798328&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: Marek Krocak (mkrocak) Assigned to: Nobody/Anonymous (nobody) Summary: Restore keypad +-* when folding disabled Initial Comment: Keypad '+', '-' and '*' keys are used to control folding in Pythonwin. When I disable folding in the "Pythonwin Options" dialog at the "Editor" tab, the keypad keys become inactive and hitting them has no effect. I would appreciate if they regain their original meaning of "*", "+" and "-" when folding is disabled. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1798328&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2007-09-09 23:16:50
|
Feature Requests item #1791127, was opened at 2007-09-10 02:43 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1791127&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: Pending Resolution: None Priority: 5 Private: No Submitted By: baerschen (baerschen) Assigned to: Nobody/Anonymous (nobody) Summary: Support for High Baud Rate Serial Port Initial Comment: Maybe this is a bug but by now I call i feature request. It seems it's not possible to acces the serial port at higher baudrates, e.g. 1000000bps which is theoretically possible because some terminal progs do this successful on my system. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2007-09-10 09:16 Message: Logged In: YES user_id=14198 Originator: NO What do you think pywin32 needs to do to enable that? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1791127&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2007-09-09 16:43:39
|
Feature Requests item #1791127, was opened at 2007-09-09 18:43 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1791127&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: baerschen (baerschen) Assigned to: Nobody/Anonymous (nobody) Summary: Support for High Baud Rate Serial Port Initial Comment: Maybe this is a bug but by now I call i feature request. It seems it's not possible to acces the serial port at higher baudrates, e.g. 1000000bps which is theoretically possible because some terminal progs do this successful on my system. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1791127&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2007-09-05 01:26:32
|
Bugs item #1784777, was opened at 2007-08-30 06: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: 2007-09-04 19: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 17: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 08: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 08: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 08: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 08: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 08: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 07: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...> - 2007-09-04 23:18:42
|
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: 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...> - 2007-09-04 14:45:38
|
Bugs item #1784777, was opened at 2007-08-30 06: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: Nobody/Anonymous (nobody) 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: 2007-09-04 08: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 08: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 08: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 08: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 08: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 07: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...> - 2007-09-04 14:43:53
|
Bugs item #1784777, was opened at 2007-08-30 06: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: Nobody/Anonymous (nobody) 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: 2007-09-04 08: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 08: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 08: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 08: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 07: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...> - 2007-09-04 14:32:35
|
Bugs item #1784777, was opened at 2007-08-30 14:12 Message generated for change (Comment added) made by bernhard_bender 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: Nobody/Anonymous (nobody) 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: Bernhard (bernhard_bender) Date: 2007-09-04 16: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 16: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 16: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 15: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...> - 2007-09-04 14:25:09
|
Bugs item #1784777, was opened at 2007-08-30 06: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: Nobody/Anonymous (nobody) 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: 2007-09-04 08: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 08: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 07: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...> - 2007-09-04 14:13:07
|
Bugs item #1784777, was opened at 2007-08-30 06: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: Nobody/Anonymous (nobody) 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: 2007-09-04 08: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 07: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...> - 2007-09-04 13:40:48
|
Bugs item #1784777, was opened at 2007-08-30 06: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: Nobody/Anonymous (nobody) 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: 2007-09-04 07: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...> - 2007-09-04 10:55:07
|
Bugs item #1648655, was opened at 2007-01-31 21:09 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1648655&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: com Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: atsuo ishimoto (ishimoto) Assigned to: Nobody/Anonymous (nobody) Summary: Wrong args order with event handler Initial Comment: Order of args doesn't match with prototype generated by makepy. To reproduce, please run script below and Save workbook on the Excel. # <<<<<< BEGIN >>>>>> import win32com.client class WorkbookEvent: def OnBeforeSave(self, SaveAsUI, Cancel): print "OnBeforeSave", SaveAsUI, Cancel return False xl = win32com.client.Dispatch("Excel.Application") xl.Visible = 1 wb = DispatchWithEvents(xl.Workbooks.Add(), WorkbookEvent) while 1: pythoncom.PumpWaitingMessages() # <<<<<< END >>>>>> When I save workbook, WorkbookEvent.OnBeforeSave called with SaveAsUI=False and Cancel=False. But on SaveAs, args passed are SaveAsUI=False and Cancel=True, which should be SaveAsUI=True and Cancel=False. Python2.4.3,pywin32-210,MS-Excel 2000 ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2007-09-04 20:55 Message: Logged In: YES user_id=14198 Originator: NO Thanks Roger! I've added both warnings as you suggested. Checking in com/TestSources/PyCOMTest/PyCOMImpl.cpp; new revision: 1.16; previous revision: 1.15 Checking in com/TestSources/PyCOMTest/PyCOMImpl.h; new revision: 1.15; previous revision: 1.14 Checking in com/TestSources/PyCOMTest/PyCOMTest.idl; new revision: 1.16; previous revision: 1.15 Checking in com/win32com/src/PyGatewayBase.cpp; new revision: 1.17; previous revision: 1.16 Checking in com/win32com/src/PythonCOM.cpp; new revision: 1.49; previous revision: 1.48 Checking in com/win32com/test/testPyComTest.py; new revision: 1.28; previous revision: 1.27 ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2007-09-02 04:14 Message: Logged In: YES user_id=771074 Originator: NO This works for all the cases I've tried. A couple of things that might be nice to do while we're into the code: Log the exception in invoke_setup instead of just clearing it In invoke_finish, log a warning if it doesn't receive the expected number of output parms. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2007-08-30 18:28 Message: Logged In: YES user_id=14198 Originator: NO I think this should work OK. The out params seem harder than they should be, but after a few false starts, this is the best I can come up with. The cost for no named params should be low. Let me know what you think... File Added: bug-1648655.patch ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2007-08-29 16:32 Message: Logged In: YES user_id=771074 Originator: NO I don't see anything in the docs to indicate that the sequential order of DISPIDs can't be depended upon. One thing we'd have to be careful of is missing args. I guess the tuple could be created with the max of the DISPIDs, and we could insert an ArgNotFound object for any args not passed. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2007-08-29 14:07 Message: Logged In: YES user_id=14198 Originator: NO Actually, I think there might be an easier way. The docs for ITypeInfo::GetIDsOfNames says "The IDs of parameters are 0 for the first parameter in the member function's argument list, 1 for the second, and so on" and I'm not aware of a way to override that in the IDL. So the point of GetIDsOfNames is when you do *not* know about the params - all you know is the names of params presented to you. If you pass the entire set of param names to GetIDsOfNames, you'd always get back an array from 0->n. So for our purposes, this is enough information - we can just treat the dispID as an offset into our arg tuple. Creating the tuple etc becomes a little more complicated, but thats OK, especially if we optimize the 'no named params' case. does that make sense? ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2007-08-29 13:33 Message: Logged In: YES user_id=771074 Originator: NO >From playing around inside the python event code, it looks like the type info may be available in a roundabout way: ti=self._oleobj_.GetTypeInfo(0) The returned type info is for the WorkBook itself, but the event source type info should be locatable from there (I think). The gateway object stashes away a reference to the class instance that's passed as self to the event methods in _obj_. Inside PyGatewayBase::Invoke, you can get the object that provides the type info like this: PyObject *_obj_, *_oleobj_; _obj_=PyObject_GetAttrString(this->m_pPyObject, "_obj_"); if (_obj_) _oleobj_=PyObject_GetAttrString(_obj_, "_oleobj_"); That's as far as I've got for right now. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2007-08-28 08:17 Message: Logged In: YES user_id=14198 Originator: NO Yeah, I'm a little confused about that page - but it seems pretty obvious that every Excel related call we receive does indeed have index[0] of the named items being a dispid of zero, and that this corresponds to the first arg. I understand that this isn't guaranteed though (and yeah, it is apparently not even what is recommended according to that page.) I don't think we can use GetTypeInfo() in the way you suggest. Consider this Excel example - we don't have a pointer to an Excel object, only one of our objects that implements an interface defined by Excel. I'm not sure how the PyGatewayBase code at that point could determine the dispids as defined in the excel typelib. The only way I can see it working is to have makepy include info in the class it generates, and this code could call back on the policy to resolve the dispids to names. This policy code could sniff the properties written to the generated class, or if they don't exist, just do what is done now. Note that I do *not* think we can pass a keywords arg dict, as that will defeat attempts to treat such as args as a byref. Or am I missing something regarding getting the ITypeInfo from the object? ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2007-08-28 06:57 Message: Logged In: YES user_id=771074 Originator: NO As far as I can tell, this fixes the Excel events that pass the named args sequentially. I also tested it out with several different types of events from IE, which uses positional args. However, unless I'm misreading the page on MSDN, the canonical order even for named args is last arg first. Again, that's not a requirement. Even though this patch works for the specific Office events in question, it may break com servers that fire events with the named args in reverse order, which would currently be called correctly. The only way I can see to make sure the args are passed correctly in all cases is to do a reverse mapping from the DISPID's to the names. This would require that the object have type info, but we already require that for DispatchWithEvents. A basic outline might look something like this: If named args are passed, use GetTypeInfo to retrieve the server's type info Use ITypeInfo->GetNames for the invoked member id, which returns the names in the order in which they're to be passed to the python method. Call GetIDsOfNames with the above names to retrieve their DISPID's in the same order Loop over DISPID's for the named args, and use the order of the DISPID's returned from above to build the arg tuple in the order the names are returned Alternately, we could use keywords as you suggested and build an arg tuple and dict to be passed to the python implementation of the method. On return, use the ordered DISPID's to determine which VT_BYREF params receive the values returned from python. This looks to be fairly expensive in terms of processing time, but apparently named args aren't frequently used so there shouldn't be too much of a performance hit in the general case. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2007-08-27 18:13 Message: Logged In: YES user_id=14198 Originator: NO Thanks Roger - nice work tracking that down :) That is pretty nasty :( A proper fix isn't trivial either as there is no obvious way to map the dispid to the name in this code. We'd probably end up needing to have makepy include this param information and have our code call back into our policy to resolve things. Its harder given the way we return BYREF params (ie, its not as simple as leaning on Python's keyword capabilities) In the short term, I think the existing checks can remain - their intent is kinda reasonable even if they are wrong :) We should then unpack the named params in the reverse order. This would then work for people who set their params up the "recommended"[1] way - and this is what Office seems to do, as per these examples. I've attached the start of a patch which appears to fixup the main issue, but still fails to handle "out" params correctly (but the test suite changes pick that up) - it might be a few days before I can look at this again. In the meantime, if you (Roger) can find the time to review the patch I'd appreciate it, and it seems somewhat strange that the args *passed* are reversed in the 'named' case, but the test suite changes appear to match both the docs and the description in that MS article. [1] http://msdn2.microsoft.com/en-us/library/ms221653.aspx File Added: bug-1648655.patch ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2007-08-26 12:33 Message: Logged In: YES user_id=771074 Originator: NO I think the problem is that the args wind up backwards when they're passed as named args. For a different event with 3 parms: def OnSheetBeforeDoubleClick(self, Sh, Target, Cancel): print Sh, Target, Cancel return False This prints False None <win32com.gen_py.Microsoft Excel 9.0 Object Library._Worksheet instance at 0x21747576> The first arg Sh should be the worksheet, but I get a boolean as the first parm, and the worksheet ends up as the 3rd arg. >From stepping through in the debugger, both of these events are passing named parms. The code that creates the arg tuple to pass to the event method isn't doing any mapping between names and DISPID's. It only verifies that the named params are in sequential order (which they are not actually required to be). However, it then goes on to process the named args in reverse order just as if they were positional args. ---------------------------------------------------------------------- Comment By: atsuo ishimoto (ishimoto) Date: 2007-07-28 22:35 Message: Logged In: YES user_id=463672 Originator: YES Thank you for comment. But same script with VB.NET, correct values are passed with correct order. So, I guess typelib is corrent. Part of VB script follows. Private WithEvents e1 As Excel.Application Private Sub e1_WorkbookBeforeSave(ByVal Wb As Excel.Workbook, ByVal SaveAsUI As Boolean, ByRef Cancel As Boolean) Handles e1.WorkbookBeforeSave MsgBox("SaveAsUI:" + Str(SaveAsUI) + " Cancel:" + Str(Cancel)) End Sub End Class ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2007-07-28 17:17 Message: Logged In: YES user_id=14198 Originator: NO Sorry, but I can't see a bug of ours here. It sounds like the type info Excel gives out is wrong - otherwise I'd expect *all* params to be reversed for all events, and I don't think that is the case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1648655&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2007-09-01 18:14:29
|
Bugs item #1648655, was opened at 2007-01-31 05:09 Message generated for change (Comment added) made by rupole You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1648655&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: atsuo ishimoto (ishimoto) Assigned to: Nobody/Anonymous (nobody) Summary: Wrong args order with event handler Initial Comment: Order of args doesn't match with prototype generated by makepy. To reproduce, please run script below and Save workbook on the Excel. # <<<<<< BEGIN >>>>>> import win32com.client class WorkbookEvent: def OnBeforeSave(self, SaveAsUI, Cancel): print "OnBeforeSave", SaveAsUI, Cancel return False xl = win32com.client.Dispatch("Excel.Application") xl.Visible = 1 wb = DispatchWithEvents(xl.Workbooks.Add(), WorkbookEvent) while 1: pythoncom.PumpWaitingMessages() # <<<<<< END >>>>>> When I save workbook, WorkbookEvent.OnBeforeSave called with SaveAsUI=False and Cancel=False. But on SaveAs, args passed are SaveAsUI=False and Cancel=True, which should be SaveAsUI=True and Cancel=False. Python2.4.3,pywin32-210,MS-Excel 2000 ---------------------------------------------------------------------- >Comment By: Roger Upole (rupole) Date: 2007-09-01 13:14 Message: Logged In: YES user_id=771074 Originator: NO This works for all the cases I've tried. A couple of things that might be nice to do while we're into the code: Log the exception in invoke_setup instead of just clearing it In invoke_finish, log a warning if it doesn't receive the expected number of output parms. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2007-08-30 03:28 Message: Logged In: YES user_id=14198 Originator: NO I think this should work OK. The out params seem harder than they should be, but after a few false starts, this is the best I can come up with. The cost for no named params should be low. Let me know what you think... File Added: bug-1648655.patch ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2007-08-29 01:32 Message: Logged In: YES user_id=771074 Originator: NO I don't see anything in the docs to indicate that the sequential order of DISPIDs can't be depended upon. One thing we'd have to be careful of is missing args. I guess the tuple could be created with the max of the DISPIDs, and we could insert an ArgNotFound object for any args not passed. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2007-08-28 23:07 Message: Logged In: YES user_id=14198 Originator: NO Actually, I think there might be an easier way. The docs for ITypeInfo::GetIDsOfNames says "The IDs of parameters are 0 for the first parameter in the member function's argument list, 1 for the second, and so on" and I'm not aware of a way to override that in the IDL. So the point of GetIDsOfNames is when you do *not* know about the params - all you know is the names of params presented to you. If you pass the entire set of param names to GetIDsOfNames, you'd always get back an array from 0->n. So for our purposes, this is enough information - we can just treat the dispID as an offset into our arg tuple. Creating the tuple etc becomes a little more complicated, but thats OK, especially if we optimize the 'no named params' case. does that make sense? ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2007-08-28 22:33 Message: Logged In: YES user_id=771074 Originator: NO >From playing around inside the python event code, it looks like the type info may be available in a roundabout way: ti=self._oleobj_.GetTypeInfo(0) The returned type info is for the WorkBook itself, but the event source type info should be locatable from there (I think). The gateway object stashes away a reference to the class instance that's passed as self to the event methods in _obj_. Inside PyGatewayBase::Invoke, you can get the object that provides the type info like this: PyObject *_obj_, *_oleobj_; _obj_=PyObject_GetAttrString(this->m_pPyObject, "_obj_"); if (_obj_) _oleobj_=PyObject_GetAttrString(_obj_, "_oleobj_"); That's as far as I've got for right now. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2007-08-27 17:17 Message: Logged In: YES user_id=14198 Originator: NO Yeah, I'm a little confused about that page - but it seems pretty obvious that every Excel related call we receive does indeed have index[0] of the named items being a dispid of zero, and that this corresponds to the first arg. I understand that this isn't guaranteed though (and yeah, it is apparently not even what is recommended according to that page.) I don't think we can use GetTypeInfo() in the way you suggest. Consider this Excel example - we don't have a pointer to an Excel object, only one of our objects that implements an interface defined by Excel. I'm not sure how the PyGatewayBase code at that point could determine the dispids as defined in the excel typelib. The only way I can see it working is to have makepy include info in the class it generates, and this code could call back on the policy to resolve the dispids to names. This policy code could sniff the properties written to the generated class, or if they don't exist, just do what is done now. Note that I do *not* think we can pass a keywords arg dict, as that will defeat attempts to treat such as args as a byref. Or am I missing something regarding getting the ITypeInfo from the object? ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2007-08-27 15:57 Message: Logged In: YES user_id=771074 Originator: NO As far as I can tell, this fixes the Excel events that pass the named args sequentially. I also tested it out with several different types of events from IE, which uses positional args. However, unless I'm misreading the page on MSDN, the canonical order even for named args is last arg first. Again, that's not a requirement. Even though this patch works for the specific Office events in question, it may break com servers that fire events with the named args in reverse order, which would currently be called correctly. The only way I can see to make sure the args are passed correctly in all cases is to do a reverse mapping from the DISPID's to the names. This would require that the object have type info, but we already require that for DispatchWithEvents. A basic outline might look something like this: If named args are passed, use GetTypeInfo to retrieve the server's type info Use ITypeInfo->GetNames for the invoked member id, which returns the names in the order in which they're to be passed to the python method. Call GetIDsOfNames with the above names to retrieve their DISPID's in the same order Loop over DISPID's for the named args, and use the order of the DISPID's returned from above to build the arg tuple in the order the names are returned Alternately, we could use keywords as you suggested and build an arg tuple and dict to be passed to the python implementation of the method. On return, use the ordered DISPID's to determine which VT_BYREF params receive the values returned from python. This looks to be fairly expensive in terms of processing time, but apparently named args aren't frequently used so there shouldn't be too much of a performance hit in the general case. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2007-08-27 03:13 Message: Logged In: YES user_id=14198 Originator: NO Thanks Roger - nice work tracking that down :) That is pretty nasty :( A proper fix isn't trivial either as there is no obvious way to map the dispid to the name in this code. We'd probably end up needing to have makepy include this param information and have our code call back into our policy to resolve things. Its harder given the way we return BYREF params (ie, its not as simple as leaning on Python's keyword capabilities) In the short term, I think the existing checks can remain - their intent is kinda reasonable even if they are wrong :) We should then unpack the named params in the reverse order. This would then work for people who set their params up the "recommended"[1] way - and this is what Office seems to do, as per these examples. I've attached the start of a patch which appears to fixup the main issue, but still fails to handle "out" params correctly (but the test suite changes pick that up) - it might be a few days before I can look at this again. In the meantime, if you (Roger) can find the time to review the patch I'd appreciate it, and it seems somewhat strange that the args *passed* are reversed in the 'named' case, but the test suite changes appear to match both the docs and the description in that MS article. [1] http://msdn2.microsoft.com/en-us/library/ms221653.aspx File Added: bug-1648655.patch ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2007-08-25 21:33 Message: Logged In: YES user_id=771074 Originator: NO I think the problem is that the args wind up backwards when they're passed as named args. For a different event with 3 parms: def OnSheetBeforeDoubleClick(self, Sh, Target, Cancel): print Sh, Target, Cancel return False This prints False None <win32com.gen_py.Microsoft Excel 9.0 Object Library._Worksheet instance at 0x21747576> The first arg Sh should be the worksheet, but I get a boolean as the first parm, and the worksheet ends up as the 3rd arg. >From stepping through in the debugger, both of these events are passing named parms. The code that creates the arg tuple to pass to the event method isn't doing any mapping between names and DISPID's. It only verifies that the named params are in sequential order (which they are not actually required to be). However, it then goes on to process the named args in reverse order just as if they were positional args. ---------------------------------------------------------------------- Comment By: atsuo ishimoto (ishimoto) Date: 2007-07-28 07:35 Message: Logged In: YES user_id=463672 Originator: YES Thank you for comment. But same script with VB.NET, correct values are passed with correct order. So, I guess typelib is corrent. Part of VB script follows. Private WithEvents e1 As Excel.Application Private Sub e1_WorkbookBeforeSave(ByVal Wb As Excel.Workbook, ByVal SaveAsUI As Boolean, ByRef Cancel As Boolean) Handles e1.WorkbookBeforeSave MsgBox("SaveAsUI:" + Str(SaveAsUI) + " Cancel:" + Str(Cancel)) End Sub End Class ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2007-07-28 02:17 Message: Logged In: YES user_id=14198 Originator: NO Sorry, but I can't see a bug of ours here. It sounds like the type info Excel gives out is wrong - otherwise I'd expect *all* params to be reversed for all events, and I don't think that is the case. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1648655&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2007-08-30 12:12:46
|
Bugs item #1784777, was opened at 2007-08-30 14:12 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=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: Nobody/Anonymous (nobody) 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1784777&group_id=78018 |
2 messages has been excluded from this view by a project administrator.
