pywin32-bugs Mailing List for Python for Windows Extensions (Page 80)
OLD project page for the Python extensions for Windows
Brought to you by:
mhammond
Menu
▾
▴
pywin32-bugs — Automated tracker notifications (not for bug reports!)
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
(24) |
May
(19) |
Jun
(15) |
Jul
(43) |
Aug
(39) |
Sep
(25) |
Oct
(43) |
Nov
(19) |
Dec
(4) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(21) |
Feb
(18) |
Mar
(14) |
Apr
(80) |
May
(56) |
Jun
(24) |
Jul
(30) |
Aug
(17) |
Sep
(36) |
Oct
(106) |
Nov
(38) |
Dec
(30) |
| 2005 |
Jan
(14) |
Feb
(14) |
Mar
(48) |
Apr
(28) |
May
(49) |
Jun
(23) |
Jul
(9) |
Aug
(13) |
Sep
(28) |
Oct
(21) |
Nov
(8) |
Dec
(26) |
| 2006 |
Jan
(56) |
Feb
(33) |
Mar
(33) |
Apr
(18) |
May
(16) |
Jun
(9) |
Jul
(24) |
Aug
(16) |
Sep
(14) |
Oct
(37) |
Nov
(38) |
Dec
(22) |
| 2007 |
Jan
(7) |
Feb
(16) |
Mar
(11) |
Apr
(15) |
May
(15) |
Jun
(8) |
Jul
(24) |
Aug
(26) |
Sep
(18) |
Oct
(11) |
Nov
(20) |
Dec
(1) |
| 2008 |
Jan
(19) |
Feb
(55) |
Mar
(7) |
Apr
(35) |
May
(66) |
Jun
(38) |
Jul
(26) |
Aug
(5) |
Sep
(25) |
Oct
(25) |
Nov
(18) |
Dec
(18) |
| 2009 |
Jan
(25) |
Feb
(38) |
Mar
(29) |
Apr
(25) |
May
(5) |
Jun
(11) |
Jul
(16) |
Aug
(16) |
Sep
(16) |
Oct
(1) |
Nov
(15) |
Dec
(33) |
| 2010 |
Jan
(13) |
Feb
(11) |
Mar
(1) |
Apr
(24) |
May
(26) |
Jun
(19) |
Jul
(22) |
Aug
(51) |
Sep
(38) |
Oct
(39) |
Nov
(25) |
Dec
(27) |
| 2011 |
Jan
(40) |
Feb
(31) |
Mar
(21) |
Apr
(42) |
May
(11) |
Jun
(16) |
Jul
(20) |
Aug
(14) |
Sep
(6) |
Oct
(8) |
Nov
(34) |
Dec
(7) |
| 2012 |
Jan
(60) |
Feb
(24) |
Mar
(6) |
Apr
(28) |
May
(41) |
Jun
(15) |
Jul
(14) |
Aug
(25) |
Sep
(30) |
Oct
(18) |
Nov
(30) |
Dec
(9) |
| 2013 |
Jan
(3) |
Feb
(8) |
Mar
(17) |
Apr
(23) |
May
(34) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
|
From: SourceForge.net <no...@so...> - 2006-01-10 04:37:41
|
Patches item #1043733, was opened at 2004-10-10 07:36 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1043733&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 Submitted By: Adal Chiriliuc (adalx) Assigned to: Nobody/Anonymous (nobody) Summary: Added message map ranges support to CmdTarget Initial Comment: Added HookCommandRange, HookCommandUpdateRange and HookNotifyRange to CmdTarget. They have no documentation since AutoDuck doesn't parse .py files. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2006-01-10 15:37 Message: Logged In: YES user_id=14198 Checking in pythonwin/pywin/mfc/object.py; new revision: 1.3; previous revision: 1.2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1043733&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-01-10 04:35:45
|
Patches item #1043732, was opened at 2004-10-10 07:35 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1043732&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 Submitted By: Adal Chiriliuc (adalx) Assigned to: Nobody/Anonymous (nobody) Summary: New win32con constants and a bug fix Initial Comment: Added some new constants. BUG: Fixed GetRValue, GetGValue and GetBValue. They didn't clip the return value to 8 bit integers. GetRValue(0xffffff) returned 0xffffff. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2006-01-10 15:35 Message: Logged In: YES user_id=14198 Checking in win32con.py; new revision: 1.14; previous revision: 1.13 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1043732&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-01-10 04:30:05
|
Patches item #1043731, was opened at 2004-10-10 07:32 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1043731&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 Submitted By: Adal Chiriliuc (adalx) Assigned to: Nobody/Anonymous (nobody) Summary: New mmsystem.py constants Initial Comment: Added WAVE_MAPPER and WAVE_FORMAT_IEEE_FLOAT constants to mmsystem.py. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2006-01-10 15:30 Message: Logged In: YES user_id=14198 Checking in win32/Lib/mmsystem.py; new revision: 1.2; previous revision: 1.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1043731&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-01-10 04:29:02
|
Patches item #1043730, was opened at 2004-10-10 07:28 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1043730&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 Submitted By: Adal Chiriliuc (adalx) Assigned to: Nobody/Anonymous (nobody) Summary: New afxres.py constants Initial Comment: Added CBRS_GRIPPER, SBPS_NORMAL, SBPS_NOBORDERS, SBPS_POPOUT, SBPS_OWNERDRAW, SBPS_DISABLED and SBPS_STRETCH to afxres.py. There are two afxres.py files. One in "win32\Lib" and one in "Pythonwin\pywin\mfc". The first of these contained the above constants, the other did not. Fixed that. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2006-01-10 15:28 Message: Logged In: YES user_id=14198 Checking in pythonwin/pywin/mfc/afxres.py; new revision: 1.2; previous revision: 1.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1043730&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-01-10 04:26:48
|
Patches item #1043740, was opened at 2004-10-10 07:43 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1043740&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 Submitted By: Adal Chiriliuc (adalx) Assigned to: Nobody/Anonymous (nobody) Summary: Added PyCWnd.OnTimer virtual handler Initial Comment: Added PyCWnd.OnTimer virtual handler so that the Python WM_TIMER handler will be called even if a modal dialog box is displayed. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2006-01-10 15:26 Message: Logged In: YES user_id=14198 Thanks! Checking in win32uiExt.h; new revision: 1.7; previous revision: 1.6 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1043740&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-01-10 04:20:46
|
Patches item #1195096, was opened at 2005-05-04 20:19 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1195096&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stefan Schukat (sschukat) Assigned to: Mark Hammond (mhammond) Summary: Native access to SAFEARRAY with wrapper class Initial Comment: The conversion to/from SAFEARRAYs to tuples takes up a lot of time if the SAFEARRAYs are really big. Therefore I created a wrapper class which does not copy any data and just wraps the access to the underlying SAFEARRAY data. In addition to the performance improvements thes classes could be created for specific dimensions and data types if the automatic calculation of the dimension does not work or a specific data type is requested by the COM server. The new object does support, comparision, sequence protocol, printing and representation. The changed files a test client and script are attached. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2006-01-10 15:20 Message: Logged In: YES user_id=14198 I like the idea of this, but I'm not that happy with the global used to change the behaviour. My main concern is for an application using one lib that wants SafeArrays, and the other wanting tuples, and no clear answer about who is "correct" I assume that the new SafeArray type will operate exactly like a tuple in every way - but that the "type()" will obviously be different - so that the vast majority of programs will see no change. I'd prefer an approach like I am taking for the "Decimal" objects. Specifically: * create a pythoncom.__future_safearray_ flag - default is False, but ppl can set it to true to get the new behaviour (globally) now. * A few/many builds in the future, we start issuing deprecation warnings whenever SafeArrays are used without this flag being set. * A few/many builds after that the new behaviour becomes the default. Would that work for you? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-10-24 09:32 Message: Logged In: YES user_id=14198 Sorry for the delay here - I'll check this out after I release the next pywin32 build - in the next few days. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1195096&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-01-10 04:07:10
|
Patches item #1064568, was opened at 2004-11-12 02:51 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1064568&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 Submitted By: Stefan Schukat (sschukat) Assigned to: Nobody/Anonymous (nobody) Summary: Added GlobalInterface Table and more Safearray Variant Types Initial Comment: Until now only IStream marshalling was supported by pythoncom. This is not sufficient for all marshalling tasks. Therefore I patched the pythoncom DLL which allows now to create a Global Interface Table Object and access the IGlobalInterfaceTable interface. Secondly some VARIANT types where missing in the SafeArray support. This list was now extended. The new and changed files and a GIT test are attached. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2006-01-10 15:07 Message: Logged In: YES user_id=14198 Very sorry about the delay in getting to this. The SafeArray ones are out of date, but I have checked in the GIT ones (without pythoncom.CreateGIT() - see testGIT for how this should be done. However, I'm a little unsure about the change in oleargs.cpp: else { // Just an empty list so increase Dimension lReturnDimension += 1; } Is a test case possible for this? Thanks, Mark ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1064568&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-01-10 03:45:11
|
Patches item #1377153, was opened at 2005-12-10 01:26 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1377153&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 Submitted By: Luke Dunstan (infidel) Assigned to: Nobody/Anonymous (nobody) Summary: Improved Windows CE support Initial Comment: Some changes to allow pywintypes, win32gui, win32event and win32process to compile for Windows CE. Tested with MS eMbedded Visual C++ 4.0 with the Pocket PC 2003 SDK. This is still a work in progress. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2006-01-10 14:45 Message: Logged In: YES user_id=14198 All checked in - thanks! ---------------------------------------------------------------------- Comment By: Luke Dunstan (infidel) Date: 2005-12-16 02:48 Message: Logged In: YES user_id=30442 Probably not soon. I have a set of makefiles for building the parts of pywin32 I mentioned for WinCE (using MS eVC 4): would that be appropriate for submission? They are based on makefiles from the PythonCE project because pywin32 is distributed with it. I hope to eventually look at modifying distutils to eliminate the need for these makefiles but I have no idea how hard that will be. Failing that I would try writing a Python script (from scratch) to do it. I also created a small module wince.pyd containing a bunch of WinCE-specific functions (actually mostly Pocket PC- specific I think), but now that I have also finished porting ctypes to ARM-WinCE that module may be less necessary. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-12-14 08:49 Message: Logged In: YES user_id=14198 Thanks for that. When you submitted the patch, you mentioned "This is still a work in progress." Do you think you will have an update any time soon? ---------------------------------------------------------------------- Comment By: Luke Dunstan (infidel) Date: 2005-12-14 00:43 Message: Logged In: YES user_id=30442 Yes, I tried to explain but not clearly enough. That particular #ifdef is incorrect, it should be like: #ifndef MS_WINCE if (index==-1) { nicons = (int)ExtractIconEx(fname, index, NULL, NULL, 0); PyWinObject_FreeTCHAR(fname); return PyInt_FromLong(nicons); } #endif because -1 does not have this special meaning. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-12-13 08:39 Message: Logged In: YES user_id=14198 I'm still not quite with you on the handling of the "-1, NULL, NULL" case. I agree that the docs are not particularly clear, but I see nothing in the docs that means you should force the result to 1 in that case - the way I read it, your code will *always* return 1 in the "-1, NULL, NULL" case, regardless of what Windows actually returned. Further, the comment appears incorrect - if the API actually returns a HICON but your implementation always returns 1, then presumably the hicon returned has been lost? +#ifdef MS_WINCE + /* On WinCE >= 2.1 the API actually returns a HICON */ + nicons = 1; +#endif + PyWinObject_FreeTCHAR(fname); return PyInt_FromLong(nicons); ---------------------------------------------------------------------- Comment By: Luke Dunstan (infidel) Date: 2005-12-13 02:19 Message: Logged In: YES user_id=30442 * You are correct about the format string * Regarding the return value: "For Windows CE versions 2.10 and later, this function returns the handle to an icon. If both phiconLarge and phiconSmall are not NULL, the return value defaults to the large icon. For Windows CE versions 1.0 through 2.01, this function returns a UINT data type. If the nIconIndex parameter is â 1, the phiconLarge parameter is NULL, and the phiconSmall parameter is NULL, then the return value is the number of icons contained in the specified file. Otherwise, the return value is the number of icons successfully extracted from the file." My reading is that the whole of the second paragraph only applies to WinCE <= 2.01. The earlier description of nIconIndex supports this: "For Windows CE versions 2.10 and later, the nIconIndex parameter must be zero or âN, where N is a specified resource identifier." This implies that -1 means "the resource ID 1" for WinCE >= 2.10. This probably also means that my patch should have excluded the whole if(index==-1) { ... } block for MS_WINCE. Also, it would not make much sense to return the number of icons since nIcons must be 1. In theory we could use #if to check the WinCE version but I prefer to leave that to someone who actually develops for old versions of WinCE. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-12-12 16:15 Message: Logged In: YES user_id=14198 This looks quite good - thanks! A few questions about ExtractIconEx: * It appears first char of the format string passed to PyArg_ParseTuple should be changed from "s" to "O"? * The block: if (index==-1) { nicons = (int)ExtractIconEx(fname, index, NULL, NULL, 0); #ifdef MS_WINCE /* On WinCE >= 2.1 the API actually returns a HICON */ nicons = 1; #endif Isn't clear to me. My reading of the MSDN documentation for CE says that the (-1, NULL, NULL case does correctly return the number of icons in the DLL. Can you please clarify? Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1377153&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-01-09 19:13:44
|
Bugs item #1400633, was opened at 2006-01-09 19:13 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=1400633&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 Submitted By: Greg Hazel (ghazel) Assigned to: Nobody/Anonymous (nobody) Summary: GetVersionEx does not return everything Initial Comment: win32api.GetVersionEx() returns: (5, 1, 2600, 2, 'Service Pack 2') when it should return: (5, 1, 2600, 2, 'Service Pack 2', 2, 0, 256, 1, 0) sys.getwindowsversion() returns the short version as well, so I was hoping to use win32api to retrieve more detailed information. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1400633&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-01-06 18:47:18
|
Bugs item #1398756, was opened at 2006-01-06 18:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1398756&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 Submitted By: Greg Hazel (ghazel) Assigned to: Nobody/Anonymous (nobody) Summary: ReadFile returns trash when using overlapped io on namedpipe Initial Comment: This bug demonstration probably looks familiar if you read svcbug.py - however it is a different bug. win32file.ReadFile seems to be returning as much data as is requested (only when using overlapped io) even if that much data is not actually available. The extra data is random trash. This same operation in C does not act this way. running "ovbug.py s" starts a correct server and "ovbug.py s bug" starts a buggy server. running "ovbug.py c" starts a client You'll also notice that PeekNamedPipe seems to indicate the correct situation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1398756&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-01-05 17:47:48
|
Feature Requests item #1397932, was opened at 2006-01-05 17:47 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=1397932&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Markus Klinik (brudermarkus) Assigned to: Nobody/Anonymous (nobody) Summary: SHFileOperation - support sequence of names Initial Comment: Actually, replace the line PyErr_Format(PyExc_RuntimeError, "Sequences of names not yet supported"); in com/win32comext/shell/src/shell.cpp with useful code. :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1397932&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-01-02 22:20:22
|
Bugs item #1392316, was opened at 2005-12-29 09:09 Message generated for change (Settings changed) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1392316&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pythonwin Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Radek Svarz (allitaice) Assigned to: Nobody/Anonymous (nobody) Summary: win32timezone.GetLocalTimeZone cannot find timezone Initial Comment: Realized on Python 2.4.2 pywin32 205 Winxp Pro Czech GetLocalTimeZone( ) uses StandardName in this key: SYSTEM\CurrentControlSet\Control\TimeZoneInformation this StandardName in the registry is a text string of the local translated name of the local time zone (eg. for the Czech Republic it is "Stredni Evropa (bezny cas)" However keys used in TimeZoneInfo.__init__: SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\* are written in English (even on other than English Win XP installations) (eg. for the Czech Republic it is: SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\Central Europe Standard Time) Therefore you cannot perform the lookup like this on non-English Winxp systems. Unfortunately there is no item in TimeZoneInformation key, that would state the English name of the time zone. FYI the item Std in Time Zones\Central Europe Standard Time states the same string as the item StandardName in TimeZoneInformation. You should perform lookup using that. Radek ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2006-01-03 09:20 Message: Logged In: YES user_id=14198 Fixed in a patch from Jason: Checking in win32timezone.py; new revision: 1.5; previous revision: 1.4 Will be in the next pywin32 build. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1392316&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-12-28 22:09:28
|
Bugs item #1392316, was opened at 2005-12-28 23:09 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=1392316&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pythonwin Group: None Status: Open Resolution: None Priority: 5 Submitted By: Radek Svarz (allitaice) Assigned to: Nobody/Anonymous (nobody) Summary: win32timezone.GetLocalTimeZone cannot find timezone Initial Comment: Realized on Python 2.4.2 pywin32 205 Winxp Pro Czech GetLocalTimeZone( ) uses StandardName in this key: SYSTEM\CurrentControlSet\Control\TimeZoneInformation this StandardName in the registry is a text string of the local translated name of the local time zone (eg. for the Czech Republic it is "Stredni Evropa (bezny cas)" However keys used in TimeZoneInfo.__init__: SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\* are written in English (even on other than English Win XP installations) (eg. for the Czech Republic it is: SOFTWARE\Microsoft\Windows NT\CurrentVersion\Time Zones\Central Europe Standard Time) Therefore you cannot perform the lookup like this on non-English Winxp systems. Unfortunately there is no item in TimeZoneInformation key, that would state the English name of the time zone. FYI the item Std in Time Zones\Central Europe Standard Time states the same string as the item StandardName in TimeZoneInformation. You should perform lookup using that. Radek ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1392316&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-12-21 07:44:31
|
Bugs item #1376001, was opened at 2005-12-08 09:26 Message generated for change (Comment added) made by mcvgmatthews You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1376001&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pythonwin Group: None Status: Open Resolution: None Priority: 8 Submitted By: O.R.Senthil Kumaran (orsenthil) Assigned to: Nobody/Anonymous (nobody) Summary: Build 205 pythonwin.exe crashes on Win2k3 Initial Comment: As soon the installation is completed on Windows 2003 Operating System.Starting the pythonwin IDE,the pythonwin32.exe crashes with the message: Pythonwin:Pythonwin.exe - Application Error The instruction of "0x00c25fa4" referenced memory at "0x00c25fa4". The Memory could not be written. ---------------------------------------------------------------------- Comment By: Morena Chris Matthews (mcvgmatthews) Date: 2005-12-21 09:44 Message: Logged In: YES user_id=1408439 It is the Data Execution Prevention (DEP)that cause the crash. See "How can I tell if DEP is available on my computer?" below. I selected "DEP for all programs and services except those I select" and then ticked Pythonwin. For good measure I ticked Windows Installer, and reinstalled Python 2.3.5 + Pythonwin 205, Python 2.4.2 + Pythonwin 205. I deleted the old Pythonwin entries and added the newly installed ones. And Voila! Pythonwin works again. The one help I found was: Data Execution Prevention (DEP) helps prevent damage from viruses and other security threats that attack by running (executing) malicious code from memory locations that only Windows and other programs should use. This type of threat causes damage by taking over one or more memory locations in use by a program. Then it spreads and harms other programs, files, and even your e-mail contacts. Unlike a firewall or antivirus program, DEP does not help prevent harmful programs from being installed on your computer. Instead, it monitors your programs to determine if they use system memory safely. To do this, DEP software works alone or with compatible microprocessors to mark some memory locations as "non-executable." If a program tries to run codeâmalicious or notâfrom a protected location, DEP closes the program and notifies you. DEP can take advantage of software and hardware support. To use DEP, your computer must be running Microsoft Windows XP with Service Pack 2 (SP2), Microsoft Windows Server 2003 with Service Pack 1 (SP1), or an x64-based version of a Windows Server 2003 or Windows XP operating system. DEP software alone helps protect against certain types of malicious code attacks but to take full advantage of the protection that DEP can offer, your processor must support "execution protection." This is a hardware-based technology designed to mark memory locations as non-executable. If your processor does not support hardware-based DEP, it's a good idea to upgrade to a processor that offers execution protection features. Is it safe to run a program again if DEP has closed it? Yes, but only if you leave DEP turned on for that program. Windows can continue to detect attempts to execute code from protected memory locations and help prevent attacks. In cases where a program does not run correctly with DEP turned on, you can reduce security risks by getting a DEP-compatible version of the program from the software publisher. For more information about what to do after DEP closes a program, click Related Topics. How can I tell if DEP is available on my computer? 1. To open System Properties, click Start, click Control Panel, and then double-click System. 2. Click the Advanced tab and, under Performance, click Settings. 3. Click the Data Execution Prevention tab. Note ⢠By default, DEP is only turned on for essential Windows operating system programs and services. To help protect more programs with DEP, select Turn on DEP for all programs and services except those I select. ---------------------------------------------------------------------- Comment By: Morena Chris Matthews (mcvgmatthews) Date: 2005-12-20 09:18 Message: Logged In: YES user_id=1408439 Not sure if this may help. Some crash information. python 2.4.2 Faulting application Pythonwin.exe, version 2.4.205.0, faulting module unknown, version 0.0.0.0, fault address 0x00ac1514. Running it again crash consistently at: Faulting application Pythonwin.exe, version 2.4.205.0, faulting module unknown, version 0.0.0.0, fault address 0x00ab816c. I run: Microsoft(R) Windows(R) Server 2003, Standard Edition 5.2.3790 Service Pack 1 Build 3790 and the following MFC's were loaded: version 6.6.8063.0 <Data> <Name><![CDATA[mfc42]]> <Version><![CDATA[6.06.8063.0]]> <Size><![CDATA[1.11 MB (1,160,704 bytes)]]> <File_Date><![CDATA[2005/11/16 09:52 AM]]> <Manufacturer><![CDATA[Microsoft Corporation]]> <Path><![CDATA[c:\windows\system32\mfc42.dll]]> version 6.6.8063.0 <Data> <Name><![CDATA[mfc42u]]> <Version><![CDATA[6.06.8063.0]]> <Size><![CDATA[1.11 MB (1,163,776 bytes)]]> <File_Date><![CDATA[2005/11/16 09:52 AM]]> <Manufacturer><![CDATA[Microsoft Corporation]]> <Path><![CDATA[c:\windows\system32\mfc42u.dll]]> version 7.10.3077.0 <Data> <Name><![CDATA[mfc71]]> <Version><![CDATA[7.10.3077.0]]> <Size><![CDATA[1.01 MB (1,060,864 bytes)]]> <File_Date><![CDATA[2003/03/19 07:19 AM]]> <Manufacturer><![CDATA[Microsoft Corporation]]> <Path><![CDATA[c:\windows\system32\mfc71.dll]]> version 7.10.3077.0 <Data> <Name><![CDATA[mfc71enu]]> <Version><![CDATA[7.10.3077.0]]> <Size><![CDATA[56.00 KB (57,344 bytes)]]> <File_Date><![CDATA[2003/03/19 06:44 AM]]> <Manufacturer><![CDATA[Microsoft Corporation]]> <Path><![CDATA[c:\windows\system32\mfc71enu.dll]]> 00AB8166 add byte ptr [eax],al 00AB8168 or al,byte ptr [eax] 00AB816A add byte ptr [eax],al 00AB816C pop eax 00AB816D push 0AB8118h 00AB8172 push eax 00AB8173 push 1E504C10h 00AB8178 ret Stack: 00ab816c() user32.dll!77387050() user32.dll!77387dc3() user32.dll!77387101() user32.dll!7738e3f0() user32.dll!7739c3b7() user32.dll!7739c484() user32.dll!7739c43a() user32.dll!7739c73c() user32.dll!7738e406() > MFC71.dll!AfxInternalPumpMessage() Line 188 C++ MFC71.dll!CWinThread::Run() Line 637 + 0x7 C++ win32ui.pyd!1e2b62a7() Pythonwin.exe!004015cc() MFC71.dll!AfxWinMain(HINSTANCE__ * hInstance=0x00400000, HINSTANCE__ * hPrevInstance=0x00000000, char * lpCmdLine=0x00142545, int nCmdShow=10) Line 49 + 0x7 C++ Pythonwin.exe!004019f1() kernel32.dll!77e523cd() Last source code window: AfxInternalPumpMessage(void) file thrdcore.cpp line 181-189 181: // process this message 182: 183: if (pState->m_msgCur.message != WM_KICKIDLE && !AfxPreTranslateMessage(&(pState->m_msgCur))) 7C169054 cmp dword ptr [edi+34h],36Ah 7C16905B je AfxInternalPumpMessage+3Eh (7C169076h) 7C16905D push esi 7C16905E call AfxPreTranslateMessage (7C169121h) 7C169063 test eax,eax 7C169065 pop ecx 7C169066 jne AfxInternalPumpMessage+3Eh (7C169076h) 184: { 185: ::TranslateMessage(&(pState->m_msgCur)); 7C169068 push esi 7C169069 call dword ptr [__imp__TranslateMessage@4 (7C141728h)] 186: ::DispatchMessage(&(pState->m_msgCur)); 7C16906F push esi 7C169070 call dword ptr [__imp__DispatchMessageA@4 (7C14166Ch)] 187: } 188: return TRUE; >>Instruction cursor>>7C169076 xor eax,eax 7C169078 inc eax 7C169079 pop edi 7C16907A pop esi 189: } 7C16907B ret Registers: EAX = 00000000 EBX = 773E20E0 ECX = 000080A2 EDX = 0014B678 ESI = 0012FCF8 EDI = 7FFDF6CC EIP = 00AB816C ESP = 0012FCD4 EBP = 0012FD04 EFL = 00010246 ---------------------------------------------------------------------- Comment By: Morena Chris Matthews (mcvgmatthews) Date: 2005-12-19 18:09 Message: Logged In: YES user_id=1408439 I also get the error on Win2003 Server. I upgraded to 205, because of a __setitem__ problem of the COMObject. Thereafter I have been experiencing the problem. Now the strange thing is that it crashes regardless of the python and Pythonwin version (I have installed and re-installed and booted, etc.). I also deinstalled my python 2.4. python 2.3.5 build 205 Faulting application Pythonwin.exe, version 2.3.205.0, faulting module unknown, version 0.0.0.0, fault address 0x00bfdb04. python 2.3.5 build 204 Faulting application Pythonwin.exe, version 0.0.0.0, faulting module unknown, version 0.0.0.0, fault address 0x00c1db04. Downgrade to: python 2.3 build 203 Faulting application Pythonwin.exe, version 0.0.0.0, faulting module unknown, version 0.0.0.0, fault address 0x00c36f0c. python 2.3 build 204 Faulting application Pythonwin.exe, version 0.0.0.0, faulting module unknown, version 0.0.0.0, fault address 0x00c36f0c. python 2.3 build 202 Faulting application Pythonwin.exe, version 0.0.0.0, faulting module unknown, version 0.0.0.0, fault address 0x00c36f0c. Upgrade to: python 2.3.5 build 202 Faulting application Pythonwin.exe, version 0.0.0.0, faulting module unknown, version 0.0.0.0, fault address 0x00c68d4c. Upgrade to: python 2.4.1 build 205 Faulting application Pythonwin.exe, version 2.4.205.0, faulting module unknown, version 0.0.0.0, fault address 0x00ac1aa4. Upgrade to: python 2.4.2 build 205 Faulting application Pythonwin.exe, version 2.4.205.0, faulting module unknown, version 0.0.0.0, fault address 0x00aecefc. Thereafter it crashed at: Faulting application Pythonwin.exe, version 2.4.205.0, faulting module unknown, version 0.0.0.0, fault address 0x00baebac. Shout if I can provide more info. Thanks ---------------------------------------------------------------------- Comment By: O.R.Senthil Kumaran (orsenthil) Date: 2005-12-08 13:14 Message: Logged In: YES user_id=942711 Am sorry,Mark. -Python 2.4 Build 205. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-12-08 10:22 Message: Logged In: YES user_id=14198 What Python version? ---------------------------------------------------------------------- Comment By: O.R.Senthil Kumaran (orsenthil) Date: 2005-12-08 09:27 Message: Logged In: YES user_id=942711 Please let me know if I need to provide more debugging information. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1376001&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-12-20 07:18:29
|
Bugs item #1376001, was opened at 2005-12-08 09:26 Message generated for change (Comment added) made by mcvgmatthews You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1376001&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pythonwin Group: None Status: Open Resolution: None Priority: 8 Submitted By: O.R.Senthil Kumaran (orsenthil) Assigned to: Nobody/Anonymous (nobody) Summary: Build 205 pythonwin.exe crashes on Win2k3 Initial Comment: As soon the installation is completed on Windows 2003 Operating System.Starting the pythonwin IDE,the pythonwin32.exe crashes with the message: Pythonwin:Pythonwin.exe - Application Error The instruction of "0x00c25fa4" referenced memory at "0x00c25fa4". The Memory could not be written. ---------------------------------------------------------------------- Comment By: Morena Chris Matthews (mcvgmatthews) Date: 2005-12-20 09:18 Message: Logged In: YES user_id=1408439 Not sure if this may help. Some crash information. python 2.4.2 Faulting application Pythonwin.exe, version 2.4.205.0, faulting module unknown, version 0.0.0.0, fault address 0x00ac1514. Running it again crash consistently at: Faulting application Pythonwin.exe, version 2.4.205.0, faulting module unknown, version 0.0.0.0, fault address 0x00ab816c. I run: Microsoft(R) Windows(R) Server 2003, Standard Edition 5.2.3790 Service Pack 1 Build 3790 and the following MFC's were loaded: version 6.6.8063.0 <Data> <Name><![CDATA[mfc42]]> <Version><![CDATA[6.06.8063.0]]> <Size><![CDATA[1.11 MB (1,160,704 bytes)]]> <File_Date><![CDATA[2005/11/16 09:52 AM]]> <Manufacturer><![CDATA[Microsoft Corporation]]> <Path><![CDATA[c:\windows\system32\mfc42.dll]]> version 6.6.8063.0 <Data> <Name><![CDATA[mfc42u]]> <Version><![CDATA[6.06.8063.0]]> <Size><![CDATA[1.11 MB (1,163,776 bytes)]]> <File_Date><![CDATA[2005/11/16 09:52 AM]]> <Manufacturer><![CDATA[Microsoft Corporation]]> <Path><![CDATA[c:\windows\system32\mfc42u.dll]]> version 7.10.3077.0 <Data> <Name><![CDATA[mfc71]]> <Version><![CDATA[7.10.3077.0]]> <Size><![CDATA[1.01 MB (1,060,864 bytes)]]> <File_Date><![CDATA[2003/03/19 07:19 AM]]> <Manufacturer><![CDATA[Microsoft Corporation]]> <Path><![CDATA[c:\windows\system32\mfc71.dll]]> version 7.10.3077.0 <Data> <Name><![CDATA[mfc71enu]]> <Version><![CDATA[7.10.3077.0]]> <Size><![CDATA[56.00 KB (57,344 bytes)]]> <File_Date><![CDATA[2003/03/19 06:44 AM]]> <Manufacturer><![CDATA[Microsoft Corporation]]> <Path><![CDATA[c:\windows\system32\mfc71enu.dll]]> 00AB8166 add byte ptr [eax],al 00AB8168 or al,byte ptr [eax] 00AB816A add byte ptr [eax],al 00AB816C pop eax 00AB816D push 0AB8118h 00AB8172 push eax 00AB8173 push 1E504C10h 00AB8178 ret Stack: 00ab816c() user32.dll!77387050() user32.dll!77387dc3() user32.dll!77387101() user32.dll!7738e3f0() user32.dll!7739c3b7() user32.dll!7739c484() user32.dll!7739c43a() user32.dll!7739c73c() user32.dll!7738e406() > MFC71.dll!AfxInternalPumpMessage() Line 188 C++ MFC71.dll!CWinThread::Run() Line 637 + 0x7 C++ win32ui.pyd!1e2b62a7() Pythonwin.exe!004015cc() MFC71.dll!AfxWinMain(HINSTANCE__ * hInstance=0x00400000, HINSTANCE__ * hPrevInstance=0x00000000, char * lpCmdLine=0x00142545, int nCmdShow=10) Line 49 + 0x7 C++ Pythonwin.exe!004019f1() kernel32.dll!77e523cd() Last source code window: AfxInternalPumpMessage(void) file thrdcore.cpp line 181-189 181: // process this message 182: 183: if (pState->m_msgCur.message != WM_KICKIDLE && !AfxPreTranslateMessage(&(pState->m_msgCur))) 7C169054 cmp dword ptr [edi+34h],36Ah 7C16905B je AfxInternalPumpMessage+3Eh (7C169076h) 7C16905D push esi 7C16905E call AfxPreTranslateMessage (7C169121h) 7C169063 test eax,eax 7C169065 pop ecx 7C169066 jne AfxInternalPumpMessage+3Eh (7C169076h) 184: { 185: ::TranslateMessage(&(pState->m_msgCur)); 7C169068 push esi 7C169069 call dword ptr [__imp__TranslateMessage@4 (7C141728h)] 186: ::DispatchMessage(&(pState->m_msgCur)); 7C16906F push esi 7C169070 call dword ptr [__imp__DispatchMessageA@4 (7C14166Ch)] 187: } 188: return TRUE; >>Instruction cursor>>7C169076 xor eax,eax 7C169078 inc eax 7C169079 pop edi 7C16907A pop esi 189: } 7C16907B ret Registers: EAX = 00000000 EBX = 773E20E0 ECX = 000080A2 EDX = 0014B678 ESI = 0012FCF8 EDI = 7FFDF6CC EIP = 00AB816C ESP = 0012FCD4 EBP = 0012FD04 EFL = 00010246 ---------------------------------------------------------------------- Comment By: Morena Chris Matthews (mcvgmatthews) Date: 2005-12-19 18:09 Message: Logged In: YES user_id=1408439 I also get the error on Win2003 Server. I upgraded to 205, because of a __setitem__ problem of the COMObject. Thereafter I have been experiencing the problem. Now the strange thing is that it crashes regardless of the python and Pythonwin version (I have installed and re-installed and booted, etc.). I also deinstalled my python 2.4. python 2.3.5 build 205 Faulting application Pythonwin.exe, version 2.3.205.0, faulting module unknown, version 0.0.0.0, fault address 0x00bfdb04. python 2.3.5 build 204 Faulting application Pythonwin.exe, version 0.0.0.0, faulting module unknown, version 0.0.0.0, fault address 0x00c1db04. Downgrade to: python 2.3 build 203 Faulting application Pythonwin.exe, version 0.0.0.0, faulting module unknown, version 0.0.0.0, fault address 0x00c36f0c. python 2.3 build 204 Faulting application Pythonwin.exe, version 0.0.0.0, faulting module unknown, version 0.0.0.0, fault address 0x00c36f0c. python 2.3 build 202 Faulting application Pythonwin.exe, version 0.0.0.0, faulting module unknown, version 0.0.0.0, fault address 0x00c36f0c. Upgrade to: python 2.3.5 build 202 Faulting application Pythonwin.exe, version 0.0.0.0, faulting module unknown, version 0.0.0.0, fault address 0x00c68d4c. Upgrade to: python 2.4.1 build 205 Faulting application Pythonwin.exe, version 2.4.205.0, faulting module unknown, version 0.0.0.0, fault address 0x00ac1aa4. Upgrade to: python 2.4.2 build 205 Faulting application Pythonwin.exe, version 2.4.205.0, faulting module unknown, version 0.0.0.0, fault address 0x00aecefc. Thereafter it crashed at: Faulting application Pythonwin.exe, version 2.4.205.0, faulting module unknown, version 0.0.0.0, fault address 0x00baebac. Shout if I can provide more info. Thanks ---------------------------------------------------------------------- Comment By: O.R.Senthil Kumaran (orsenthil) Date: 2005-12-08 13:14 Message: Logged In: YES user_id=942711 Am sorry,Mark. -Python 2.4 Build 205. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-12-08 10:22 Message: Logged In: YES user_id=14198 What Python version? ---------------------------------------------------------------------- Comment By: O.R.Senthil Kumaran (orsenthil) Date: 2005-12-08 09:27 Message: Logged In: YES user_id=942711 Please let me know if I need to provide more debugging information. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1376001&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-12-19 16:09:34
|
Bugs item #1376001, was opened at 2005-12-08 09:26 Message generated for change (Comment added) made by mcvgmatthews You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1376001&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pythonwin Group: None Status: Open Resolution: None Priority: 8 Submitted By: O.R.Senthil Kumaran (orsenthil) Assigned to: Nobody/Anonymous (nobody) Summary: Build 205 pythonwin.exe crashes on Win2k3 Initial Comment: As soon the installation is completed on Windows 2003 Operating System.Starting the pythonwin IDE,the pythonwin32.exe crashes with the message: Pythonwin:Pythonwin.exe - Application Error The instruction of "0x00c25fa4" referenced memory at "0x00c25fa4". The Memory could not be written. ---------------------------------------------------------------------- Comment By: Morena Chris Matthews (mcvgmatthews) Date: 2005-12-19 18:09 Message: Logged In: YES user_id=1408439 I also get the error on Win2003 Server. I upgraded to 205, because of a __setitem__ problem of the COMObject. Thereafter I have been experiencing the problem. Now the strange thing is that it crashes regardless of the python and Pythonwin version (I have installed and re-installed and booted, etc.). I also deinstalled my python 2.4. python 2.3.5 build 205 Faulting application Pythonwin.exe, version 2.3.205.0, faulting module unknown, version 0.0.0.0, fault address 0x00bfdb04. python 2.3.5 build 204 Faulting application Pythonwin.exe, version 0.0.0.0, faulting module unknown, version 0.0.0.0, fault address 0x00c1db04. Downgrade to: python 2.3 build 203 Faulting application Pythonwin.exe, version 0.0.0.0, faulting module unknown, version 0.0.0.0, fault address 0x00c36f0c. python 2.3 build 204 Faulting application Pythonwin.exe, version 0.0.0.0, faulting module unknown, version 0.0.0.0, fault address 0x00c36f0c. python 2.3 build 202 Faulting application Pythonwin.exe, version 0.0.0.0, faulting module unknown, version 0.0.0.0, fault address 0x00c36f0c. Upgrade to: python 2.3.5 build 202 Faulting application Pythonwin.exe, version 0.0.0.0, faulting module unknown, version 0.0.0.0, fault address 0x00c68d4c. Upgrade to: python 2.4.1 build 205 Faulting application Pythonwin.exe, version 2.4.205.0, faulting module unknown, version 0.0.0.0, fault address 0x00ac1aa4. Upgrade to: python 2.4.2 build 205 Faulting application Pythonwin.exe, version 2.4.205.0, faulting module unknown, version 0.0.0.0, fault address 0x00aecefc. Thereafter it crashed at: Faulting application Pythonwin.exe, version 2.4.205.0, faulting module unknown, version 0.0.0.0, fault address 0x00baebac. Shout if I can provide more info. Thanks ---------------------------------------------------------------------- Comment By: O.R.Senthil Kumaran (orsenthil) Date: 2005-12-08 13:14 Message: Logged In: YES user_id=942711 Am sorry,Mark. -Python 2.4 Build 205. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-12-08 10:22 Message: Logged In: YES user_id=14198 What Python version? ---------------------------------------------------------------------- Comment By: O.R.Senthil Kumaran (orsenthil) Date: 2005-12-08 09:27 Message: Logged In: YES user_id=942711 Please let me know if I need to provide more debugging information. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1376001&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-12-15 15:48:58
|
Patches item #1377153, was opened at 2005-12-09 22:26 Message generated for change (Comment added) made by infidel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1377153&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Luke Dunstan (infidel) Assigned to: Nobody/Anonymous (nobody) Summary: Improved Windows CE support Initial Comment: Some changes to allow pywintypes, win32gui, win32event and win32process to compile for Windows CE. Tested with MS eMbedded Visual C++ 4.0 with the Pocket PC 2003 SDK. This is still a work in progress. ---------------------------------------------------------------------- >Comment By: Luke Dunstan (infidel) Date: 2005-12-15 23:48 Message: Logged In: YES user_id=30442 Probably not soon. I have a set of makefiles for building the parts of pywin32 I mentioned for WinCE (using MS eVC 4): would that be appropriate for submission? They are based on makefiles from the PythonCE project because pywin32 is distributed with it. I hope to eventually look at modifying distutils to eliminate the need for these makefiles but I have no idea how hard that will be. Failing that I would try writing a Python script (from scratch) to do it. I also created a small module wince.pyd containing a bunch of WinCE-specific functions (actually mostly Pocket PC- specific I think), but now that I have also finished porting ctypes to ARM-WinCE that module may be less necessary. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-12-14 05:49 Message: Logged In: YES user_id=14198 Thanks for that. When you submitted the patch, you mentioned "This is still a work in progress." Do you think you will have an update any time soon? ---------------------------------------------------------------------- Comment By: Luke Dunstan (infidel) Date: 2005-12-13 21:43 Message: Logged In: YES user_id=30442 Yes, I tried to explain but not clearly enough. That particular #ifdef is incorrect, it should be like: #ifndef MS_WINCE if (index==-1) { nicons = (int)ExtractIconEx(fname, index, NULL, NULL, 0); PyWinObject_FreeTCHAR(fname); return PyInt_FromLong(nicons); } #endif because -1 does not have this special meaning. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-12-13 05:39 Message: Logged In: YES user_id=14198 I'm still not quite with you on the handling of the "-1, NULL, NULL" case. I agree that the docs are not particularly clear, but I see nothing in the docs that means you should force the result to 1 in that case - the way I read it, your code will *always* return 1 in the "-1, NULL, NULL" case, regardless of what Windows actually returned. Further, the comment appears incorrect - if the API actually returns a HICON but your implementation always returns 1, then presumably the hicon returned has been lost? +#ifdef MS_WINCE + /* On WinCE >= 2.1 the API actually returns a HICON */ + nicons = 1; +#endif + PyWinObject_FreeTCHAR(fname); return PyInt_FromLong(nicons); ---------------------------------------------------------------------- Comment By: Luke Dunstan (infidel) Date: 2005-12-12 23:19 Message: Logged In: YES user_id=30442 * You are correct about the format string * Regarding the return value: "For Windows CE versions 2.10 and later, this function returns the handle to an icon. If both phiconLarge and phiconSmall are not NULL, the return value defaults to the large icon. For Windows CE versions 1.0 through 2.01, this function returns a UINT data type. If the nIconIndex parameter is â 1, the phiconLarge parameter is NULL, and the phiconSmall parameter is NULL, then the return value is the number of icons contained in the specified file. Otherwise, the return value is the number of icons successfully extracted from the file." My reading is that the whole of the second paragraph only applies to WinCE <= 2.01. The earlier description of nIconIndex supports this: "For Windows CE versions 2.10 and later, the nIconIndex parameter must be zero or âN, where N is a specified resource identifier." This implies that -1 means "the resource ID 1" for WinCE >= 2.10. This probably also means that my patch should have excluded the whole if(index==-1) { ... } block for MS_WINCE. Also, it would not make much sense to return the number of icons since nIcons must be 1. In theory we could use #if to check the WinCE version but I prefer to leave that to someone who actually develops for old versions of WinCE. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-12-12 13:15 Message: Logged In: YES user_id=14198 This looks quite good - thanks! A few questions about ExtractIconEx: * It appears first char of the format string passed to PyArg_ParseTuple should be changed from "s" to "O"? * The block: if (index==-1) { nicons = (int)ExtractIconEx(fname, index, NULL, NULL, 0); #ifdef MS_WINCE /* On WinCE >= 2.1 the API actually returns a HICON */ nicons = 1; #endif Isn't clear to me. My reading of the MSDN documentation for CE says that the (-1, NULL, NULL case does correctly return the number of icons in the DLL. Can you please clarify? Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1377153&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-12-14 22:12:18
|
Bugs item #1380832, was opened at 2005-12-15 08:13 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1380832&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 Submitted By: Siggi (sigurasg) Assigned to: Nobody/Anonymous (nobody) Summary: win32file.DeviceIoControl can't do OVERLAPPED with output Initial Comment: In the case where win32file.DeviceIoControl is called on an async IOCTL with output, and an OVERLAPPED structure is called, it'll do the wrong thing. In this case win32 function will return FALSE, and ::GetLastError will return ERROR_IO_PENDING. In this case it's the caller's responsibility to keep the output buffer (readData) around until the IO completes or is cancelled, but the code below deallocates it. ok = DeviceIoControl(hDevice, dwIoControlCode, writeData, writeSize, readData, readSize, &numRead, pOverlapped); Py_END_ALLOW_THREADS if (!ok) { free(readData); return PyWin_SetAPIError("DeviceIoControl"); } Also, given the current interface, there's no way to retrieve the output of an overlapped IOCTL. This'd require much the same output convention as win32file.ReadFile. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2005-12-15 09:12 Message: Logged In: YES user_id=14198 That sounds correct. Patches gratefully accepted (or even just something I could add to the test suite!) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1380832&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-12-14 21:13:21
|
Bugs item #1380832, was opened at 2005-12-14 16:13 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=1380832&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 Submitted By: Siggi (sigurasg) Assigned to: Nobody/Anonymous (nobody) Summary: win32file.DeviceIoControl can't do OVERLAPPED with output Initial Comment: In the case where win32file.DeviceIoControl is called on an async IOCTL with output, and an OVERLAPPED structure is called, it'll do the wrong thing. In this case win32 function will return FALSE, and ::GetLastError will return ERROR_IO_PENDING. In this case it's the caller's responsibility to keep the output buffer (readData) around until the IO completes or is cancelled, but the code below deallocates it. ok = DeviceIoControl(hDevice, dwIoControlCode, writeData, writeSize, readData, readSize, &numRead, pOverlapped); Py_END_ALLOW_THREADS if (!ok) { free(readData); return PyWin_SetAPIError("DeviceIoControl"); } Also, given the current interface, there's no way to retrieve the output of an overlapped IOCTL. This'd require much the same output convention as win32file.ReadFile. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1380832&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-12-14 09:54:04
|
Bugs item #1379557, was opened at 2005-12-13 15:56 Message generated for change (Comment added) made by halon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1379557&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 Submitted By: Dieter Verfaillie (halon) Assigned to: Mark Hammond (mhammond) Summary: problem with pywin32 and unicode Initial Comment: I had a problem with the following code, pywin32 Build 205 and unicode. The following: <code, without error handling for easy reading...> # active_directory.find_user() eventualy # calls GetObject('LDAP://...') and # returns the result. account_in_ad = active_directory.find_user('DNFtest') # init canonicalName field account_in_ad.GetInfoEx(['canonicalName'], 0) # print canonicalName field print '[found]', account_in_ad.GetEx("canonicalName")[0] </code> sometimes resulted in the following: <trace> Traceback (most recent call last): File "C:\Python24\lib\site-packages\win32com\client\dynamic.py", line 293, in _make_method_ codeObject = compile(methodCode, "<COMObject %s>" % self._username_,"exec") UnicodeEncodeError: 'ascii' codec can't encode character u'\xf6' in position 66: ordinal not in range(128) </trace> Playing around with print statements showed that the call to GetInfoEx() triggered the backtrace. Looking deeper, self._username_ on line 293 in the file win32com/client/dynamic.py contained the unicode value: LDAP://CN=DNFtest,OU=16 H-Coördinatie & Veiligheid,OU=Unit Placeholder,DC=workplace,DC=be Note the o with the trema. That together with pythons compile() builtin used on that same line not liking unicode at all for the filename parameter caused the backtrace. As the second parameter (filename) to the compile builtin doesn't really matter when the code to compile does not come from a file, changing line 293 from: codeObject = compile(methodCode, "<COMObject %s>" % self._username_,"exec") to: codeObject = compile(methodCode, "<COMObject %s>" % self._username_.encode('ascii','replace'),"exec") solves this problem. Testing this change does not seem to have negative effects to other(older) code, so, eeerhm, whoohoo? I haven't looked if there are any other places where compile() is used yet, and if there are, maybe it would be a good idea to do this everywere, as long as the code to compile does not come from a file? with kind regards, Dieter Verfaillie ---------------------------------------------------------------------- >Comment By: Dieter Verfaillie (halon) Date: 2005-12-14 10:54 Message: Logged In: YES user_id=894731 I reverted my change and tried again with your function, but it didn't work (same traceback occuring on the same place as my original report). After some debugging I found out that the userName value sometimes contains the LDAP:// querystring. So the function you gave me never encodes userName. It only does that if userName is None, calculating userName from IDispatch. So taking that in account and adding an else to the if "userName is None:" part works. Like so: def _GetGoodDispatchAndUserName(IDispatch,userName,clsctx): #print userName if userName is None: if type(IDispatch) == StringType: userName = IDispatch elif type(IDispatch) == UnicodeType: # We always want the name displayed to the user to be a string userName = IDispatch.encode("ascii", "replace") else: userName = "<unknown>" else: if type(userName) == UnicodeType: userName = userName.encode("ascii", "replace") return (_GetGoodDispatch(IDispatch, clsctx), userName) ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-12-13 23:10 Message: Logged In: YES user_id=14198 Could you please try a different fix for me? Try reverting your change, and change the following function: def _GetGoodDispatchAndUserName(IDispatch,userName,clsctx): if userName is None: if type(IDispatch) == StringType: userName = IDispatch elif type(IDispatch) == UnicodeType: # We always want the name displayed to the user to be a string userName = IDispatch.encode("ascii", "replace") else: userName = "<unknown>" return (_GetGoodDispatch(IDispatch, clsctx), userName) Note the special handling of Unicode that will not exist in your version. This change should have the same affect, but should prevent you seeing other edge cases with the similar error, as this should ensure _username_ is *always* a string (not only when passed to compile) Thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1379557&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-12-13 22:10:30
|
Bugs item #1379557, was opened at 2005-12-14 01:56 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1379557&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 Submitted By: Dieter Verfaillie (halon) >Assigned to: Mark Hammond (mhammond) Summary: problem with pywin32 and unicode Initial Comment: I had a problem with the following code, pywin32 Build 205 and unicode. The following: <code, without error handling for easy reading...> # active_directory.find_user() eventualy # calls GetObject('LDAP://...') and # returns the result. account_in_ad = active_directory.find_user('DNFtest') # init canonicalName field account_in_ad.GetInfoEx(['canonicalName'], 0) # print canonicalName field print '[found]', account_in_ad.GetEx("canonicalName")[0] </code> sometimes resulted in the following: <trace> Traceback (most recent call last): File "C:\Python24\lib\site-packages\win32com\client\dynamic.py", line 293, in _make_method_ codeObject = compile(methodCode, "<COMObject %s>" % self._username_,"exec") UnicodeEncodeError: 'ascii' codec can't encode character u'\xf6' in position 66: ordinal not in range(128) </trace> Playing around with print statements showed that the call to GetInfoEx() triggered the backtrace. Looking deeper, self._username_ on line 293 in the file win32com/client/dynamic.py contained the unicode value: LDAP://CN=DNFtest,OU=16 H-Coördinatie & Veiligheid,OU=Unit Placeholder,DC=workplace,DC=be Note the o with the trema. That together with pythons compile() builtin used on that same line not liking unicode at all for the filename parameter caused the backtrace. As the second parameter (filename) to the compile builtin doesn't really matter when the code to compile does not come from a file, changing line 293 from: codeObject = compile(methodCode, "<COMObject %s>" % self._username_,"exec") to: codeObject = compile(methodCode, "<COMObject %s>" % self._username_.encode('ascii','replace'),"exec") solves this problem. Testing this change does not seem to have negative effects to other(older) code, so, eeerhm, whoohoo? I haven't looked if there are any other places where compile() is used yet, and if there are, maybe it would be a good idea to do this everywere, as long as the code to compile does not come from a file? with kind regards, Dieter Verfaillie ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2005-12-14 09:10 Message: Logged In: YES user_id=14198 Could you please try a different fix for me? Try reverting your change, and change the following function: def _GetGoodDispatchAndUserName(IDispatch,userName,clsctx): if userName is None: if type(IDispatch) == StringType: userName = IDispatch elif type(IDispatch) == UnicodeType: # We always want the name displayed to the user to be a string userName = IDispatch.encode("ascii", "replace") else: userName = "<unknown>" return (_GetGoodDispatch(IDispatch, clsctx), userName) Note the special handling of Unicode that will not exist in your version. This change should have the same affect, but should prevent you seeing other edge cases with the similar error, as this should ensure _username_ is *always* a string (not only when passed to compile) Thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1379557&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-12-13 21:49:36
|
Patches item #1377153, was opened at 2005-12-10 01:26 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1377153&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Luke Dunstan (infidel) Assigned to: Nobody/Anonymous (nobody) Summary: Improved Windows CE support Initial Comment: Some changes to allow pywintypes, win32gui, win32event and win32process to compile for Windows CE. Tested with MS eMbedded Visual C++ 4.0 with the Pocket PC 2003 SDK. This is still a work in progress. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2005-12-14 08:49 Message: Logged In: YES user_id=14198 Thanks for that. When you submitted the patch, you mentioned "This is still a work in progress." Do you think you will have an update any time soon? ---------------------------------------------------------------------- Comment By: Luke Dunstan (infidel) Date: 2005-12-14 00:43 Message: Logged In: YES user_id=30442 Yes, I tried to explain but not clearly enough. That particular #ifdef is incorrect, it should be like: #ifndef MS_WINCE if (index==-1) { nicons = (int)ExtractIconEx(fname, index, NULL, NULL, 0); PyWinObject_FreeTCHAR(fname); return PyInt_FromLong(nicons); } #endif because -1 does not have this special meaning. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-12-13 08:39 Message: Logged In: YES user_id=14198 I'm still not quite with you on the handling of the "-1, NULL, NULL" case. I agree that the docs are not particularly clear, but I see nothing in the docs that means you should force the result to 1 in that case - the way I read it, your code will *always* return 1 in the "-1, NULL, NULL" case, regardless of what Windows actually returned. Further, the comment appears incorrect - if the API actually returns a HICON but your implementation always returns 1, then presumably the hicon returned has been lost? +#ifdef MS_WINCE + /* On WinCE >= 2.1 the API actually returns a HICON */ + nicons = 1; +#endif + PyWinObject_FreeTCHAR(fname); return PyInt_FromLong(nicons); ---------------------------------------------------------------------- Comment By: Luke Dunstan (infidel) Date: 2005-12-13 02:19 Message: Logged In: YES user_id=30442 * You are correct about the format string * Regarding the return value: "For Windows CE versions 2.10 and later, this function returns the handle to an icon. If both phiconLarge and phiconSmall are not NULL, the return value defaults to the large icon. For Windows CE versions 1.0 through 2.01, this function returns a UINT data type. If the nIconIndex parameter is â 1, the phiconLarge parameter is NULL, and the phiconSmall parameter is NULL, then the return value is the number of icons contained in the specified file. Otherwise, the return value is the number of icons successfully extracted from the file." My reading is that the whole of the second paragraph only applies to WinCE <= 2.01. The earlier description of nIconIndex supports this: "For Windows CE versions 2.10 and later, the nIconIndex parameter must be zero or âN, where N is a specified resource identifier." This implies that -1 means "the resource ID 1" for WinCE >= 2.10. This probably also means that my patch should have excluded the whole if(index==-1) { ... } block for MS_WINCE. Also, it would not make much sense to return the number of icons since nIcons must be 1. In theory we could use #if to check the WinCE version but I prefer to leave that to someone who actually develops for old versions of WinCE. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-12-12 16:15 Message: Logged In: YES user_id=14198 This looks quite good - thanks! A few questions about ExtractIconEx: * It appears first char of the format string passed to PyArg_ParseTuple should be changed from "s" to "O"? * The block: if (index==-1) { nicons = (int)ExtractIconEx(fname, index, NULL, NULL, 0); #ifdef MS_WINCE /* On WinCE >= 2.1 the API actually returns a HICON */ nicons = 1; #endif Isn't clear to me. My reading of the MSDN documentation for CE says that the (-1, NULL, NULL case does correctly return the number of icons in the DLL. Can you please clarify? Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1377153&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-12-13 14:56:33
|
Bugs item #1379557, was opened at 2005-12-13 15:56 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=1379557&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 Submitted By: Dieter Verfaillie (halon) Assigned to: Nobody/Anonymous (nobody) Summary: problem with pywin32 and unicode Initial Comment: I had a problem with the following code, pywin32 Build 205 and unicode. The following: <code, without error handling for easy reading...> # active_directory.find_user() eventualy # calls GetObject('LDAP://...') and # returns the result. account_in_ad = active_directory.find_user('DNFtest') # init canonicalName field account_in_ad.GetInfoEx(['canonicalName'], 0) # print canonicalName field print '[found]', account_in_ad.GetEx("canonicalName")[0] </code> sometimes resulted in the following: <trace> Traceback (most recent call last): File "C:\Python24\lib\site-packages\win32com\client\dynamic.py", line 293, in _make_method_ codeObject = compile(methodCode, "<COMObject %s>" % self._username_,"exec") UnicodeEncodeError: 'ascii' codec can't encode character u'\xf6' in position 66: ordinal not in range(128) </trace> Playing around with print statements showed that the call to GetInfoEx() triggered the backtrace. Looking deeper, self._username_ on line 293 in the file win32com/client/dynamic.py contained the unicode value: LDAP://CN=DNFtest,OU=16 H-Coördinatie & Veiligheid,OU=Unit Placeholder,DC=workplace,DC=be Note the o with the trema. That together with pythons compile() builtin used on that same line not liking unicode at all for the filename parameter caused the backtrace. As the second parameter (filename) to the compile builtin doesn't really matter when the code to compile does not come from a file, changing line 293 from: codeObject = compile(methodCode, "<COMObject %s>" % self._username_,"exec") to: codeObject = compile(methodCode, "<COMObject %s>" % self._username_.encode('ascii','replace'),"exec") solves this problem. Testing this change does not seem to have negative effects to other(older) code, so, eeerhm, whoohoo? I haven't looked if there are any other places where compile() is used yet, and if there are, maybe it would be a good idea to do this everywere, as long as the code to compile does not come from a file? with kind regards, Dieter Verfaillie ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1379557&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-12-13 13:43:15
|
Patches item #1377153, was opened at 2005-12-09 22:26 Message generated for change (Comment added) made by infidel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1377153&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Luke Dunstan (infidel) Assigned to: Nobody/Anonymous (nobody) Summary: Improved Windows CE support Initial Comment: Some changes to allow pywintypes, win32gui, win32event and win32process to compile for Windows CE. Tested with MS eMbedded Visual C++ 4.0 with the Pocket PC 2003 SDK. This is still a work in progress. ---------------------------------------------------------------------- >Comment By: Luke Dunstan (infidel) Date: 2005-12-13 21:43 Message: Logged In: YES user_id=30442 Yes, I tried to explain but not clearly enough. That particular #ifdef is incorrect, it should be like: #ifndef MS_WINCE if (index==-1) { nicons = (int)ExtractIconEx(fname, index, NULL, NULL, 0); PyWinObject_FreeTCHAR(fname); return PyInt_FromLong(nicons); } #endif because -1 does not have this special meaning. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-12-13 05:39 Message: Logged In: YES user_id=14198 I'm still not quite with you on the handling of the "-1, NULL, NULL" case. I agree that the docs are not particularly clear, but I see nothing in the docs that means you should force the result to 1 in that case - the way I read it, your code will *always* return 1 in the "-1, NULL, NULL" case, regardless of what Windows actually returned. Further, the comment appears incorrect - if the API actually returns a HICON but your implementation always returns 1, then presumably the hicon returned has been lost? +#ifdef MS_WINCE + /* On WinCE >= 2.1 the API actually returns a HICON */ + nicons = 1; +#endif + PyWinObject_FreeTCHAR(fname); return PyInt_FromLong(nicons); ---------------------------------------------------------------------- Comment By: Luke Dunstan (infidel) Date: 2005-12-12 23:19 Message: Logged In: YES user_id=30442 * You are correct about the format string * Regarding the return value: "For Windows CE versions 2.10 and later, this function returns the handle to an icon. If both phiconLarge and phiconSmall are not NULL, the return value defaults to the large icon. For Windows CE versions 1.0 through 2.01, this function returns a UINT data type. If the nIconIndex parameter is â 1, the phiconLarge parameter is NULL, and the phiconSmall parameter is NULL, then the return value is the number of icons contained in the specified file. Otherwise, the return value is the number of icons successfully extracted from the file." My reading is that the whole of the second paragraph only applies to WinCE <= 2.01. The earlier description of nIconIndex supports this: "For Windows CE versions 2.10 and later, the nIconIndex parameter must be zero or âN, where N is a specified resource identifier." This implies that -1 means "the resource ID 1" for WinCE >= 2.10. This probably also means that my patch should have excluded the whole if(index==-1) { ... } block for MS_WINCE. Also, it would not make much sense to return the number of icons since nIcons must be 1. In theory we could use #if to check the WinCE version but I prefer to leave that to someone who actually develops for old versions of WinCE. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-12-12 13:15 Message: Logged In: YES user_id=14198 This looks quite good - thanks! A few questions about ExtractIconEx: * It appears first char of the format string passed to PyArg_ParseTuple should be changed from "s" to "O"? * The block: if (index==-1) { nicons = (int)ExtractIconEx(fname, index, NULL, NULL, 0); #ifdef MS_WINCE /* On WinCE >= 2.1 the API actually returns a HICON */ nicons = 1; #endif Isn't clear to me. My reading of the MSDN documentation for CE says that the (-1, NULL, NULL case does correctly return the number of icons in the DLL. Can you please clarify? Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1377153&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-12-13 03:56:48
|
Feature Requests item #1322653, was opened at 2005-10-10 22:52 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1322653&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Dubner (dubnerm) Assigned to: Nobody/Anonymous (nobody) Summary: Support for VT_RECORD in universal gateway Initial Comment: I'm interested in implementing this, and started working on it. If someone already near implementation - please inform here. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2005-12-13 14:56 Message: Logged In: YES user_id=14198 I guess that should work :) Ideally the test suite should also arrange for this to be called so we know it works and always remains working. ---------------------------------------------------------------------- Comment By: Michael Dubner (dubnerm) Date: 2005-12-13 14:28 Message: Logged In: YES user_id=39274 I want to do something as simple as following: RCS file: /cvsroot/pywin32/pywin32/com/win32com/src/univgw_dataconv.cpp,v retrieving revision 1.9 diff -p -s -r1.9 univgw_dataconv.cpp *** univgw_dataconv.cpp 27 Jun 2005 11:02:41 -0000 1.9 --- univgw_dataconv.cpp 13 Dec 2005 02:56:26 -0000 *************** PyObject * dataconv_WriteFromOutTuple(Py *** 301,306 **** --- 301,315 ---- } break; } + case VT_RECORD: + { + BOOL PyObject_AsRecordData(PyObject *ob, void **data); + if ( !PyObject_AsRecordData(obOutValue, pbArg) ) + { + goto Error; + } + break; + } case VT_BSTR: { // This is the normal "BSTR" case, we can't Do you know any reason this would fail? I can't check now - pywin32 doesn't compiles neither under VC toolkit, nor under mingw. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-10-21 13:22 Message: Logged In: YES user_id=14198 I don't know of anyone working on this. What approach are you taking? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1322653&group_id=78018 |
2 messages has been excluded from this view by a project administrator.
