pywin32-bugs Mailing List for Python for Windows Extensions (Page 78)
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-02-11 20:19:33
|
Feature Requests item #1429815, was opened at 2006-02-11 22:19 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=1429815&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: Norman Rasmussen (normanr) Assigned to: Nobody/Anonymous (nobody) Summary: win32security missing several constants (listed) Initial Comment: Please can you include the following sets of constants: ISC_REQ_* ISC_RET_* ASC_REQ_* ASC_RET_* SECBUFFER_* SECPKG_ATTR_* SECPKG_CONTEXT_* SECPKG_FLAG_* SECPKG_NEGOTIATION_* SECPKG_OPTIONS_* SECURITY_*_DREP SEC_E_OK SEC_I_* SEC_WINNT_* Some are referenced in the help files, but they're not defined. I had to go and dig in sspi.h in the SDK to find the vaules. Some used for AcceptSecurityContext and InitializeSecurityContext are only metioned by wildcard, and should be listed (like PyCtxtHandle.QueryContextAttributes does) (sspi.h attached) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1429815&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-02-07 16:21:43
|
Patches item #1424856, was opened at 2006-02-05 17:55 Message generated for change (Comment added) made by mkleehammer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1424856&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: Deleted >Resolution: Rejected Priority: 5 Submitted By: Michael Kleehammer (mkleehammer) Assigned to: Nobody/Anonymous (nobody) Summary: DialogIndrect/CreateDialogIndrect resource ID support Initial Comment: This patch allows DialogIndirect and CreateDialogIndirect to accept a resource ID in place of a control list. The previous control list code still works; the type of the parameter is examined and is only used as a resource ID if it is an int. This code uses the resource directly instead of translating to a Python specific format and then back. ---------------------------------------------------------------------- >Comment By: Michael Kleehammer (mkleehammer) Date: 2006-02-07 10:21 Message: Logged In: YES user_id=95205 I don't know what I was thinking -- this emulates CreateDialog. I was working on multiple things and managed to confuse them. Deleting this unnecessary patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1424856&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-02-05 23:55:32
|
Patches item #1424856, was opened at 2006-02-05 17:55 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=1424856&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 Kleehammer (mkleehammer) Assigned to: Nobody/Anonymous (nobody) Summary: DialogIndrect/CreateDialogIndrect resource ID support Initial Comment: This patch allows DialogIndirect and CreateDialogIndirect to accept a resource ID in place of a control list. The previous control list code still works; the type of the parameter is examined and is only used as a resource ID if it is an int. This code uses the resource directly instead of translating to a Python specific format and then back. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1424856&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-02-02 23:55:45
|
Bugs item #1414160, was opened at 2006-01-25 00:24 Message generated for change (Comment added) made by ghazel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1414160&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: DDE sets off DEP (in demos and pythonwin too) Initial Comment: running C:\Python24\Lib\site-packages\win32 \Demos\dde\ddeserver.py causes DEP to go off for python. Similarly, DEP is set off for pythonwin. If you disable the DDE stuff in pythonwin, it does not set off DEP. ---------------------------------------------------------------------- >Comment By: Greg Hazel (ghazel) Date: 2006-02-02 23:55 Message: Logged In: YES user_id=731668 I found the code that triggers DEP. In pywin32\Pythonwin\stddde.cpp there is a define called _CALLHACK_. If that is commented out DDE does not set off DEP. Judging from the comments surrounding this "hack", I'd guess this is not too much of a surprise. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1414160&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-02-02 21:20:25
|
Bugs item #1422850, was opened at 2006-02-02 19:27 Message generated for change (Comment added) made by rbell01824 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1422850&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: None Priority: 5 Submitted By: rbell01824 (rbell01824) Assigned to: Nobody/Anonymous (nobody) Summary: pythoncom curious behavior, possible bug Initial Comment: The attached test program was derived from the current distribution testexplorer.py. It is modified to catch most of IE's events and to output a message whenever an event occurs. As part of the message output the elapsed time since the start of the operation that should be generating events is output by calculating time.time()-timeStart. Based on the output, early in the applications execution, there is a period of time when events are occuring and timeStart appears to be 0. The code design and debug print statements indicate that this should not be the case under any circumstances. The behavior is odd and may be a bug. The period of time during which the behavior occurs depends on when/how pythoncom.PumpWaitingMessages() is called (see the comments on the WaitLoop statements in TestExplorerEvents). Incidentally, the code may provide a useful example of event processing for the distribution as the existing code implies message pump behaviors that are not generally reliable. You have my permission to use it in this fashion. The following clip from a run highlights the behavior: <<<<< Create IE ##### set timeStart <<<<< Try setting visible OK timeStart==0 5637330 1138908269.281 0 0 OnCommandStateChange Command -1 Enable False timeStart==0 5637330 1138908269.281 0 0 Visible True ******************************************************************************** ##### Navigate to [about:blank] waitstyle [] ##### set timeStart timeStart==0 5637330 1138908269.281 0 1 PropertyChange '{265b75c1-4158-11d0-90f6-00c04fd497ea}' timeStart==0 5637330 1138908269.296 0 1 OnBeforeNavigate2 URL [about:blank] Flags [0] TargetFrameName [] timeStart should not ever be 0 based on the code and debug prings. The test script is attached. ---------------------------------------------------------------------- >Comment By: rbell01824 (rbell01824) Date: 2006-02-02 21:20 Message: Logged In: YES user_id=1190195 Bug in test routine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1422850&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-02-02 19:27:23
|
Bugs item #1422850, was opened at 2006-02-02 19:27 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=1422850&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: rbell01824 (rbell01824) Assigned to: Nobody/Anonymous (nobody) Summary: pythoncom curious behavior, possible bug Initial Comment: The attached test program was derived from the current distribution testexplorer.py. It is modified to catch most of IE's events and to output a message whenever an event occurs. As part of the message output the elapsed time since the start of the operation that should be generating events is output by calculating time.time()-timeStart. Based on the output, early in the applications execution, there is a period of time when events are occuring and timeStart appears to be 0. The code design and debug print statements indicate that this should not be the case under any circumstances. The behavior is odd and may be a bug. The period of time during which the behavior occurs depends on when/how pythoncom.PumpWaitingMessages() is called (see the comments on the WaitLoop statements in TestExplorerEvents). Incidentally, the code may provide a useful example of event processing for the distribution as the existing code implies message pump behaviors that are not generally reliable. You have my permission to use it in this fashion. The following clip from a run highlights the behavior: <<<<< Create IE ##### set timeStart <<<<< Try setting visible OK timeStart==0 5637330 1138908269.281 0 0 OnCommandStateChange Command -1 Enable False timeStart==0 5637330 1138908269.281 0 0 Visible True ******************************************************************************** ##### Navigate to [about:blank] waitstyle [] ##### set timeStart timeStart==0 5637330 1138908269.281 0 1 PropertyChange '{265b75c1-4158-11d0-90f6-00c04fd497ea}' timeStart==0 5637330 1138908269.296 0 1 OnBeforeNavigate2 URL [about:blank] Flags [0] TargetFrameName [] timeStart should not ever be 0 based on the code and debug prings. The test script is attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1422850&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-01-29 22:40:55
|
Bugs item #1418081, was opened at 2006-01-29 15:06 Message generated for change (Settings changed) made by nickjacobson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1418081&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: None Priority: 5 Submitted By: Nick Jacobson (nickjacobson) Assigned to: Nobody/Anonymous (nobody) Summary: Reads float from Excel cell instead of int Initial Comment: When you read in an integer from an Excel cell, it is type float. And printing it will print e.g. "5.0" instead of "5". example: from win32com.client import Dispatch xlApp = Dispatch("Excel.Application") xlApp.Visible = 1 xlApp.Workbooks.Add() xlApp.ActiveSheet.Cells(1,1).Value = 5 print xlApp.ActiveSheet.Cells(1,1).Value print type(xlApp.ActiveSheet.Cells(1,1).Value) raw_input("paused") xlApp.Quit() This returns: 5.0 <type 'float'> paused I'm using Python 2.4.2 and Excel 2003 Pro. ---------------------------------------------------------------------- Comment By: John Machin (sjmachin) Date: 2006-01-29 16:14 Message: Logged In: YES user_id=480138 Again, it's nothing to do with pywin32. This is standard Python. >>> print float(5) 5.0 >>> Perhaps you might like to discuss perceived bugs in the pywin32 mailing list. Then when a real bug is agreed to exist, a concise description of the bug can be put here on sourceforge. ---------------------------------------------------------------------- Comment By: Nick Jacobson (nickjacobson) Date: 2006-01-29 16:04 Message: Logged In: YES user_id=1067650 Thanks for the info; I didn't know that about Excel. Still, shouldn't it return "5" or "5." instead of "5.0"? ---------------------------------------------------------------------- Comment By: John Machin (sjmachin) Date: 2006-01-29 15:44 Message: Logged In: YES user_id=480138 "When you read in an integer from an Excel cell": no such concept. Excel "number" format is floating point. When you assigned 5 to the cell, it was correctly stored as a floating point number. The value in the cell was then correctly retrieved as a floating point number. This is not a problem with pywin32. VBA and every other method of programmatic access to Excel or reading Excel files would (or should!) do the same thing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1418081&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-01-29 21:14:46
|
Bugs item #1418081, was opened at 2006-01-30 07:06 Message generated for change (Comment added) made by sjmachin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1418081&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: Nick Jacobson (nickjacobson) Assigned to: Nobody/Anonymous (nobody) Summary: Reads float from Excel cell instead of int Initial Comment: When you read in an integer from an Excel cell, it is type float. And printing it will print e.g. "5.0" instead of "5". example: from win32com.client import Dispatch xlApp = Dispatch("Excel.Application") xlApp.Visible = 1 xlApp.Workbooks.Add() xlApp.ActiveSheet.Cells(1,1).Value = 5 print xlApp.ActiveSheet.Cells(1,1).Value print type(xlApp.ActiveSheet.Cells(1,1).Value) raw_input("paused") xlApp.Quit() This returns: 5.0 <type 'float'> paused I'm using Python 2.4.2 and Excel 2003 Pro. ---------------------------------------------------------------------- Comment By: John Machin (sjmachin) Date: 2006-01-30 08:14 Message: Logged In: YES user_id=480138 Again, it's nothing to do with pywin32. This is standard Python. >>> print float(5) 5.0 >>> Perhaps you might like to discuss perceived bugs in the pywin32 mailing list. Then when a real bug is agreed to exist, a concise description of the bug can be put here on sourceforge. ---------------------------------------------------------------------- Comment By: Nick Jacobson (nickjacobson) Date: 2006-01-30 08:04 Message: Logged In: YES user_id=1067650 Thanks for the info; I didn't know that about Excel. Still, shouldn't it return "5" or "5." instead of "5.0"? ---------------------------------------------------------------------- Comment By: John Machin (sjmachin) Date: 2006-01-30 07:44 Message: Logged In: YES user_id=480138 "When you read in an integer from an Excel cell": no such concept. Excel "number" format is floating point. When you assigned 5 to the cell, it was correctly stored as a floating point number. The value in the cell was then correctly retrieved as a floating point number. This is not a problem with pywin32. VBA and every other method of programmatic access to Excel or reading Excel files would (or should!) do the same thing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1418081&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-01-29 21:04:47
|
Bugs item #1418081, was opened at 2006-01-29 15:06 Message generated for change (Comment added) made by nickjacobson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1418081&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: Nick Jacobson (nickjacobson) Assigned to: Nobody/Anonymous (nobody) Summary: Reads float from Excel cell instead of int Initial Comment: When you read in an integer from an Excel cell, it is type float. And printing it will print e.g. "5.0" instead of "5". example: from win32com.client import Dispatch xlApp = Dispatch("Excel.Application") xlApp.Visible = 1 xlApp.Workbooks.Add() xlApp.ActiveSheet.Cells(1,1).Value = 5 print xlApp.ActiveSheet.Cells(1,1).Value print type(xlApp.ActiveSheet.Cells(1,1).Value) raw_input("paused") xlApp.Quit() This returns: 5.0 <type 'float'> paused I'm using Python 2.4.2 and Excel 2003 Pro. ---------------------------------------------------------------------- >Comment By: Nick Jacobson (nickjacobson) Date: 2006-01-29 16:04 Message: Logged In: YES user_id=1067650 Thanks for the info; I didn't know that about Excel. Still, shouldn't it return "5" or "5." instead of "5.0"? ---------------------------------------------------------------------- Comment By: John Machin (sjmachin) Date: 2006-01-29 15:44 Message: Logged In: YES user_id=480138 "When you read in an integer from an Excel cell": no such concept. Excel "number" format is floating point. When you assigned 5 to the cell, it was correctly stored as a floating point number. The value in the cell was then correctly retrieved as a floating point number. This is not a problem with pywin32. VBA and every other method of programmatic access to Excel or reading Excel files would (or should!) do the same thing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1418081&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-01-29 20:44:16
|
Bugs item #1418081, was opened at 2006-01-30 07:06 Message generated for change (Comment added) made by sjmachin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1418081&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: Nick Jacobson (nickjacobson) Assigned to: Nobody/Anonymous (nobody) Summary: Reads float from Excel cell instead of int Initial Comment: When you read in an integer from an Excel cell, it is type float. And printing it will print e.g. "5.0" instead of "5". example: from win32com.client import Dispatch xlApp = Dispatch("Excel.Application") xlApp.Visible = 1 xlApp.Workbooks.Add() xlApp.ActiveSheet.Cells(1,1).Value = 5 print xlApp.ActiveSheet.Cells(1,1).Value print type(xlApp.ActiveSheet.Cells(1,1).Value) raw_input("paused") xlApp.Quit() This returns: 5.0 <type 'float'> paused I'm using Python 2.4.2 and Excel 2003 Pro. ---------------------------------------------------------------------- Comment By: John Machin (sjmachin) Date: 2006-01-30 07:44 Message: Logged In: YES user_id=480138 "When you read in an integer from an Excel cell": no such concept. Excel "number" format is floating point. When you assigned 5 to the cell, it was correctly stored as a floating point number. The value in the cell was then correctly retrieved as a floating point number. This is not a problem with pywin32. VBA and every other method of programmatic access to Excel or reading Excel files would (or should!) do the same thing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1418081&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-01-29 20:06:31
|
Bugs item #1418081, was opened at 2006-01-29 15:06 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1418081&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: Nick Jacobson (nickjacobson) Assigned to: Nobody/Anonymous (nobody) Summary: Reads float from Excel cell instead of int Initial Comment: When you read in an integer from an Excel cell, it is type float. And printing it will print e.g. "5.0" instead of "5". example: from win32com.client import Dispatch xlApp = Dispatch("Excel.Application") xlApp.Visible = 1 xlApp.Workbooks.Add() xlApp.ActiveSheet.Cells(1,1).Value = 5 print xlApp.ActiveSheet.Cells(1,1).Value print type(xlApp.ActiveSheet.Cells(1,1).Value) raw_input("paused") xlApp.Quit() This returns: 5.0 <type 'float'> paused I'm using Python 2.4.2 and Excel 2003 Pro. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1418081&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-01-26 13:30:32
|
Patches item #1195096, was opened at 2005-05-04 12:19 Message generated for change (Comment added) made by sschukat 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: Stefan Schukat (sschukat) Date: 2006-01-26 14:30 Message: Logged In: YES user_id=977439 I attached changed source for the 207 branch, with the suggested __future__ changed. I also added testcode and extended the PyCOMTest server. Stefan ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2006-01-10 11:04 Message: Logged In: YES user_id=14198 Thanks. Sorry I wasn't more clear - my idea ends up with the same end result, although also provides a transition plan to the New World Order! :) I don't think we do want to give the user a choice, as the user may be using libraries they have no control over, but which have made a different choice - like the "currency" issue, its important there is only one 'correct' thing we return. As mentioned, there is already existing __future_ related code dealing with currencies - if you could adopt your patch to something similar, it reduces any adaptation I need to make to the patch. Cheers ---------------------------------------------------------------------- Comment By: Stefan Schukat (sschukat) Date: 2006-01-10 09:53 Message: Logged In: YES user_id=977439 I already saw that problem and included therefore included pythoncom.SetSafeArrayType(bool) to set the flag programmatically. Your suggestion would lead to the same result. So I have no objections, but as long as the PySafeArrayType does successfully pass the tuple test suite I would give the user the choice. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2006-01-10 05: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 01: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-25 09:29:17
|
Feature Requests item #1414413, was opened at 2006-01-25 09: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=1414413&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: HVB bei TUP (hvb_tup) Assigned to: Nobody/Anonymous (nobody) Summary: Support JobObject functions Initial Comment: JobObject functions are very useful. The basic usage is: CreateJobObject CreateProcess suspended AddProcessToJobObject ResumeThread Then the child process you started belongs to the job, as well as any processes the child process starts (the property of belonging to a job is inherited). You can then kill the child process AND all grandchildren etc. using TerminateJobObject. This is very similar to the *nix world. References: MSDN: CreateJobObject TerminateJobObject AddProcessToJobObject QueryInformationJobObject http://www.microsoft.com/msj/0698/win320698.aspx see the last paragraphs mentioning JobObjects. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1414413&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-01-25 00:24:59
|
Bugs item #1414160, was opened at 2006-01-25 00:24 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=1414160&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: DDE sets off DEP (in demos and pythonwin too) Initial Comment: running C:\Python24\Lib\site-packages\win32 \Demos\dde\ddeserver.py causes DEP to go off for python. Similarly, DEP is set off for pythonwin. If you disable the DDE stuff in pythonwin, it does not set off DEP. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1414160&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-01-18 19:20:48
|
Feature Requests item #1409321, was opened at 2006-01-18 19:20 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=1409321&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: Greg Hazel (ghazel) Assigned to: Nobody/Anonymous (nobody) Summary: different newlines and non-existant files Initial Comment: Really two feature requests. 1. Support for '\n' newlines. I'd prefer that it open both and save unix-style, but any other feature which would allow me to work on unix-style newlines without damaging the file would be helpful. 2. Allow notepad-style "Cannot find the X.EXT file. Do you want to create a new file?" ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1409321&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-01-18 19:17:36
|
Bugs item #1398756, was opened at 2006-01-06 18:47 Message generated for change (Comment added) made by ghazel 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: Closed Resolution: Wont Fix 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. ---------------------------------------------------------------------- >Comment By: Greg Hazel (ghazel) Date: 2006-01-18 19:17 Message: Logged In: YES user_id=731668 Ah, I skipped over the fact that it was passing in the same buffer each time. The win32file.ReadFile behaviour makes sense to me now, thanks. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2006-01-10 22:22 Message: Logged In: YES user_id=14198 It appears that sample uses strlen() to determine how much to write. I'm not sure what you are asking for. ReadFile simply returns the exact same buffer that was passed to it. If you were writing this in C and passing (say) an 8k buffer to the function, there must be *some* way to determine how much of that is valid. My choice was to put that in the hands of the programmer. ---------------------------------------------------------------------- Comment By: Greg Hazel (ghazel) Date: 2006-01-10 17:55 Message: Logged In: YES user_id=731668 Why does this work differently form the native win32 api? This example doesn't use the overlapped api to retrieve the size of the valid data: http://msdn.microsoft.com/library/default.asp? url=/library/en- us/ipc/base/named_pipe_server_using_overlapped_i_o.asp ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2006-01-10 05:16 Message: Logged In: YES user_id=14198 This is the documented behaviour. From the pywin32 docs for ReadFile: While the operation is in progress, you can use the slice operations (object[:end]) to obtain the data read so far. You must use the OVERLAPPED API functions to determine how much of the data is valid. ---------------------------------------------------------------------- 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-17 20:57:45
|
Bugs item #1408486, was opened at 2006-01-17 14:57 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=1408486&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: v1.0 (example) Status: Open Resolution: None Priority: 5 Submitted By: Michael Kleehammer (mkleehammer) Assigned to: Nobody/Anonymous (nobody) Summary: WSARecv exception states the error is from "WSASend" Initial Comment: The WSARecv wrapper contains the following line: PyWin_SetAPIError("WSASend", rc); This shoud say WSARecv. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1408486&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-01-17 20:56:44
|
Bugs item #1408485, was opened at 2006-01-17 14: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=1408485&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: v1.0 (example) Status: Open Resolution: None Priority: 5 Submitted By: Michael Kleehammer (mkleehammer) Assigned to: Nobody/Anonymous (nobody) Summary: OVERLAPPED not hashable Initial Comment: Can we make the OVERLAPPED object hashable so it can be stored in a set or used as a dictionary key? As mentioned in a previous bug report, references to OVERLAPPED objects must be maintained even after posting it to the I/O subsystem. It is sometimes natural to want to store it in a set or dictionary. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1408485&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-01-17 20:54:55
|
Bugs item #1408484, was opened at 2006-01-17 14:54 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=1408484&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: v1.0 (example) Status: Open Resolution: None Priority: 5 Submitted By: Michael Kleehammer (mkleehammer) Assigned to: Nobody/Anonymous (nobody) Summary: Increment reference to OVERLAPPED Initial Comment: It would be helpful if the reference count of OVERLAPPED objects was incremented by each overlapped I/O function that "posts" the object to the OS. I'm using I/O completion ports with sockes, and if the OVERLAPPED object is not stored somewhere, it is deallocated even after calling WSASend or WSARecv. (This is my assumption based on an error message stating the OVERLAPPED was deallocated.) In the WSAxxx function cases, it makes sense to approach this as if the OVERLAPPED were "referenced" by the operating system. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1408484&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-01-12 23:05:49
|
Patches item #1404103, was opened at 2006-01-12 18:29 Message generated for change (Settings changed) made by tmick You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1404103&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: Trent Mick (tmick) Assigned to: Mark Hammond (mhammond) Summary: patch to setup.py for adsi build Initial Comment: Mark, I've found that the pywin32 build always fails while building the 'adsi' extension with the following error unless I add user32.lib and advapi32.lib to the setup of libraries for it (patch attached). ----------------------------------------------------- Creating library build\temp.win32-2.4\Release\com/win32comext/adsi/src\adsi.l ib and object build\temp.win32-2.4\Release\com/win32comext/adsi/src\adsi.exp PyADSIUtil.obj : error LNK2019: unresolved external symbol __imp__wsprintfA refe renced in function "struct _object * __cdecl PyADSIObject_FromADSVALUE(struct _a dsvalue &)" (?PyADSIObject_FromADSVALUE@@YAPAU_object@@AAU_adsvalue@@@Z) PyADSIUtil.obj : error LNK2019: unresolved external symbol __imp__GetSecurityDes criptorLength@4 referenced in function "struct _object * __cdecl PyADSIObject_Fr omADSVALUE(struct _adsvalue &)" (?PyADSIObject_FromADSVALUE@@YAPAU_object@@AAU_a dsvalue@@@Z) build\lib.win32-2.4\win32comext/adsi\adsi.pyd : fatal error LNK1120: 2 unresolve d externals error: command '"C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\bin\link .exe"' failed with exit status 1120 ----------------------------------------------------- My build is on Win2k with the "Windows Server 2003 SP1 SDK" (the latest according to http://www.microsoft.com/msdownload/platformsdk/sdkupdate/). I presume you (and Roger and others) don't have the same local patch in your setup.py so I'm not sure what the difference is that you can build and I cannot. Thoughts on add this patch? ---------------------------------------------------------------------- >Comment By: Trent Mick (tmick) Date: 2006-01-12 23:05 Message: Logged In: YES user_id=34892 Patch applied. /cvsroot/pywin32/pywin32/setup.py,v <-- setup.py new revision: 1.33; previous revision: 1.32 ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2006-01-12 23:04 Message: Logged In: YES user_id=771074 It appears I also had to add these to my setup.py to get it to build, although I can't tell exactly when I did so. Roger ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1404103&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-01-12 23:04:40
|
Patches item #1404103, was opened at 2006-01-12 13:29 Message generated for change (Comment added) made by rupole You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1404103&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: Trent Mick (tmick) Assigned to: Mark Hammond (mhammond) Summary: patch to setup.py for adsi build Initial Comment: Mark, I've found that the pywin32 build always fails while building the 'adsi' extension with the following error unless I add user32.lib and advapi32.lib to the setup of libraries for it (patch attached). ----------------------------------------------------- Creating library build\temp.win32-2.4\Release\com/win32comext/adsi/src\adsi.l ib and object build\temp.win32-2.4\Release\com/win32comext/adsi/src\adsi.exp PyADSIUtil.obj : error LNK2019: unresolved external symbol __imp__wsprintfA refe renced in function "struct _object * __cdecl PyADSIObject_FromADSVALUE(struct _a dsvalue &)" (?PyADSIObject_FromADSVALUE@@YAPAU_object@@AAU_adsvalue@@@Z) PyADSIUtil.obj : error LNK2019: unresolved external symbol __imp__GetSecurityDes criptorLength@4 referenced in function "struct _object * __cdecl PyADSIObject_Fr omADSVALUE(struct _adsvalue &)" (?PyADSIObject_FromADSVALUE@@YAPAU_object@@AAU_a dsvalue@@@Z) build\lib.win32-2.4\win32comext/adsi\adsi.pyd : fatal error LNK1120: 2 unresolve d externals error: command '"C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\bin\link .exe"' failed with exit status 1120 ----------------------------------------------------- My build is on Win2k with the "Windows Server 2003 SP1 SDK" (the latest according to http://www.microsoft.com/msdownload/platformsdk/sdkupdate/). I presume you (and Roger and others) don't have the same local patch in your setup.py so I'm not sure what the difference is that you can build and I cannot. Thoughts on add this patch? ---------------------------------------------------------------------- >Comment By: Roger Upole (rupole) Date: 2006-01-12 18:04 Message: Logged In: YES user_id=771074 It appears I also had to add these to my setup.py to get it to build, although I can't tell exactly when I did so. Roger ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1404103&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-01-12 22:35:10
|
Feature Requests item #1097745, was opened at 2005-01-07 05:11 Message generated for change (Comment added) made by rupole You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1097745&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: Next Release (example) >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Harald Armin Massa (ghum) Assigned to: Nobody/Anonymous (nobody) Summary: please expose Getservicebyname and getservicebykeyname Initial Comment: The win32service-module does not expose Getservicebyname and Getservicebykeyname of the win32api yet. Please expose them in future versions. ---------------------------------------------------------------------- >Comment By: Roger Upole (rupole) Date: 2006-01-12 17:35 Message: Logged In: YES user_id=771074 This should be covered by win32service.GetServiceDisplayName and win32service.GetServiceKeyName ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1097745&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-01-12 22:29:24
|
Feature Requests item #942500, was opened at 2004-04-26 12:49 Message generated for change (Comment added) made by rupole You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=942500&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: BlackCat (cmelv) Assigned to: Nobody/Anonymous (nobody) Summary: GetVolumePathName missing Initial Comment: Just noticed that GetVolumePathName is missing, and thought I'd better report this as most of the other file/volume management APIs are there so presumably its an oversight! :0) ---------------------------------------------------------------------- >Comment By: Roger Upole (rupole) Date: 2006-01-12 17:29 Message: Logged In: YES user_id=771074 This was added to win32file some time ago ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2004-04-28 18:31 Message: Logged In: YES user_id=14198 Slightly trickier than normal as it is not available on Win9x, so will need to use LoadLibrary(). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=942500&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-01-12 22:25:51
|
Feature Requests item #1397932, was opened at 2006-01-05 12:47 Message generated for change (Settings changed) made by rupole 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: Closed >Resolution: Fixed Priority: 5 Submitted By: Markus Klinik (brudermarkus) Assigned to: Roger Upole (rupole) 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. :) ---------------------------------------------------------------------- >Comment By: Roger Upole (rupole) Date: 2006-01-12 17:25 Message: Logged In: YES user_id=771074 Rev 1.42 of shell.cpp now allows multiple filenames to be passed in as a single string ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2006-01-11 18:49 Message: Logged In: YES user_id=14198 Thanks Roger - they both sound fine to me! ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2006-01-11 10:40 Message: Logged In: YES user_id=771074 It might actually be easier to just let callers construct their own string with filenames separated by NULL's. Interestingly, this would work right now except for the fact that _tcscpy is used which stops copying characters when it finds a NULL byte. So basically, replace tcscpy with memcpy and remove the sequence check altogether. It'll take longer to put together a test case than it will to change the C++ code. Mark, if you're okay with this I'll go ahead and do it. Alternately, win32api already has code to create a double- null terminated sequence of strings for REG_MULTI_SZ. We could move it into pywintypes so it's available for anyplace else this type of string is used. Roger ---------------------------------------------------------------------- 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-12 19:09:20
|
Bugs item #1273738, was opened at 2005-08-25 18:52 Message generated for change (Comment added) made by haridsv You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1273738&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: Hari Krishna Dara (haridsv) Assigned to: Nobody/Anonymous (nobody) Summary: atexit not called for pythonservice (win32) Initial Comment: I have a couple of functions registered with atexit which work fine when the program is executed on command-line. But when I run the same as a windows service, and stop the service using service interface, these hooks never get call backs. The service does exit normally (at least my program doesn't do os._exit() and there are no exceptions). I am using ActiveState's distribution of python, but I would imagine this is non-specific. Here is the version information: ActivePython 2.4.1 Build 247 (ActiveState Corp.) based on Python 2.4.1 (#65, Jun 20 2005, 17:01:55) [MSC v.1310 32 bit (Intel)] on win32 As a workaround I am calling the atexit._run_exitfuncs() manually before returning from SvcDoRun() for now. ---------------------------------------------------------------------- >Comment By: Hari Krishna Dara (haridsv) Date: 2006-01-12 11:09 Message: Logged In: YES user_id=344432 Doesn't seem to be. In my case I don't see a call back at all, so the issue is not about when it gets called. ---------------------------------------------------------------------- Comment By: David S. Rushby (woodsplitter) Date: 2006-01-12 10:50 Message: Logged In: YES user_id=414645 I wonder if this bug is related to the following issue? http://groups.google.com/group/comp.lang.python/browse_thread/thread/fe9e426650764ed9/972ecadc2d6fcf5b#972ecadc2d6fcf5b ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1273738&group_id=78018 |
2 messages has been excluded from this view by a project administrator.
