pywin32-bugs Mailing List for Python for Windows Extensions (Page 34)
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...> - 2010-07-19 09:32:53
|
Bugs item #3029949, was opened at 2010-07-15 14:09 Message generated for change (Comment added) made by erikjanssen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3029949&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: com Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Erik Janssen (erikjanssen) Assigned to: Nobody/Anonymous (nobody) Summary: Type information lost in enumeration of COM objects Initial Comment: I am using the pywin32-214.win32-py2.7.exe distribution. I notice type information is not always available. In the following 3-line snippet 'SearchResult' is an enumerator of objects of a certain type'. Coding it like this everything is fine and python knows the type of f: for i in range(0,result.SearchResults.Count): f = result.SearchResults.Item(i) print f.StartTime, "-", f.EndTime, f.Camera.CameraName But in the following code, imho preffered, python complains about f being IUnknown and can't continue: for f in result.SearchResults: print f print f.StartTime, "-", f.EndTime, f.Camera.CameraName In the generated files (gencache) all information seems to be available, as in the IDL of the COM component. I can supply lot's of additional information but I don't know what is making sense and what isn't. ---------------------------------------------------------------------- Comment By: Erik Janssen (erikjanssen) Date: 2010-07-19 11:32 Message: Here is the relevant IDL, assuming that is what you refer to: 223 interface IFootageDescriptionEnumerator : IDispatch 224 { 225 [id(DISPID_NEWENUM), propget] HRESULT _NewEnum([out, retval] IUnknown** Enumerator); 226 [id(DISPID_VALUE), propget] HRESULT Item([in] VARIANT Index, [out, retval] IFootageDescription **FootageInfo); 227 [id(0x00000001), propget] HRESULT Count([out, retval] long * Count); 228 }; I notice that another enumarator works fine in python, it is in the IDL declared as: 131 interface ICameraEnumerator : IDispatch{ 132 [id(0xfffffffc), propget] HRESULT _NewEnum([out, retval] IUnknown **CameraEnum); 133 [id(00000000), propget] HRESULT Item([in] int Index, [out, retval] ICamera **CameraInfo); 134 [id(00000000), propput] HRESULT Item([in] int Index, [in] ICamera *CameraInfo); 135 [id(0x00000001), propget] HRESULT Count([out, retval] int *Count); Hope that helps. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2010-07-15 18:40 Message: Does the item have a _NewEnum method? If so, how is it defined? Otherwise I am surprised IUnknown is returned - it should behave identically to when you call Item() manually. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3029949&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-07-15 16:40:39
|
Bugs item #3029949, was opened at 2010-07-15 22:09 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3029949&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: com Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Erik Janssen (erikjanssen) Assigned to: Nobody/Anonymous (nobody) Summary: Type information lost in enumeration of COM objects Initial Comment: I am using the pywin32-214.win32-py2.7.exe distribution. I notice type information is not always available. In the following 3-line snippet 'SearchResult' is an enumerator of objects of a certain type'. Coding it like this everything is fine and python knows the type of f: for i in range(0,result.SearchResults.Count): f = result.SearchResults.Item(i) print f.StartTime, "-", f.EndTime, f.Camera.CameraName But in the following code, imho preffered, python complains about f being IUnknown and can't continue: for f in result.SearchResults: print f print f.StartTime, "-", f.EndTime, f.Camera.CameraName In the generated files (gencache) all information seems to be available, as in the IDL of the COM component. I can supply lot's of additional information but I don't know what is making sense and what isn't. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2010-07-16 02:40 Message: Does the item have a _NewEnum method? If so, how is it defined? Otherwise I am surprised IUnknown is returned - it should behave identically to when you call Item() manually. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3029949&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-07-15 12:09:05
|
Bugs item #3029949, was opened at 2010-07-15 14:09 Message generated for change (Tracker Item Submitted) made by erikjanssen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3029949&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: com Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Erik Janssen (erikjanssen) Assigned to: Nobody/Anonymous (nobody) Summary: Type information lost in enumeration of COM objects Initial Comment: I am using the pywin32-214.win32-py2.7.exe distribution. I notice type information is not always available. In the following 3-line snippet 'SearchResult' is an enumerator of objects of a certain type'. Coding it like this everything is fine and python knows the type of f: for i in range(0,result.SearchResults.Count): f = result.SearchResults.Item(i) print f.StartTime, "-", f.EndTime, f.Camera.CameraName But in the following code, imho preffered, python complains about f being IUnknown and can't continue: for f in result.SearchResults: print f print f.StartTime, "-", f.EndTime, f.Camera.CameraName In the generated files (gencache) all information seems to be available, as in the IDL of the COM component. I can supply lot's of additional information but I don't know what is making sense and what isn't. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3029949&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-07-13 09:32:24
|
Bugs item #3028647, was opened at 2010-07-12 16:24 Message generated for change (Comment added) made by rupole You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3028647&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Greg Hazel (ghazel) Assigned to: Nobody/Anonymous (nobody) Summary: pythonwin keeps opening new preocesses Initial Comment: Every time I run "pythonwin foo", PythonWin opens a new process and a new window. Previously it would open "foo" in any existing process, MDI style. I'm not sure what the culprit is, since I just installed PythonWin build 214. I also just started running Windows 7 64bit (I was previously on 32bit). ---------------------------------------------------------------------- >Comment By: Roger Upole (rupole) Date: 2010-07-13 04:32 Message: The dde module will build for amd64 using a modified project file, but I haven't tried to integrate the necessary changes into the setup script yet. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2010-07-12 19:34 Message: This is because the DDE module hjasn't been ported to the 64bit world. It may be fixed in the future (probably by re-implementing the functionality using something other than DDE), but I really wouldn't hold my breath for me to get a round tuit for this specific problem... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3028647&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-07-13 00:34:43
|
Bugs item #3028647, was opened at 2010-07-13 07:24 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3028647&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Greg Hazel (ghazel) Assigned to: Nobody/Anonymous (nobody) Summary: pythonwin keeps opening new preocesses Initial Comment: Every time I run "pythonwin foo", PythonWin opens a new process and a new window. Previously it would open "foo" in any existing process, MDI style. I'm not sure what the culprit is, since I just installed PythonWin build 214. I also just started running Windows 7 64bit (I was previously on 32bit). ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2010-07-13 10:34 Message: This is because the DDE module hjasn't been ported to the 64bit world. It may be fixed in the future (probably by re-implementing the functionality using something other than DDE), but I really wouldn't hold my breath for me to get a round tuit for this specific problem... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3028647&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-07-12 21:24:14
|
Bugs item #3028647, was opened at 2010-07-12 21:24 Message generated for change (Tracker Item Submitted) made by ghazel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3028647&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Greg Hazel (ghazel) Assigned to: Nobody/Anonymous (nobody) Summary: pythonwin keeps opening new preocesses Initial Comment: Every time I run "pythonwin foo", PythonWin opens a new process and a new window. Previously it would open "foo" in any existing process, MDI style. I'm not sure what the culprit is, since I just installed PythonWin build 214. I also just started running Windows 7 64bit (I was previously on 32bit). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3028647&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-07-12 18:55:22
|
Bugs item #3026596, was opened at 2010-07-07 22:50 Message generated for change (Comment added) made by farshizzo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3026596&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: win32 Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Farshid Lashkari (farshizzo) Assigned to: Nobody/Anonymous (nobody) Summary: DLL files should not include manifest Initial Comment: I just installed version 214 for Python 2.7 and noticed the included dll/pyd files have embedded manifests that specify the runtime library. This makes it difficult to distribute the files on machines that don't have the 9.0 runtime library already installed. All the extension modules that come with the standard library are built without embedded manifests. Shouldn't pywin32 follow the same behavior? ---------------------------------------------------------------------- >Comment By: Farshid Lashkari (farshizzo) Date: 2010-07-12 18:55 Message: Thanks for the information! Are there any plans to provide an updated build soon? ---------------------------------------------------------------------- Comment By: Christoph Gohlke (cjgohlke) Date: 2010-07-09 18:19 Message: A rebuild with the final release of Python 2.7 should take care of that. However, the pythoncom27.dll and pywintypes27.dll will likely fail to register during installation and not function as COM server. See http://bugs.python.org/issue7833. A build with embedded manifests removed from the PYD (but not from DLL) files is at http://www.lfd.uci.edu/~gohlke/pythonlibs/#pywin32. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3026596&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-07-12 10:59:04
|
Bugs item #3026235, was opened at 2010-07-07 04:01 Message generated for change (Comment added) made by rupole You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3026235&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: com Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tim Golden (tjgolden) Assigned to: Nobody/Anonymous (nobody) Summary: adsi not built under py3k Initial Comment: The adsi module isn't being built under py3k (it's specifically excluded by setup.py). Is this because of a lack of round tuits, or is there something which would prevent it ever working? ---------------------------------------------------------------------- >Comment By: Roger Upole (rupole) Date: 2010-07-12 05:59 Message: The biggest impediment is the custom version of swig used to generate com extension modules in 2.x. The source is apparently no longer available, and it will take a good deal of work to duplicate what it generates in our custom py3k port of swig. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3026235&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-07-11 22:14:11
|
Patches item #3028046, was opened at 2010-07-11 07:02 Message generated for change (Comment added) made by rupole You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3028046&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: Out of Date Priority: 5 Private: No Submitted By: Harald Armin Massa (ghum) Assigned to: Nobody/Anonymous (nobody) Summary: patch to reenable makepy.py / against missing encoding error Initial Comment: in Version 213 of pywin32 within win32com\client\genpy.py on line 814, within def do_gen_file_header(self): there is the assertion: # You must provide a file correctly configured for writing unicode. # We assert this is it may indicate somewhere in pywin32 that needs # upgrading. assert self.file.encoding, self.file But using makepy.py via makepy.py -v -o OLE_Excel11.py "Microsoft Excel 11.0 Object Library" this assertion fails ... as self.file.encoding is None The culprit is makepy.py itself: starting at line 367ff there is: if outputName is not None: path = os.path.dirname(outputName) if path is not '' and not os.path.exists(path): os.makedirs(path) f = open(outputName, "w") else: f = None and this "f" will have encoding=None I patched this to: if outputName is not None: path = os.path.dirname(outputName) if path is not '' and not os.path.exists(path): os.makedirs(path) #~ f = open(outputName, "w") import codecs f= codecs.open(outputName, mode="w",encoding="mbcs") else: f = None use codecs to create a file with mbcs encoding. After this, I get a nice create ole_excel11.py file, with the good line # -*- coding: mbcs -*- at the beginning. I propose to put this fix into makepy.py for everybody; (any rights you need are hereby granted) ---------------------------------------------------------------------- >Comment By: Roger Upole (rupole) Date: 2010-07-11 17:14 Message: Thanks for the patch! However, this is already fixed in r1.29. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3028046&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-07-11 12:02:06
|
Patches item #3028046, was opened at 2010-07-11 14:02 Message generated for change (Tracker Item Submitted) made by ghum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3028046&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Harald Armin Massa (ghum) Assigned to: Nobody/Anonymous (nobody) Summary: patch to reenable makepy.py / against missing encoding error Initial Comment: in Version 213 of pywin32 within win32com\client\genpy.py on line 814, within def do_gen_file_header(self): there is the assertion: # You must provide a file correctly configured for writing unicode. # We assert this is it may indicate somewhere in pywin32 that needs # upgrading. assert self.file.encoding, self.file But using makepy.py via makepy.py -v -o OLE_Excel11.py "Microsoft Excel 11.0 Object Library" this assertion fails ... as self.file.encoding is None The culprit is makepy.py itself: starting at line 367ff there is: if outputName is not None: path = os.path.dirname(outputName) if path is not '' and not os.path.exists(path): os.makedirs(path) f = open(outputName, "w") else: f = None and this "f" will have encoding=None I patched this to: if outputName is not None: path = os.path.dirname(outputName) if path is not '' and not os.path.exists(path): os.makedirs(path) #~ f = open(outputName, "w") import codecs f= codecs.open(outputName, mode="w",encoding="mbcs") else: f = None use codecs to create a file with mbcs encoding. After this, I get a nice create ole_excel11.py file, with the good line # -*- coding: mbcs -*- at the beginning. I propose to put this fix into makepy.py for everybody; (any rights you need are hereby granted) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3028046&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-07-09 18:19:45
|
Bugs item #3026596, was opened at 2010-07-07 15:50 Message generated for change (Comment added) made by cjgohlke You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3026596&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: win32 Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Farshid Lashkari (farshizzo) Assigned to: Nobody/Anonymous (nobody) Summary: DLL files should not include manifest Initial Comment: I just installed version 214 for Python 2.7 and noticed the included dll/pyd files have embedded manifests that specify the runtime library. This makes it difficult to distribute the files on machines that don't have the 9.0 runtime library already installed. All the extension modules that come with the standard library are built without embedded manifests. Shouldn't pywin32 follow the same behavior? ---------------------------------------------------------------------- Comment By: Christoph Gohlke (cjgohlke) Date: 2010-07-09 11:19 Message: A rebuild with the final release of Python 2.7 should take care of that. However, the pythoncom27.dll and pywintypes27.dll will likely fail to register during installation and not function as COM server. See http://bugs.python.org/issue7833. A build with embedded manifests removed from the PYD (but not from DLL) files is at http://www.lfd.uci.edu/~gohlke/pythonlibs/#pywin32. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3026596&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-07-07 22:50:10
|
Bugs item #3026596, was opened at 2010-07-07 22:50 Message generated for change (Tracker Item Submitted) made by farshizzo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3026596&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: win32 Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Farshid Lashkari (farshizzo) Assigned to: Nobody/Anonymous (nobody) Summary: DLL files should not include manifest Initial Comment: I just installed version 214 for Python 2.7 and noticed the included dll/pyd files have embedded manifests that specify the runtime library. This makes it difficult to distribute the files on machines that don't have the 9.0 runtime library already installed. All the extension modules that come with the standard library are built without embedded manifests. Shouldn't pywin32 follow the same behavior? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3026596&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-07-07 09:01:27
|
Bugs item #3026235, was opened at 2010-07-07 09:01 Message generated for change (Tracker Item Submitted) made by tjgolden You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3026235&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: com Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tim Golden (tjgolden) Assigned to: Nobody/Anonymous (nobody) Summary: adsi not built under py3k Initial Comment: The adsi module isn't being built under py3k (it's specifically excluded by setup.py). Is this because of a lack of round tuits, or is there something which would prevent it ever working? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3026235&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-07-02 09:35:20
|
Feature Requests item #3023833, was opened at 2010-07-01 16:19 Message generated for change (Settings changed) made by hvbargen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=3023833&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: 3 Private: No Submitted By: H. von Bargen (hvbargen) Assigned to: Nobody/Anonymous (nobody) Summary: MAPI support for PR_REPLY_RECIPIENT_ENTRIES Initial Comment: I was able to replace most of my existing C++ based sendmail.exe program with a Python script using pythoncom.mapi. Great work! However, I am not able to specify a different Reply-To address, because the mapi package does not support the FLATENTRY and FLATENTRYLIST structures. Note: Working C++ code for specifying a different Reply-To address can be found at http://support.microsoft.com/kb/300531 ---------------------------------------------------------------------- >Comment By: H. von Bargen (hvbargen) Date: 2010-07-02 11:35 Message: OK, as a workaround it is possible to modify the reply-to address with a bit low-level code (see below). So, my problem is solved. Anyway, perhaps this could be a nice addition to the mapiutil package. code fragment to set the replyTo-Address def makeentry(typ, name_addr): return ((mapitags.PR_RECIPIENT_TYPE, typ), #(mapitags.PR_DISPLAY_NAME_A, name_addr), (mapitags.PR_DISPLAY_NAME_W, name_addr), ) # ReplyTo-Address if replyTo: # replyTo is a unicode string replyToList = address_book.ResolveName(0, mapi.MAPI_UNICODE, None, [makeentry(mapi.MAPI_TO, replyTo)]) props = [(mapitags.PR_REPLY_RECIPIENT_NAMES, replyTo), ] message.SetProps(props) replyToAddr = replyToList[0] for (pt, pv) in replyToAddr: if pt == mapitags.PR_ENTRYID: entryid = pv break #print "reply-to entryid (len %s): %r" % (len(entryid), entryid) flatentry = struct.pack("i", len(entryid)) + entryid #print "flatentry:", repr(flatentry) flatentrylist = struct.pack("ii", 1, len(flatentry)) + flatentry props = [ (mapitags.PR_REPLY_RECIPIENT_ENTRIES, flatentrylist), ] message.SetProps(props) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=3023833&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-07-01 14:19:11
|
Feature Requests item #3023833, was opened at 2010-07-01 16:19 Message generated for change (Tracker Item Submitted) made by hvbargen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=3023833&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: com Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: H. von Bargen (hvbargen) Assigned to: Nobody/Anonymous (nobody) Summary: MAPI support for PR_REPLY_RECIPIENT_ENTRIES Initial Comment: I was able to replace most of my existing C++ based sendmail.exe program with a Python script using pythoncom.mapi. Great work! However, I am not able to specify a different Reply-To address, because the mapi package does not support the FLATENTRY and FLATENTRYLIST structures. Note: Working C++ code for specifying a different Reply-To address can be found at http://support.microsoft.com/kb/300531 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=3023833&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-06-29 22:06:41
|
Feature Requests item #739624, was opened at 2003-05-19 10:38 Message generated for change (Settings changed) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=739624&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Mark Hammond (mhammond) Assigned to: Nobody/Anonymous (nobody) Summary: Implement SetConsoleCtrlHandler Initial Comment: Includes a patch and discussion. ---------------------------------------------------------------------- Comment By: Ziga Seilnacht (zseil) Date: 2010-06-30 00:35 Message: SetConsoleCtrlHandler was added to win32api module on 10.10.2004. Can this feature request be closed? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2003-05-19 10:39 Message: Logged In: YES user_id=14198 we talked about SetConsoleCtrlHandler a while ago. >Sorry for the delay, but yes, that sounds like a reasonable > approach. The only problem is with the "last-registered, > first-called" approach, meaning second calls to your > extensions function would not have the same effect as a > second call to the real SetConsoleCtrlHandler - but yeah, > I see no reasonable solution worth the effort. > >The GIL management will not be trivial, and may require > you to get - err - creative :) The GIL wasn't too hard in the end - the handler is called in the context of a new thread, and there is precedent for that in the source :) I have attached a simplistic version of a SetConsoleCtrlHandler. It allows to set *one* handler function and doesn't implement the list I originally had in mind. The code works works, but its behaviour is far from the behaviour of SetConsoleCtrlHandler in a C program. This is probably due to the signal handling of Python itself, and I can't see what can be done about it. The current code is useful to me, and it could be improved to handle multiple handlers properly (by installing different C handlers, thereby preserving the order), but it would be rather hard to document the behaviour, since it clashes with the Python internal signal handling. For example, take: import cch # this is the console controle handler module import time def handler(type): print type return False cch.SetConsoleCtrlHandler(handler, True) time.sleep(60) If you execute this, and hit Ctrl-C before the 60 seconds are up, the handler will dutifully print 0, but the process won't be killed - because time.sleep() cannot be killed in Python. If you do a sys.exit() in the handler function, it will also not terminate the process, since sys.exit() only works from the main thread. Basically, I have no clue how the Python SetConsoleCtrlHandler should be documented. It would need a link to description of standard Python signal handling to be generally useful, but I am not aware of any such documentation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=739624&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-06-29 14:35:45
|
Feature Requests item #739624, was opened at 2003-05-19 02:38 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=739624&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mark Hammond (mhammond) Assigned to: Nobody/Anonymous (nobody) Summary: Implement SetConsoleCtrlHandler Initial Comment: Includes a patch and discussion. ---------------------------------------------------------------------- Comment By: Ziga Seilnacht (zseil) Date: 2010-06-29 16:35 Message: SetConsoleCtrlHandler was added to win32api module on 10.10.2004. Can this feature request be closed? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2003-05-19 02:39 Message: Logged In: YES user_id=14198 we talked about SetConsoleCtrlHandler a while ago. >Sorry for the delay, but yes, that sounds like a reasonable > approach. The only problem is with the "last-registered, > first-called" approach, meaning second calls to your > extensions function would not have the same effect as a > second call to the real SetConsoleCtrlHandler - but yeah, > I see no reasonable solution worth the effort. > >The GIL management will not be trivial, and may require > you to get - err - creative :) The GIL wasn't too hard in the end - the handler is called in the context of a new thread, and there is precedent for that in the source :) I have attached a simplistic version of a SetConsoleCtrlHandler. It allows to set *one* handler function and doesn't implement the list I originally had in mind. The code works works, but its behaviour is far from the behaviour of SetConsoleCtrlHandler in a C program. This is probably due to the signal handling of Python itself, and I can't see what can be done about it. The current code is useful to me, and it could be improved to handle multiple handlers properly (by installing different C handlers, thereby preserving the order), but it would be rather hard to document the behaviour, since it clashes with the Python internal signal handling. For example, take: import cch # this is the console controle handler module import time def handler(type): print type return False cch.SetConsoleCtrlHandler(handler, True) time.sleep(60) If you execute this, and hit Ctrl-C before the 60 seconds are up, the handler will dutifully print 0, but the process won't be killed - because time.sleep() cannot be killed in Python. If you do a sys.exit() in the handler function, it will also not terminate the process, since sys.exit() only works from the main thread. Basically, I have no clue how the Python SetConsoleCtrlHandler should be documented. It would need a link to description of standard Python signal handling to be generally useful, but I am not aware of any such documentation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=739624&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-06-29 14:28:13
|
Patches item #3022832, was opened at 2010-06-29 15:55 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3022832&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ziga Seilnacht (zseil) Assigned to: Nobody/Anonymous (nobody) Summary: add win32File.WSAEnumNetworkEvents Initial Comment: WSAEventSelect is not very useful without the accompanying WSAEnumNetworkEvents, which reports the exact network events that caused the event associated with a socket to become signaled. This patch adds it. The added function reports network events as a dict, which deviates slightly from the winapi interface, but is more convenient. The patch includes some tests that show the intended usage of this function. ---------------------------------------------------------------------- Comment By: Ziga Seilnacht (zseil) Date: 2010-06-29 16:28 Message: This would also close feature request #1527583: https://sourceforge.net/tracker/?func=detail&aid=1527583&group_id=78018&atid=551957 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3022832&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-06-29 14:26:29
|
Feature Requests item #1527583, was opened at 2006-07-24 09:11 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1527583&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: win32 Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: david arnold (dja) Assigned to: Nobody/Anonymous (nobody) Summary: Add support for WSAEnumNetworkEvents Initial Comment: WSAEnumNetworkEvents is used to determine the state of a socket after it has signaled an Event to indicate that its state has changed. Its useful for integrating sockets with other objects (handles, events, etc) in a main loop. Currently, WSAEventSelect is supported, as is WSAAsyncSelect (which is used to direct state change notifications to a Window), but not WSAEnumNetworkEvents. It'd be great if this could be added ... ---------------------------------------------------------------------- Comment By: Ziga Seilnacht (zseil) Date: 2010-06-29 16:26 Message: See patch #3022832: https://sourceforge.net/tracker/?func=detail&aid=3022832&group_id=78018&atid=551956 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1527583&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-06-29 13:55:38
|
Patches item #3022832, was opened at 2010-06-29 15:55 Message generated for change (Tracker Item Submitted) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3022832&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ziga Seilnacht (zseil) Assigned to: Nobody/Anonymous (nobody) Summary: add win32File.WSAEnumNetworkEvents Initial Comment: WSAEventSelect is not very useful without the accompanying WSAEnumNetworkEvents, which reports the exact network events that caused the event associated with a socket to become signaled. This patch adds it. The added function reports network events as a dict, which deviates slightly from the winapi interface, but is more convenient. The patch includes some tests that show the intended usage of this function. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3022832&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-06-18 17:30:25
|
Bugs item #3017949, was opened at 2010-06-18 04:15 Message generated for change (Comment added) made by rupole You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3017949&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pythonwin Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Greg Hazel (ghazel) Assigned to: Nobody/Anonymous (nobody) Summary: pythonwin leaks directory handles, holds directory open Initial Comment: Pythonwin seems to keep an open handle to a directory after opening and closing a file. Here's a demonstration: ... make sure PythonWin is closed ... J:\>mkdir test J:\>cd test J:\test>echo > foo J:\test>pythonwin foo ... close 'foo' in PythonWin, but do not close PythonWin ... J:\test>cd .. J:\>rmdir /S /Q test The process cannot access the file because it is being used by another process. J:\handle test Handle v3.42 Copyright (C) 1997-2008 Mark Russinovich Sysinternals - www.sysinternals.com Pythonwin.exe pid: 5468 8: J:\test Pythonwin.exe pid: 5468 208: J:\test J:\>handle -p pythonwin Handle v3.42 Copyright (C) 1997-2008 Mark Russinovich Sysinternals - www.sysinternals.com ------------------------------------------------------------------------------ Pythonwin.exe pid: 5468 greg-x60\Greg 8: File (---) J:\test C: File (---) C:\Windows\winsxs\x86_microsoft.vc90.mfc_1fc8b3b9a1e18e3b_9.0.30729.4974_none_4bf89ae8bf9a48c0 10: File (---) C:\Windows\winsxs\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4974_none_50940634bcb759cb 18: File (---) C:\Windows\winsxs\x86_microsoft.windows.common-controls_6595b64144ccf1df_5.82.7600.16385_none_ebf82fc36c758ad5 5C: File (---) C:\Windows\winsxs\x86_microsoft.vc90.mfcloc_1fc8b3b9a1e18e3b_9.0.30729.4974_none_497745fb754785d2 84: File (---) C:\Windows\winsxs\x86_microsoft.vc90.mfc_1fc8b3b9a1e18e3b_9.0.30729.4974_none_4bf89ae8bf9a48c0 88: File (---) C:\Windows\winsxs\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4974_none_50940634bcb759cb 8C: File (---) C:\Windows\winsxs\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4974_none_50940634bcb759cb 90: File (---) C:\Windows\winsxs\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4974_none_50940634bcb759cb C8: File (---) C:\Windows\System32\en-US\KernelBase.dll.mui D8: File (---) C:\Windows\winsxs\x86_microsoft.vc90.mfc_1fc8b3b9a1e18e3b_9.0.30729.4974_none_4bf89ae8bf9a48c0 DC: File (---) C:\Windows\winsxs\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4974_none_50940634bcb759cb 100: File (---) C:\Windows\winsxs\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4974_none_50940634bcb759cb 110: File (---) C:\Windows\Fonts\StaticCache.dat 120: File (---) C:\Windows\winsxs\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7600.16385_none_421189da2b7fabfc 124: File (---) C:\Windows\winsxs\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4974_none_50940634bcb759cb 130: Section \Sessions\1\BaseNamedObjects\windows_shell_global_counters 138: File (---) C:\Windows\winsxs\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4974_none_50940634bcb759cb 14C: File (---) C:\Windows\winsxs\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7600.16385_none_421189da2b7fabfc 16C: Section \BaseNamedObjects\__ComCatalogCache__ 178: Section \BaseNamedObjects\__ComCatalogCache__ 188: Section \BaseNamedObjects\windows_shell_global_counters 208: File (---) J:\test It will continue to add one handle to J:\test for each time J:\test\foo is opened. ---------------------------------------------------------------------- >Comment By: Roger Upole (rupole) Date: 2010-06-18 12:30 Message: The thread that monitors files for external changes wasn't releasing its change notification handle. Fixed in document.py r1.15. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3017949&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-06-18 09:15:47
|
Bugs item #3017949, was opened at 2010-06-18 09:15 Message generated for change (Tracker Item Submitted) made by ghazel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3017949&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pythonwin Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Greg Hazel (ghazel) Assigned to: Nobody/Anonymous (nobody) Summary: pythonwin leaks directory handles, holds directory open Initial Comment: Pythonwin seems to keep an open handle to a directory after opening and closing a file. Here's a demonstration: ... make sure PythonWin is closed ... J:\>mkdir test J:\>cd test J:\test>echo > foo J:\test>pythonwin foo ... close 'foo' in PythonWin, but do not close PythonWin ... J:\test>cd .. J:\>rmdir /S /Q test The process cannot access the file because it is being used by another process. J:\handle test Handle v3.42 Copyright (C) 1997-2008 Mark Russinovich Sysinternals - www.sysinternals.com Pythonwin.exe pid: 5468 8: J:\test Pythonwin.exe pid: 5468 208: J:\test J:\>handle -p pythonwin Handle v3.42 Copyright (C) 1997-2008 Mark Russinovich Sysinternals - www.sysinternals.com ------------------------------------------------------------------------------ Pythonwin.exe pid: 5468 greg-x60\Greg 8: File (---) J:\test C: File (---) C:\Windows\winsxs\x86_microsoft.vc90.mfc_1fc8b3b9a1e18e3b_9.0.30729.4974_none_4bf89ae8bf9a48c0 10: File (---) C:\Windows\winsxs\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4974_none_50940634bcb759cb 18: File (---) C:\Windows\winsxs\x86_microsoft.windows.common-controls_6595b64144ccf1df_5.82.7600.16385_none_ebf82fc36c758ad5 5C: File (---) C:\Windows\winsxs\x86_microsoft.vc90.mfcloc_1fc8b3b9a1e18e3b_9.0.30729.4974_none_497745fb754785d2 84: File (---) C:\Windows\winsxs\x86_microsoft.vc90.mfc_1fc8b3b9a1e18e3b_9.0.30729.4974_none_4bf89ae8bf9a48c0 88: File (---) C:\Windows\winsxs\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4974_none_50940634bcb759cb 8C: File (---) C:\Windows\winsxs\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4974_none_50940634bcb759cb 90: File (---) C:\Windows\winsxs\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4974_none_50940634bcb759cb C8: File (---) C:\Windows\System32\en-US\KernelBase.dll.mui D8: File (---) C:\Windows\winsxs\x86_microsoft.vc90.mfc_1fc8b3b9a1e18e3b_9.0.30729.4974_none_4bf89ae8bf9a48c0 DC: File (---) C:\Windows\winsxs\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4974_none_50940634bcb759cb 100: File (---) C:\Windows\winsxs\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4974_none_50940634bcb759cb 110: File (---) C:\Windows\Fonts\StaticCache.dat 120: File (---) C:\Windows\winsxs\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7600.16385_none_421189da2b7fabfc 124: File (---) C:\Windows\winsxs\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4974_none_50940634bcb759cb 130: Section \Sessions\1\BaseNamedObjects\windows_shell_global_counters 138: File (---) C:\Windows\winsxs\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4974_none_50940634bcb759cb 14C: File (---) C:\Windows\winsxs\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7600.16385_none_421189da2b7fabfc 16C: Section \BaseNamedObjects\__ComCatalogCache__ 178: Section \BaseNamedObjects\__ComCatalogCache__ 188: Section \BaseNamedObjects\windows_shell_global_counters 208: File (---) J:\test It will continue to add one handle to J:\test for each time J:\test\foo is opened. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3017949&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-06-09 05:16:20
|
Bugs item #3013558, was opened at 2010-06-09 05:16 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3013558&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: installation Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: KurzedMetal () Assigned to: Nobody/Anonymous (nobody) Summary: install fails when python is installed only for current user Initial Comment: Installing pywin32-214 on Python 2.6 (installed for current user) on windows seven (all 32bits) makes post-install script fails with an esoteric error. I found this when i was trying to deploy python silently (using msiexec /qn swtich) but without using ALLUSERS=1 to install it system-wide. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3013558&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-06-05 22:20:04
|
Bugs item #2999657, was opened at 2010-05-10 17:58 Message generated for change (Comment added) made by rupole You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2999657&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pythonwin Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: help() failure Initial Comment: This pretty much says it all: help("os.urandom")Firing event 'ProcessEnter' failed. Traceback (most recent call last): File "C:\Python26\Lib\site-packages\pythonwin\pywin\scintilla\bindings.py", line 142, in fire rc = binding.handler(*args) File "C:\Python26\Lib\site-packages\pythonwin\pywin\framework\interact.py", line 453, in ProcessEnterEvent if self.HandleSpecialLine(): return 0 File "C:\Python26\Lib\site-packages\pythonwin\pywin\framework\winout.py", line 152, in HandleSpecialLine line = self.GetLine(lineNo-1) File "C:\Python26\Lib\site-packages\pythonwin\pywin\scintilla\control.py", line 373, in GetLine return self.GetTextRange(start, end) File "C:\Python26\Lib\site-packages\pythonwin\pywin\scintilla\control.py", line 362, in GetTextRange ret = ret.decode(default_scintilla_encoding) File "C:\Python26\lib\encodings\utf_8.py", line 16, in decode return codecs.utf_8_decode(input, errors, True) UnicodeDecodeError: 'utf8' codec can't decode bytes in position 0-2: invalid data Help->About reports pywin32 build214 Running Python 2.6.5 from python.org locally. ---------------------------------------------------------------------- >Comment By: Roger Upole (rupole) Date: 2010-06-05 17:20 Message: I can't reproduce this. Can you provide some more specifics on how to make it happen ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2999657&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-06-05 22:11:46
|
Bugs item #3009827, was opened at 2010-06-01 04:17 Message generated for change (Comment added) made by rupole You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3009827&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: Works For Me Priority: 5 Private: No Submitted By: Anders J. Munch (andersjm) Assigned to: Nobody/Anonymous (nobody) Summary: QueryDosDevice fails with error 234 Initial Comment: After attaching an additional USB device, win32file.QueryDosDevice(None) suddenly started failing with the exception: pywintypes.error: (234, 'QueryDosDevice', 'Der er flere data til r\xe5dighed.') Error 234 is ERROR_MORE_DATA, which indicates that the supplied buffer is too small. (The text translates to 'More data is available.) Looking at win32file.i, MyQueryDosDevice expects a too small buffer to result in ERROR_INSUFFICIENT_BUFFER; so presumably treating ERROR_MORE_DATA as synonymous will fix it. (Python 2.4.4, pywin32-208.) ---------------------------------------------------------------------- >Comment By: Roger Upole (rupole) Date: 2010-06-05 17:11 Message: Closing per submitter's suggestion. ---------------------------------------------------------------------- Comment By: Anders J. Munch (andersjm) Date: 2010-06-04 01:50 Message: I checked on the (previously) failing system: len(win32file.QueryDosDevice(None))==10222 -- so clearly I was wrong to point to the 8192 initial buffer size. Also I can't reproduce it anymore, whether it was the nightly powercycle or a slightly different mix of USB devices that did it, I don't know. That means I can't test a fix, so I suggest you close it as 'works for me'. ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2010-06-03 16:05 Message: It already does on my system: >>> d=win32file.QueryDosDevice(None) >>> len(d) 8593 I also tried hardcoding the initial buffer sizes lower, still succeeds. ---------------------------------------------------------------------- Comment By: Anders J. Munch (andersjm) Date: 2010-06-03 14:35 Message: XP. To reproduce you need for len(win32file.QueryDosDevice(None)) to exceed the initial buffer size of 8192 - or reduce the initial buffer size so that it does. ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2010-06-03 13:49 Message: I can't reproduce this on XP, Vista, or Windows 7. Which OS are you on ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3009827&group_id=78018 |
2 messages has been excluded from this view by a project administrator.
