pywin32-bugs Mailing List for Python for Windows Extensions (Page 81)
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...> - 2005-12-13 03:28:51
|
Feature Requests item #1322653, was opened at 2005-10-10 16:52 Message generated for change (Comment added) made by dubnerm 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: Michael Dubner (dubnerm) Date: 2005-12-13 06: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 07: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 |
|
From: SourceForge.net <no...@so...> - 2005-12-12 21:39:27
|
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-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-12 15:19:08
|
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-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-12 05:15:53
|
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-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-09 14:26:48
|
Patches item #1377153, was opened at 2005-12-09 22:26 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=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. ---------------------------------------------------------------------- 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-08 11:14:50
|
Bugs item #1376001, was opened at 2005-12-08 12:56 Message generated for change (Comment added) made by orsenthil 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: O.R.Senthil Kumaran (orsenthil) Date: 2005-12-08 16:44 Message: Logged In: YES user_id=942711 Am sorry,Mark. -Python 2.4 Build 205. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-12-08 13:52 Message: Logged In: YES user_id=14198 What Python version? ---------------------------------------------------------------------- Comment By: O.R.Senthil Kumaran (orsenthil) Date: 2005-12-08 12:57 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-08 08:22:35
|
Bugs item #1376001, was opened at 2005-12-08 18:26 Message generated for change (Comment added) made by mhammond 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: Mark Hammond (mhammond) Date: 2005-12-08 19:22 Message: Logged In: YES user_id=14198 What Python version? ---------------------------------------------------------------------- Comment By: O.R.Senthil Kumaran (orsenthil) Date: 2005-12-08 18: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-08 07:27:25
|
Bugs item #1376001, was opened at 2005-12-08 12:56 Message generated for change (Comment added) made by orsenthil 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: O.R.Senthil Kumaran (orsenthil) Date: 2005-12-08 12:57 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-08 07:26:11
|
Bugs item #1376001, was opened at 2005-12-08 12: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=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: 5 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. ---------------------------------------------------------------------- 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-06 21:54:05
|
Feature Requests item #1374042, was opened at 2005-12-06 13:29 Message generated for change (Settings changed) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1374042&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: win32 Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Stuart Woolford (swoolford) Assigned to: Nobody/Anonymous (nobody) Summary: Improve GetBitmapBits() Initial Comment: It would be a great enhancement to GetBitmapBits if it would return a string of the bitmap data, rather than a tuple of integers. The reasoning for this is that just about every other imaging library (for example PIL and wxPython) can handle data as a string of bytes, and converting to this is VERY slow. I would suggest perhaps there should be a GetBitmapBitsString() added.. As an example at present I have to: bmp=win32ui.CreateBitmapFromHandle(mybitmap) data=array.array('B',bmp.GetBitmapBits()).tostring() image=Image.fromstring("RGBA",size,data,"raw","BGRA" And the middle line takes around 0.7 seconds for 720x576x32bit, this is VERY slow. I would like to: bmp=win32ui.CreateBitmapFromHandle(mybitmap) data=bmp.GetBitmapBitsString() image=Image.fromstring("RGBA",size,data,"raw","BGRA" Which should take MUCH less time. This is currently an urgent problem, but the change is trivial and I will do it to my own copy, hopefully submitting a patch, although I dont usually do much C under windows. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2005-12-07 08:53 Message: Logged In: YES user_id=14198 Glad it helped! Checking in win32bitmap.cpp; new revision: 1.3; previous revision: 1.2 ---------------------------------------------------------------------- Comment By: Stuart Woolford (swoolford) Date: 2005-12-07 08:30 Message: Logged In: YES user_id=158782 Thank you so much Mark, that patch works perfectly, and I would love to see it in the next version. The time to fetch a single image into PIL went from 0.7 seconds to 0.013 seconds. Perfect! ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-12-06 17:03 Message: Logged In: YES user_id=14198 I'm attaching a patch that does this by way of an optional param. Let me know if this works for you. alternatively let me know which Python version you use and I'll mail a new .pyd to you. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1374042&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-12-06 21:30:37
|
Feature Requests item #1374042, was opened at 2005-12-06 15:29 Message generated for change (Comment added) made by swoolford You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1374042&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: Stuart Woolford (swoolford) Assigned to: Nobody/Anonymous (nobody) Summary: Improve GetBitmapBits() Initial Comment: It would be a great enhancement to GetBitmapBits if it would return a string of the bitmap data, rather than a tuple of integers. The reasoning for this is that just about every other imaging library (for example PIL and wxPython) can handle data as a string of bytes, and converting to this is VERY slow. I would suggest perhaps there should be a GetBitmapBitsString() added.. As an example at present I have to: bmp=win32ui.CreateBitmapFromHandle(mybitmap) data=array.array('B',bmp.GetBitmapBits()).tostring() image=Image.fromstring("RGBA",size,data,"raw","BGRA" And the middle line takes around 0.7 seconds for 720x576x32bit, this is VERY slow. I would like to: bmp=win32ui.CreateBitmapFromHandle(mybitmap) data=bmp.GetBitmapBitsString() image=Image.fromstring("RGBA",size,data,"raw","BGRA" Which should take MUCH less time. This is currently an urgent problem, but the change is trivial and I will do it to my own copy, hopefully submitting a patch, although I dont usually do much C under windows. ---------------------------------------------------------------------- >Comment By: Stuart Woolford (swoolford) Date: 2005-12-07 10:30 Message: Logged In: YES user_id=158782 Thank you so much Mark, that patch works perfectly, and I would love to see it in the next version. The time to fetch a single image into PIL went from 0.7 seconds to 0.013 seconds. Perfect! ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-12-06 19:03 Message: Logged In: YES user_id=14198 I'm attaching a patch that does this by way of an optional param. Let me know if this works for you. alternatively let me know which Python version you use and I'll mail a new .pyd to you. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1374042&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-12-06 06:03:57
|
Feature Requests item #1374042, was opened at 2005-12-06 13:29 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1374042&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: Stuart Woolford (swoolford) Assigned to: Nobody/Anonymous (nobody) Summary: Improve GetBitmapBits() Initial Comment: It would be a great enhancement to GetBitmapBits if it would return a string of the bitmap data, rather than a tuple of integers. The reasoning for this is that just about every other imaging library (for example PIL and wxPython) can handle data as a string of bytes, and converting to this is VERY slow. I would suggest perhaps there should be a GetBitmapBitsString() added.. As an example at present I have to: bmp=win32ui.CreateBitmapFromHandle(mybitmap) data=array.array('B',bmp.GetBitmapBits()).tostring() image=Image.fromstring("RGBA",size,data,"raw","BGRA" And the middle line takes around 0.7 seconds for 720x576x32bit, this is VERY slow. I would like to: bmp=win32ui.CreateBitmapFromHandle(mybitmap) data=bmp.GetBitmapBitsString() image=Image.fromstring("RGBA",size,data,"raw","BGRA" Which should take MUCH less time. This is currently an urgent problem, but the change is trivial and I will do it to my own copy, hopefully submitting a patch, although I dont usually do much C under windows. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2005-12-06 17:03 Message: Logged In: YES user_id=14198 I'm attaching a patch that does this by way of an optional param. Let me know if this works for you. alternatively let me know which Python version you use and I'll mail a new .pyd to you. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1374042&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-12-06 02:29:16
|
Feature Requests item #1374042, was opened at 2005-12-06 15:29 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=1374042&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: Stuart Woolford (swoolford) Assigned to: Nobody/Anonymous (nobody) Summary: Improve GetBitmapBits() Initial Comment: It would be a great enhancement to GetBitmapBits if it would return a string of the bitmap data, rather than a tuple of integers. The reasoning for this is that just about every other imaging library (for example PIL and wxPython) can handle data as a string of bytes, and converting to this is VERY slow. I would suggest perhaps there should be a GetBitmapBitsString() added.. As an example at present I have to: bmp=win32ui.CreateBitmapFromHandle(mybitmap) data=array.array('B',bmp.GetBitmapBits()).tostring() image=Image.fromstring("RGBA",size,data,"raw","BGRA" And the middle line takes around 0.7 seconds for 720x576x32bit, this is VERY slow. I would like to: bmp=win32ui.CreateBitmapFromHandle(mybitmap) data=bmp.GetBitmapBitsString() image=Image.fromstring("RGBA",size,data,"raw","BGRA" Which should take MUCH less time. This is currently an urgent problem, but the change is trivial and I will do it to my own copy, hopefully submitting a patch, although I dont usually do much C under windows. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1374042&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-11-20 00:37:00
|
Bugs item #1361822, was opened at 2005-11-19 19:36 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=1361822&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Colin J. Williams (cjwhrh) Assigned to: Nobody/Anonymous (nobody) Summary: crash when or after importing scipy - Build 205 Initial Comment: This has happened a number of times but I haven't been able to pin it down to more than the fact it occurs when attempting to debug a program using scipy. If the code is executed first, then one can step through it. In this case a crash often occurs eventually. The crash report is the instruction "0x7c168f1d" could not read "0x0000001c" Colin W. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1361822&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-11-14 09:51:07
|
Bugs item #1017504, was opened at 2004-08-27 12:44 Message generated for change (Comment added) made by gfe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1017504&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: 4 Submitted By: Martin Gfeller (gfe) Assigned to: Nobody/Anonymous (nobody) Summary: Debugger fills Registry with 100s of ToolbarDefault-Bar-n Initial Comment: On Windows 2000, PythonWin creates many hundreds of ToolbarDefault-Bar-n keys in the registry once the debugger is invoked (either by debug or post-mortem) and the 'go' or 'close' button is clicked. It seems to be specific to Windows 2000, where it occurs each time, and makes the debugger pretty unusable, because the registry slows down Windows to the point of unusability and instability. I could not reproduce it on Windows XP Pro. Environment: PythonWin Build 202 PythonWin 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)] on win32. Windows 2000, SP4, Build 2195 Best regards, Martin ---------------------------------------------------------------------- >Comment By: Martin Gfeller (gfe) Date: 2005-11-14 10:51 Message: Logged In: YES user_id=884167 I cannot reproduce it after installing 204. For me, the problem is solved. Martin ---------------------------------------------------------------------- Comment By: Erik Andersén (erik_andersen) Date: 2005-11-13 21:11 Message: Logged In: YES user_id=364358 It still exists in both 205 and 204. To trigger it, start pythonwin, enter and leave the debugger a couple of times, and you will have the junk in the registry. Win XP SP2 Python 2.4.2 Erik ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-11-10 21:54 Message: Logged In: YES user_id=14198 This bug is already marked as fixed - assumikng you have the latest pywin32 extensions, there should be no need to change anything. ---------------------------------------------------------------------- Comment By: Erik Andersén (erik_andersen) Date: 2005-11-10 20:28 Message: Logged In: YES user_id=364358 This can be fixed by commenting out the line self.saveBarState("ToolBarbefault") in intpyapp.py. Of couse, then pythonwin cannot remeber its bar state between sessions, but it is necessary to solve this problem -- otherwise pythonwin becames impossibly slow after the debugger has been entered and exited a number of times. The huge number of barstates saved can also cause interference to other applications running. Patch: 58c58 < self.SaveBarState("ToolbarDefault") --- > ## self.SaveBarState("ToolbarDefault") ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-03-06 01:54 Message: Logged In: YES user_id=14198 The problem probably appeared ok in 2.4 due to another bug which caused a crash at shutdown, possibly preventing the toolbar state from being saved (and thereby not hitting the problem). That bug was also recently fixed. ---------------------------------------------------------------------- Comment By: Colin J. Williams (cjwhrh) Date: 2005-03-05 16:12 Message: Logged In: YES user_id=285587 Thanks Mark, I'll be watching for 204. Incidentally, with very limited usage so far, I have the impression that the problem did not exist with Python 2.4.2 Colin W. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-03-05 06:07 Message: Logged In: YES user_id=14198 Fixed - will be in build 204 ---------------------------------------------------------------------- Comment By: Martin Gfeller (gfe) Date: 2005-01-10 10:25 Message: Logged In: YES user_id=884167 I never encountered this AssertionError, nevertheless the registry gets filled regularly. I zap the PyWin part of the registry now routinely after using the debugger. ---------------------------------------------------------------------- Comment By: Colin J. Williams (cjwhrh) Date: 2005-01-08 21:48 Message: Logged In: YES user_id=285587 The following traceback appears to be connected with the flood of toolbar entries to the registry of Windows XP with PythonWin build 203. The work around is to uninstall PythonWin and then remove the Python for win32 entry in the registry (uninstall doesn't do this). Finally, reinstall PythonWin. >>> Traceback (most recent call last): File "C:\Python23\Lib\site-packages\pythonwin\pywin\framework\dbgcommands.py", line 65, in OnStepOver self._DoOrStart("do_set_next", scriptutils.RS_DEBUGGER_STEP) File "C:\Python23\Lib\site-packages\pythonwin\pywin\framework\dbgcommands.py", line 57, in _DoOrStart method() File "C:\Python23\Lib\site-packages\pythonwin\pywin\debugger\debugger.py", line 632, in do_set_next if self.GUIAboutToRun(): File "C:\Python23\Lib\site-packages\pythonwin\pywin\debugger\debugger.py", line 791, in GUIAboutToRun if not self.StopDebuggerPump(): File "C:\Python23\Lib\site-packages\pythonwin\pywin\debugger\debugger.py", line 487, in StopDebuggerPump assert self.pumping, "Can't stop the debugger pump if Im not pumping!" AssertionError: Can't stop the debugger pump if Im not pumping! win32ui: Error in Command Message handler for command ID 15021, Code 0 Best wishes, Colin W. ---------------------------------------------------------------------- Comment By: Martin Gfeller (gfe) Date: 2004-12-22 22:48 Message: Logged In: YES user_id=884167 It also happens to me on Windows XP SP2 now (with PyWin 203). ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2004-10-09 07:52 Message: Logged In: YES user_id=14198 As I said in 944506: I've failed again to solve this. It sounds alot like Q151446, but that is pre MFC6, and doesn't solve the problem. It *nearly* does. I'm closing this and will keep "[ 1017504 ] Debugger fills Registry with 100s of ToolbarDefault-Bar-n" open (only as it has a better name) The next release will have that SaveBarState() call commented out. Dropping priority as this should mean the bug is much less severe. ---------------------------------------------------------------------- Comment By: bob gailer (ramrom) Date: 2004-08-28 15:19 Message: Logged In: YES user_id=587593 *This problem has also been entered under 894191 and 944506. It definitely causes problems, and has not, to my knowledge been addressed. 944506 has never been assigned! Please, someone who knows the details of what should happen help us. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1017504&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-11-13 20:11:22
|
Bugs item #1017504, was opened at 2004-08-27 10:44 Message generated for change (Comment added) made by erik_andersen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1017504&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: 4 Submitted By: Martin Gfeller (gfe) Assigned to: Nobody/Anonymous (nobody) Summary: Debugger fills Registry with 100s of ToolbarDefault-Bar-n Initial Comment: On Windows 2000, PythonWin creates many hundreds of ToolbarDefault-Bar-n keys in the registry once the debugger is invoked (either by debug or post-mortem) and the 'go' or 'close' button is clicked. It seems to be specific to Windows 2000, where it occurs each time, and makes the debugger pretty unusable, because the registry slows down Windows to the point of unusability and instability. I could not reproduce it on Windows XP Pro. Environment: PythonWin Build 202 PythonWin 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)] on win32. Windows 2000, SP4, Build 2195 Best regards, Martin ---------------------------------------------------------------------- Comment By: Erik Andersén (erik_andersen) Date: 2005-11-13 20:11 Message: Logged In: YES user_id=364358 It still exists in both 205 and 204. To trigger it, start pythonwin, enter and leave the debugger a couple of times, and you will have the junk in the registry. Win XP SP2 Python 2.4.2 Erik ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-11-10 20:54 Message: Logged In: YES user_id=14198 This bug is already marked as fixed - assumikng you have the latest pywin32 extensions, there should be no need to change anything. ---------------------------------------------------------------------- Comment By: Erik Andersén (erik_andersen) Date: 2005-11-10 19:28 Message: Logged In: YES user_id=364358 This can be fixed by commenting out the line self.saveBarState("ToolBarbefault") in intpyapp.py. Of couse, then pythonwin cannot remeber its bar state between sessions, but it is necessary to solve this problem -- otherwise pythonwin becames impossibly slow after the debugger has been entered and exited a number of times. The huge number of barstates saved can also cause interference to other applications running. Patch: 58c58 < self.SaveBarState("ToolbarDefault") --- > ## self.SaveBarState("ToolbarDefault") ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-03-06 00:54 Message: Logged In: YES user_id=14198 The problem probably appeared ok in 2.4 due to another bug which caused a crash at shutdown, possibly preventing the toolbar state from being saved (and thereby not hitting the problem). That bug was also recently fixed. ---------------------------------------------------------------------- Comment By: Colin J. Williams (cjwhrh) Date: 2005-03-05 15:12 Message: Logged In: YES user_id=285587 Thanks Mark, I'll be watching for 204. Incidentally, with very limited usage so far, I have the impression that the problem did not exist with Python 2.4.2 Colin W. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-03-05 05:07 Message: Logged In: YES user_id=14198 Fixed - will be in build 204 ---------------------------------------------------------------------- Comment By: Martin Gfeller (gfe) Date: 2005-01-10 09:25 Message: Logged In: YES user_id=884167 I never encountered this AssertionError, nevertheless the registry gets filled regularly. I zap the PyWin part of the registry now routinely after using the debugger. ---------------------------------------------------------------------- Comment By: Colin J. Williams (cjwhrh) Date: 2005-01-08 20:48 Message: Logged In: YES user_id=285587 The following traceback appears to be connected with the flood of toolbar entries to the registry of Windows XP with PythonWin build 203. The work around is to uninstall PythonWin and then remove the Python for win32 entry in the registry (uninstall doesn't do this). Finally, reinstall PythonWin. >>> Traceback (most recent call last): File "C:\Python23\Lib\site-packages\pythonwin\pywin\framework\dbgcommands.py", line 65, in OnStepOver self._DoOrStart("do_set_next", scriptutils.RS_DEBUGGER_STEP) File "C:\Python23\Lib\site-packages\pythonwin\pywin\framework\dbgcommands.py", line 57, in _DoOrStart method() File "C:\Python23\Lib\site-packages\pythonwin\pywin\debugger\debugger.py", line 632, in do_set_next if self.GUIAboutToRun(): File "C:\Python23\Lib\site-packages\pythonwin\pywin\debugger\debugger.py", line 791, in GUIAboutToRun if not self.StopDebuggerPump(): File "C:\Python23\Lib\site-packages\pythonwin\pywin\debugger\debugger.py", line 487, in StopDebuggerPump assert self.pumping, "Can't stop the debugger pump if Im not pumping!" AssertionError: Can't stop the debugger pump if Im not pumping! win32ui: Error in Command Message handler for command ID 15021, Code 0 Best wishes, Colin W. ---------------------------------------------------------------------- Comment By: Martin Gfeller (gfe) Date: 2004-12-22 21:48 Message: Logged In: YES user_id=884167 It also happens to me on Windows XP SP2 now (with PyWin 203). ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2004-10-09 05:52 Message: Logged In: YES user_id=14198 As I said in 944506: I've failed again to solve this. It sounds alot like Q151446, but that is pre MFC6, and doesn't solve the problem. It *nearly* does. I'm closing this and will keep "[ 1017504 ] Debugger fills Registry with 100s of ToolbarDefault-Bar-n" open (only as it has a better name) The next release will have that SaveBarState() call commented out. Dropping priority as this should mean the bug is much less severe. ---------------------------------------------------------------------- Comment By: bob gailer (ramrom) Date: 2004-08-28 13:19 Message: Logged In: YES user_id=587593 *This problem has also been entered under 894191 and 944506. It definitely causes problems, and has not, to my knowledge been addressed. 944506 has never been assigned! Please, someone who knows the details of what should happen help us. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1017504&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-11-10 20:54:56
|
Bugs item #1017504, was opened at 2004-08-27 20:44 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1017504&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: 4 Submitted By: Martin Gfeller (gfe) Assigned to: Nobody/Anonymous (nobody) Summary: Debugger fills Registry with 100s of ToolbarDefault-Bar-n Initial Comment: On Windows 2000, PythonWin creates many hundreds of ToolbarDefault-Bar-n keys in the registry once the debugger is invoked (either by debug or post-mortem) and the 'go' or 'close' button is clicked. It seems to be specific to Windows 2000, where it occurs each time, and makes the debugger pretty unusable, because the registry slows down Windows to the point of unusability and instability. I could not reproduce it on Windows XP Pro. Environment: PythonWin Build 202 PythonWin 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)] on win32. Windows 2000, SP4, Build 2195 Best regards, Martin ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2005-11-11 07:54 Message: Logged In: YES user_id=14198 This bug is already marked as fixed - assumikng you have the latest pywin32 extensions, there should be no need to change anything. ---------------------------------------------------------------------- Comment By: Erik Andersén (erik_andersen) Date: 2005-11-11 06:28 Message: Logged In: YES user_id=364358 This can be fixed by commenting out the line self.saveBarState("ToolBarbefault") in intpyapp.py. Of couse, then pythonwin cannot remeber its bar state between sessions, but it is necessary to solve this problem -- otherwise pythonwin becames impossibly slow after the debugger has been entered and exited a number of times. The huge number of barstates saved can also cause interference to other applications running. Patch: 58c58 < self.SaveBarState("ToolbarDefault") --- > ## self.SaveBarState("ToolbarDefault") ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-03-06 11:54 Message: Logged In: YES user_id=14198 The problem probably appeared ok in 2.4 due to another bug which caused a crash at shutdown, possibly preventing the toolbar state from being saved (and thereby not hitting the problem). That bug was also recently fixed. ---------------------------------------------------------------------- Comment By: Colin J. Williams (cjwhrh) Date: 2005-03-06 02:12 Message: Logged In: YES user_id=285587 Thanks Mark, I'll be watching for 204. Incidentally, with very limited usage so far, I have the impression that the problem did not exist with Python 2.4.2 Colin W. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-03-05 16:07 Message: Logged In: YES user_id=14198 Fixed - will be in build 204 ---------------------------------------------------------------------- Comment By: Martin Gfeller (gfe) Date: 2005-01-10 20:25 Message: Logged In: YES user_id=884167 I never encountered this AssertionError, nevertheless the registry gets filled regularly. I zap the PyWin part of the registry now routinely after using the debugger. ---------------------------------------------------------------------- Comment By: Colin J. Williams (cjwhrh) Date: 2005-01-09 07:48 Message: Logged In: YES user_id=285587 The following traceback appears to be connected with the flood of toolbar entries to the registry of Windows XP with PythonWin build 203. The work around is to uninstall PythonWin and then remove the Python for win32 entry in the registry (uninstall doesn't do this). Finally, reinstall PythonWin. >>> Traceback (most recent call last): File "C:\Python23\Lib\site-packages\pythonwin\pywin\framework\dbgcommands.py", line 65, in OnStepOver self._DoOrStart("do_set_next", scriptutils.RS_DEBUGGER_STEP) File "C:\Python23\Lib\site-packages\pythonwin\pywin\framework\dbgcommands.py", line 57, in _DoOrStart method() File "C:\Python23\Lib\site-packages\pythonwin\pywin\debugger\debugger.py", line 632, in do_set_next if self.GUIAboutToRun(): File "C:\Python23\Lib\site-packages\pythonwin\pywin\debugger\debugger.py", line 791, in GUIAboutToRun if not self.StopDebuggerPump(): File "C:\Python23\Lib\site-packages\pythonwin\pywin\debugger\debugger.py", line 487, in StopDebuggerPump assert self.pumping, "Can't stop the debugger pump if Im not pumping!" AssertionError: Can't stop the debugger pump if Im not pumping! win32ui: Error in Command Message handler for command ID 15021, Code 0 Best wishes, Colin W. ---------------------------------------------------------------------- Comment By: Martin Gfeller (gfe) Date: 2004-12-23 08:48 Message: Logged In: YES user_id=884167 It also happens to me on Windows XP SP2 now (with PyWin 203). ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2004-10-09 15:52 Message: Logged In: YES user_id=14198 As I said in 944506: I've failed again to solve this. It sounds alot like Q151446, but that is pre MFC6, and doesn't solve the problem. It *nearly* does. I'm closing this and will keep "[ 1017504 ] Debugger fills Registry with 100s of ToolbarDefault-Bar-n" open (only as it has a better name) The next release will have that SaveBarState() call commented out. Dropping priority as this should mean the bug is much less severe. ---------------------------------------------------------------------- Comment By: bob gailer (ramrom) Date: 2004-08-28 23:19 Message: Logged In: YES user_id=587593 *This problem has also been entered under 894191 and 944506. It definitely causes problems, and has not, to my knowledge been addressed. 944506 has never been assigned! Please, someone who knows the details of what should happen help us. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1017504&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-11-10 19:28:35
|
Bugs item #1017504, was opened at 2004-08-27 10:44 Message generated for change (Comment added) made by erik_andersen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1017504&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: 4 Submitted By: Martin Gfeller (gfe) Assigned to: Nobody/Anonymous (nobody) Summary: Debugger fills Registry with 100s of ToolbarDefault-Bar-n Initial Comment: On Windows 2000, PythonWin creates many hundreds of ToolbarDefault-Bar-n keys in the registry once the debugger is invoked (either by debug or post-mortem) and the 'go' or 'close' button is clicked. It seems to be specific to Windows 2000, where it occurs each time, and makes the debugger pretty unusable, because the registry slows down Windows to the point of unusability and instability. I could not reproduce it on Windows XP Pro. Environment: PythonWin Build 202 PythonWin 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)] on win32. Windows 2000, SP4, Build 2195 Best regards, Martin ---------------------------------------------------------------------- Comment By: Erik Andersén (erik_andersen) Date: 2005-11-10 19:28 Message: Logged In: YES user_id=364358 This can be fixed by commenting out the line self.saveBarState("ToolBarbefault") in intpyapp.py. Of couse, then pythonwin cannot remeber its bar state between sessions, but it is necessary to solve this problem -- otherwise pythonwin becames impossibly slow after the debugger has been entered and exited a number of times. The huge number of barstates saved can also cause interference to other applications running. Patch: 58c58 < self.SaveBarState("ToolbarDefault") --- > ## self.SaveBarState("ToolbarDefault") ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-03-06 00:54 Message: Logged In: YES user_id=14198 The problem probably appeared ok in 2.4 due to another bug which caused a crash at shutdown, possibly preventing the toolbar state from being saved (and thereby not hitting the problem). That bug was also recently fixed. ---------------------------------------------------------------------- Comment By: Colin J. Williams (cjwhrh) Date: 2005-03-05 15:12 Message: Logged In: YES user_id=285587 Thanks Mark, I'll be watching for 204. Incidentally, with very limited usage so far, I have the impression that the problem did not exist with Python 2.4.2 Colin W. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-03-05 05:07 Message: Logged In: YES user_id=14198 Fixed - will be in build 204 ---------------------------------------------------------------------- Comment By: Martin Gfeller (gfe) Date: 2005-01-10 09:25 Message: Logged In: YES user_id=884167 I never encountered this AssertionError, nevertheless the registry gets filled regularly. I zap the PyWin part of the registry now routinely after using the debugger. ---------------------------------------------------------------------- Comment By: Colin J. Williams (cjwhrh) Date: 2005-01-08 20:48 Message: Logged In: YES user_id=285587 The following traceback appears to be connected with the flood of toolbar entries to the registry of Windows XP with PythonWin build 203. The work around is to uninstall PythonWin and then remove the Python for win32 entry in the registry (uninstall doesn't do this). Finally, reinstall PythonWin. >>> Traceback (most recent call last): File "C:\Python23\Lib\site-packages\pythonwin\pywin\framework\dbgcommands.py", line 65, in OnStepOver self._DoOrStart("do_set_next", scriptutils.RS_DEBUGGER_STEP) File "C:\Python23\Lib\site-packages\pythonwin\pywin\framework\dbgcommands.py", line 57, in _DoOrStart method() File "C:\Python23\Lib\site-packages\pythonwin\pywin\debugger\debugger.py", line 632, in do_set_next if self.GUIAboutToRun(): File "C:\Python23\Lib\site-packages\pythonwin\pywin\debugger\debugger.py", line 791, in GUIAboutToRun if not self.StopDebuggerPump(): File "C:\Python23\Lib\site-packages\pythonwin\pywin\debugger\debugger.py", line 487, in StopDebuggerPump assert self.pumping, "Can't stop the debugger pump if Im not pumping!" AssertionError: Can't stop the debugger pump if Im not pumping! win32ui: Error in Command Message handler for command ID 15021, Code 0 Best wishes, Colin W. ---------------------------------------------------------------------- Comment By: Martin Gfeller (gfe) Date: 2004-12-22 21:48 Message: Logged In: YES user_id=884167 It also happens to me on Windows XP SP2 now (with PyWin 203). ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2004-10-09 05:52 Message: Logged In: YES user_id=14198 As I said in 944506: I've failed again to solve this. It sounds alot like Q151446, but that is pre MFC6, and doesn't solve the problem. It *nearly* does. I'm closing this and will keep "[ 1017504 ] Debugger fills Registry with 100s of ToolbarDefault-Bar-n" open (only as it has a better name) The next release will have that SaveBarState() call commented out. Dropping priority as this should mean the bug is much less severe. ---------------------------------------------------------------------- Comment By: bob gailer (ramrom) Date: 2004-08-28 13:19 Message: Logged In: YES user_id=587593 *This problem has also been entered under 894191 and 944506. It definitely causes problems, and has not, to my knowledge been addressed. 944506 has never been assigned! Please, someone who knows the details of what should happen help us. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1017504&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-11-04 20:28:58
|
Bugs item #1348618, was opened at 2005-11-04 21:28 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=1348618&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: Robert Kiendl (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: IndentationError Initial Comment: latest build 205 / py2.4: occasional error message in interactive window: [Dbg]>>> Traceback (most recent call last): File "C:\Python24\Lib\site-packages\pythonwin\pywin\framework\editor\color\coloreditor.py", line 51, in OnInitialUpdate SyntEditViewParent.OnInitialUpdate(self) File "C:\Python24\Lib\site-packages\pythonwin\pywin\scintilla\view.py", line 210, in OnInitialUpdate self.OnWinIniChange(None) File "C:\Python24\Lib\site-packages\pythonwin\pywin\scintilla\view.py", line 223, in OnWinIniChange self.DoConfigChange() File "C:\Python24\Lib\site-packages\pythonwin\pywin\framework\editor\color\coloreditor.py", line 162, in DoConfigChange ext.set_indentation_params(1) File "C:\Python24\Lib\site-packages\pythonwin\pywin\idle\AutoIndent.py", line 140, in set_indentation_params i = self.guess_indent() File "C:\Python24\Lib\site-packages\pythonwin\pywin\idle\AutoIndent.py", line 473, in guess_indent opener, indented = IndentSearcher(self.text, self.tabwidth).run() File "C:\Python24\Lib\site-packages\pythonwin\pywin\idle\AutoIndent.py", line 546, in run _tokenize.tokenize(self.readline, self.tokeneater) File "C:\Python24\lib\tokenize.py", line 153, in tokenize tokenize_loop(readline, tokeneater) File "C:\Python24\lib\tokenize.py", line 159, in tokenize_loop for token_info in generate_tokens(readline): File "C:\Python24\lib\tokenize.py", line 229, in generate_tokens raise IndentationError( IndentationError: unindent does not match any outer indentation level win32ui: OnInitialUpdate() virtual handler (<bound method SyntEditView.OnInitialUpdate of <pywin.framework.editor.color.coloreditor.SyntEditView instance at 0x00EE57D8>>) raised an exception Traceback (most recent call last): File "C:\Python24\Lib\site-packages\pythonwin\pywin\framework\editor\color\coloreditor.py", line 51, in OnInitialUpdate SyntEditViewParent.OnInitialUpdate(self) File "C:\Python24\Lib\site-packages\pythonwin\pywin\scintilla\view.py", line 210, in OnInitialUpdate self.OnWinIniChange(None) File "C:\Python24\Lib\site-packages\pythonwin\pywin\scintilla\view.py", line 223, in OnWinIniChange self.DoConfigChange() File "C:\Python24\Lib\site-packages\pythonwin\pywin\framework\editor\color\coloreditor.py", line 162, in DoConfigChange ext.set_indentation_params(1) File "C:\Python24\Lib\site-packages\pythonwin\pywin\idle\AutoIndent.py", line 140, in set_indentation_params i = self.guess_indent() File "C:\Python24\Lib\site-packages\pythonwin\pywin\idle\AutoIndent.py", line 473, in guess_indent opener, indented = IndentSearcher(self.text, self.tabwidth).run() File "C:\Python24\Lib\site-packages\pythonwin\pywin\idle\AutoIndent.py", line 546, in run _tokenize.tokenize(self.readline, self.tokeneater) File "C:\Python24\lib\tokenize.py", line 153, in tokenize tokenize_loop(readline, tokeneater) File "C:\Python24\lib\tokenize.py", line 159, in tokenize_loop for token_info in generate_tokens(readline): File "C:\Python24\lib\tokenize.py", line 229, in generate_tokens raise IndentationError( IndentationError: unindent does not match any outer indentation level win32ui: OnInitialUpdate() virtual handler (<bound method SyntEditView.OnInitialUpdate of <pywin.framework.editor.color.coloreditor.SyntEditView instance at 0x00EE59E0>>) raised an exception [Dbg]>>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1348618&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-11-01 21:24:33
|
Bugs item #1345104, was opened at 2005-11-02 04:37 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1345104&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: Nikos Kouremenos (nkour) Assigned to: Nobody/Anonymous (nobody) Summary: LockFile Determines the type of a file. that is a lie Initial Comment: LockFile Locks a specified file for exclusive access by the calling process. more: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/file_management_functions.asp ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2005-11-02 08:24 Message: Logged In: YES user_id=14198 Fixed - thanks. Checking in win32/src/win32file.i; new revision: 1.49; previous revision: 1.48 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1345104&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-11-01 17:37:34
|
Bugs item #1345104, was opened at 2005-11-01 19:37 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=1345104&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: Nikos Kouremenos (nkour) Assigned to: Nobody/Anonymous (nobody) Summary: LockFile Determines the type of a file. that is a lie Initial Comment: LockFile Locks a specified file for exclusive access by the calling process. more: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/file_management_functions.asp ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1345104&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-10-28 17:55:04
|
Bugs item #1255370, was opened at 2005-08-09 19:33 Message generated for change (Comment added) made by kwharrigan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1255370&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: David Ward (dpward) Assigned to: Nobody/Anonymous (nobody) Summary: Problem using MS Collaboration Data Objects with build 204 Initial Comment: We are having problems using Microsoft's Collaboration Data Objects (CDO) to send e-mail with pywin32 build 204. Our Python code works perfectly with win32all build 163. Preliminary testing with pywin32 build 200 seemed to indicate that our code works with that as well. This is the end of the traceback message we are getting: File "C:\Program Files\NeTTS\ctb\common\eventplugins\emailoutlook\RAg ent.py", line 604, in SendEmail msg.Update() File "<COMObject <unknown>>", line 3, in Update File "C:\Python23\Lib\site- packages\win32com\client\dynamic.py", line 251, in _ApplyTypes_ result = self._oleobj_.InvokeTypes(*(dispid, LCID, wFlags, retType, argTypes) + args) com_error: (-2147352567, 'Exception occurred.', (1087, 'Collaboration Data Objects', ' [Collaboration Data Objects - [E_INVALIDARG(80070057)]]', None, 0, - 2147024809), None) Do you know what change in pywin32 is causing this? Thanks for your help. ---------------------------------------------------------------------- Comment By: Kyle Harrigan (kwharrigan) Date: 2005-10-28 13:55 Message: Logged In: YES user_id=1285226 Mark, I am the author of the code David was troubleshooting. I tried passing the optional arguments with their default values, but get the same error. I tried the call: msg.Update(True, False) but still get: msg.Update(True, False) File "<COMObject <unknown>>", line 3, in Update File "C:\Python23\Lib\site-packages\win32com\client\dynamic.py", line 251, in _ApplyTypes_ result = self._oleobj_.InvokeTypes(*(dispid, LCID, wFlags, retType, argTypes ) + args) com_error: (-2147352567, 'Exception occurred.', (1087, 'Collaboration Data Objec ts', ' [Collaboration Data Objects - [E_INVALIDARG(80070057)]]', None, 0, -21470 24809), None) I was able to cause this failure by simply uninstalling 163 and installing 2.05. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-10-23 08:23 Message: Logged In: YES user_id=14198 Did you try providing the optional args? Did it help? Thanks. ---------------------------------------------------------------------- Comment By: David Ward (dpward) Date: 2005-08-10 00:06 Message: Logged In: YES user_id=1326408 No, the only difference is pywin32 itself. Something in pywin32 has changed between builds 200 and 204 that is breaking CDO. To test this, we started with a clean VMware image with Windows XP and Office XP. We booted from this image and installed Python and pywin32 build 204. We ran our code, and it returned the error above. Then we reverted to the clean VMware image again. We did everything *exactly* the same, except that we installed win32all build 163, but this time our code worked perfectly. We reverted VMware again to the base image, and then used win32all build 200, and also did not notice any problems. The *only* difference in all of these three situations was the pywin32/win32all build version. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-08-09 22:36 Message: Logged In: YES user_id=14198 I've never heard anything similar. You could try explicitly providing any optional args to "Update()", as I believe a subtle change was made to the way default arguments are passed. If it possible something else changed - eg, new CDO version, or the code now using makepy when it previously was not, etc? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1255370&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-10-23 23:32:41
|
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: 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...> - 2005-10-23 12:23:04
|
Bugs item #1255370, was opened at 2005-08-10 09:33 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1255370&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: David Ward (dpward) Assigned to: Nobody/Anonymous (nobody) Summary: Problem using MS Collaboration Data Objects with build 204 Initial Comment: We are having problems using Microsoft's Collaboration Data Objects (CDO) to send e-mail with pywin32 build 204. Our Python code works perfectly with win32all build 163. Preliminary testing with pywin32 build 200 seemed to indicate that our code works with that as well. This is the end of the traceback message we are getting: File "C:\Program Files\NeTTS\ctb\common\eventplugins\emailoutlook\RAg ent.py", line 604, in SendEmail msg.Update() File "<COMObject <unknown>>", line 3, in Update File "C:\Python23\Lib\site- packages\win32com\client\dynamic.py", line 251, in _ApplyTypes_ result = self._oleobj_.InvokeTypes(*(dispid, LCID, wFlags, retType, argTypes) + args) com_error: (-2147352567, 'Exception occurred.', (1087, 'Collaboration Data Objects', ' [Collaboration Data Objects - [E_INVALIDARG(80070057)]]', None, 0, - 2147024809), None) Do you know what change in pywin32 is causing this? Thanks for your help. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2005-10-23 22:23 Message: Logged In: YES user_id=14198 Did you try providing the optional args? Did it help? Thanks. ---------------------------------------------------------------------- Comment By: David Ward (dpward) Date: 2005-08-10 14:06 Message: Logged In: YES user_id=1326408 No, the only difference is pywin32 itself. Something in pywin32 has changed between builds 200 and 204 that is breaking CDO. To test this, we started with a clean VMware image with Windows XP and Office XP. We booted from this image and installed Python and pywin32 build 204. We ran our code, and it returned the error above. Then we reverted to the clean VMware image again. We did everything *exactly* the same, except that we installed win32all build 163, but this time our code worked perfectly. We reverted VMware again to the base image, and then used win32all build 200, and also did not notice any problems. The *only* difference in all of these three situations was the pywin32/win32all build version. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-08-10 12:36 Message: Logged In: YES user_id=14198 I've never heard anything similar. You could try explicitly providing any optional args to "Update()", as I believe a subtle change was made to the way default arguments are passed. If it possible something else changed - eg, new CDO version, or the code now using makepy when it previously was not, etc? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1255370&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2005-10-23 11:26:49
|
Bugs item #1296632, was opened at 2005-09-21 03:34 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1296632&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: com Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Oleg Noga (oleg_noga) Assigned to: Nobody/Anonymous (nobody) Summary: TypeError: 'unicode' object is not callable Initial Comment: python 2.3.5 pythonwin 204 using dynamic binding Have TypeError: 'unicode' object is not callable while calling COM object function. Because CDispatch.__getattr__ returns empty unicode string instead of callable. I made some dirty fix, please, see attach, there is some comments inside It is win32com\client\dynamic.py Pity I can't supply COM object to reproduce because it is proprietary. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2005-10-23 21:26 Message: Logged In: YES user_id=14198 The problem here is that Python tries to check if the attribute name is a method or property by requesting a property and handling the error that results. Even though Python asks specifically for a property (INVOKE_PROPERTYGET), the object is treating it as a function call and returning a string. pythoncom therefore assumes it is a simple property. VB does it correctly as its syntax prevents using functions as objects (eg, you can't assign an object method to a variable). There are 2 choices: * Change the object to honour the invoke flags correctly. * Call obj._FlagAsMethod("Method1", "method2", ...) And you will then be able to say obk.Method1() ---------------------------------------------------------------------- Comment By: Oleg Noga (oleg_noga) Date: 2005-09-21 03:41 Message: Logged In: YES user_id=551440 Note: Visual Basic calls functions of that COM object correctly ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1296632&group_id=78018 |
2 messages has been excluded from this view by a project administrator.
