pywin32-bugs Mailing List for Python for Windows Extensions (Page 43)
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...> - 2009-04-18 21:22:14
|
Feature Requests item #1507080, was opened at 2006-06-16 00:37 Message generated for change (Comment added) made by rupole You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1507080&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: win32 Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Pavel Pergamenshchik (ppergame) Assigned to: Nobody/Anonymous (nobody) Summary: Add ConnectEx Initial Comment: It would be nice to have the binding for ConnectEx. It is available only on WinXP and higher. The function pointer must be retrieved at runtime with WSAIoctl. ---------------------------------------------------------------------- >Comment By: Roger Upole (rupole) Date: 2009-04-18 16:22 Message: This has been added to win32file in the latest build. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1507080&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2009-04-18 21:16:42
|
Feature Requests item #1236275, was opened at 2005-07-11 14:44 Message generated for change (Comment added) made by rupole You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1236275&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: Vaughn Seward (cflat7) Assigned to: Nobody/Anonymous (nobody) Summary: Sorting of the objects/defs in Class List Panel Initial Comment: I like the idea of the Class List panel (panel at the left-hand side of the code) but it is sorted alphabetically. I don't necessarily organize the classes and defines in my modules alphabetically. I therefore find the panel confusing and as a result cannot use it. Why not provide an option to sort it the same way that it appears in the code? ~Vaughn ---------------------------------------------------------------------- >Comment By: Roger Upole (rupole) Date: 2009-04-18 16:16 Message: I wouldn't mind having this myself. This page contains some code to sort by original module order: http://effbot.org/librarybook/pyclbr.htm (changing to feature request) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1236275&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2009-04-18 20:00:42
|
Bugs item #1297822, was opened at 2005-09-21 10:04 Message generated for change (Comment added) made by rupole You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1297822&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: Oleg Noga (oleg_noga) Assigned to: Nobody/Anonymous (nobody) Summary: smart-backspace brokes backspacing for non-ascii chars Initial Comment: if trying to backspace non-ascii characters need to press backspace twice for each character. One pressing produces strange rectangle. Second removes it. Quick solution is to turn of smart backspace: just comment out one line in pythonwin\pywin\default.cfg ------------ #Back = <<smart-backspace>> ---------------------------------------------------------------------- >Comment By: Roger Upole (rupole) Date: 2009-04-18 15:00 Message: This was same issue as #2618277, fixed now. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1297822&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2009-04-18 19:47:30
|
Bugs item #2555414, was opened at 2009-02-01 05:41 Message generated for change (Comment added) made by rupole You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2555414&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: Mark Hammond (mhammond) Assigned to: Nobody/Anonymous (nobody) Summary: "save" in the interactive window silently does nothing Initial Comment: >From Mark Tolonen: When the focus is in the interactive window and Save is selected, the file save dialog comes up with Interactive Window" as the default file name. If I then click Save no file is actually created. IIRC, this has been happening even in older versions of PythonWin, but it seems like it should save the contents of the interactive window, or the button should be disabled when the interactive window has focus. ---------------------------------------------------------------------- >Comment By: Roger Upole (rupole) Date: 2009-04-18 14:47 Message: This is fixed now, see winout.py r1.17. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2555414&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2009-04-17 18:54:40
|
Bugs item #2747402, was opened at 2009-04-09 06:29 Message generated for change (Comment added) made by rupole You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2747402&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: arisdon (arisdon) Assigned to: Nobody/Anonymous (nobody) Summary: pythonwin 212 crashes at start Initial Comment: Pythonwin 212 halts at start with 'PyWin32 has encountered a problem and needs to close' window on Windows XP after 'Browse Pythonpath' option has been used. Problem can be resolved temporarily as follows: 1. Rename C:\Python26\Lib\site-packages\pythonwin\scintilla.dll to .dll.old 2. Run Pythonwin.exe... which halts with a Python Traceback complaining of the absent scintilla.dll 3. Restore C:\Python26\Lib\site-packages\pythonwin\scintilla.dll to its correct name 4. Pythonwin.exe now functions correctly unless and until 'Browse Pythonpath' is used again. I have checked this behaviour in a clean virtual machine, Windows XP patched up to date. I installed freshly downloaded copies of: 1. python-2.6.1.msi 2. pywin32-212.win32-py2.6.exe ---------------------------------------------------------------------- >Comment By: Roger Upole (rupole) Date: 2009-04-17 13:54 Message: This appears to related to the problem with saving toolbar states in the registry. If you delete the registry key HKCU\Software\Python 2.6\Python for Win32\ToolbarDefault-Summary the crash goes away. It appears to be already fixed in build 213, although there have been so many changes I can't identify exactly where. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2747402&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2009-04-14 03:06:49
|
Bugs item #2726657, was opened at 2009-04-02 14:01 Message generated for change (Comment added) made by kpoman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2726657&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: Patricio Stegmann (kpoman) Assigned to: Nobody/Anonymous (nobody) Summary: getting PyIUnknown for a known return type Initial Comment: Hello all, I am getting a strange behaviour for a generated clsid: class IAcquisitionDevice(DispatchBaseClass): # SOME CODE STRIPPED HERE # Result is of type IAcquisitionDeviceInfo def EnumerateDevices(self): return self._ApplyTypes_(1610743823, 1, (8201, 0), (), u'EnumerateDevices', '{7ED03FE9-4DCC-4F5D-BDF8-4D4D22C1FA10}',) def GetNumberOfDevices(self): return self._oleobj_.InvokeTypes(1610743822, LCID, 1, (3, 0), (),) # SOME CODE STRIPPED HERE # THEN SOME LINES LATER class IAcquisitionDeviceInfo(DispatchBaseClass): CLSID = IID('{7ED03FE9-4DCC-4F5D-BDF8-4D4D22C1FA10}') coclass_clsid = IID('{DDD89560-8B0E-4D6F-9BDF-7E14068C1DEB}') _prop_map_get_ = { "Properties": (1610743809, 2, (8, 0), (), "Properties", None), "SerialNumber": (1610743808, 2, (8, 0), (), "SerialNumber", None), } _prop_map_put_ = { } I saved all this on a mk4 file. Then I perform some tests: >>> import mk4 >>> dev = mk4.AcquisitionDevice() >>> print dev.GetNumberOfDevices() 1 >>> print dev.EnumerateDevices() (<PyIUnknown at 0x00BCB4C0 with obj at 0x0509FF90>,) >>> I dont know why I am getting a PyIUnknown if it should now I am returning IAcquisitionDevice object ! I guess there is some error somewhere and I really need to fix it. From that ActiveX documentation I see this: void EnumerateDevices (AcquisitionDeviceInfo infos[]) enumerate all connected acquisition devices So it should return an array of infos and not only one info (this array contains infos for all the different compatible devices). So somehow the python cache file got wrongly generated. How can I fix this please ? How to declare it should be an array of deviceinfos instead of a single deviceinfo ? Thank you all for any help, Patricio ---------------------------------------------------------------------- >Comment By: Patricio Stegmann (kpoman) Date: 2009-04-14 05:06 Message: Mark, thanks for your help ! I didnt see your response until today (just saw comment 1). The function should return some kind of enumeration, it says this in the documentation: void EnumerateDevices (AcquisitionDeviceInfo infos[]) enumerate all connected acquisition devices I just did some tests: >>> import mk4 >>> dev = mk4.AcquisitionDevice() >>> print dev.EnumerateDevices() (<PyIUnknown at 0x00C11330 with obj at 0x04C90010>,) >>> print dev.GetDescriptor() Traceback (most recent call last): File "<stdin>", line 1, in <module> File "mk4.py", line 121, in GetDescriptor ret = self._oleobj_.InvokeTypes(1610743824, LCID, 1, (9, 0), ((8, 1),),deviceSerialNumber pywintypes.com_error: (-2147024809, 'El par\xe1metro no es correcto.', None, None) >>> print dev.GetDescriptor('') <win32com.gen_py.Sagem SÚcuritÚ MorphoKit SDK.IAcquisitionDeviceDescriptor instance at 0x12810360> >>> So GetDescriptor is working as expected, an IAcquisitionDeviceDescriptor. But EnumerateDevices is giving some list-like object, composed of PyIUnknown objects. I tried putting an __init__ into the class IAcquisitionDeviceInfo but nothing got printed. Is it returned as a list of PyIUnknown because the generated com wrapper (via makepy) did explictly said that it should return a DeviceInfo and not a list of DeviceInfo's then win32com got cheated by itself ? Is there a way to declare/update on the generated that it should return a collection of DeviceInfos and thus have it detect it as a collection and cast it correctly ? Is there a way to cast manually to AcquisitionDeviceInfo ? Doing the following fails: >>> from pywintypes import IID >>> devinfo = dev.EnumerateDevices()[0] >>> print devinfo <PyIUnknown at 0x00C11480 with obj at 0x04C9FFB0> >>> devinfo.QueryInterface(IID('{7ED03FE9-4DCC-4F5D-BDF8-4D4D22C1FA10}')) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: There is no interface object registered that supports this IID >>> Is there a way to view if there is some error on the activex itself ? Some free tool to check on the assembly what it is supposed to return ? Because there could be a bug in the activex itself. FYI it was generated from this command: regasm /tlb /codebase Sagem.MorphoKit.dll Please let me know how I can debug this ! ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2009-04-06 13:58 Message: Do you have any information about the API exposed by this object. Looking at: # Result is of type IAcquisitionDeviceInfo def EnumerateDevices(self): return self._ApplyTypes_(1610743823, 1, (8201, 0), (), u'EnumerateDevices', '{7ED03FE9-4DCC-4F5D-BDF8-4D4D22C1FA10}',) It seems something (maybe pywin32, maybe the object) is confused about the enumeration. A function named 'EnumerateDevices' would be expected to return a list/enum of IAcquisitionDeviceInfo's, not an IAcquisitionDeviceInfo directly, and I suspect this is the root of the problem. To confirm, adding a print to the __init__ of IAcquisitionDeviceInfo might tell you if we are trying to create such an object, but failing (presumably as we have an enum) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2726657&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2009-04-09 11:29:54
|
Bugs item #2747402, was opened at 2009-04-09 11:29 Message generated for change (Tracker Item Submitted) made by arisdon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2747402&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: arisdon (arisdon) Assigned to: Nobody/Anonymous (nobody) Summary: pythonwin 212 crashes at start Initial Comment: Pythonwin 212 halts at start with 'PyWin32 has encountered a problem and needs to close' window on Windows XP after 'Browse Pythonpath' option has been used. Problem can be resolved temporarily as follows: 1. Rename C:\Python26\Lib\site-packages\pythonwin\scintilla.dll to .dll.old 2. Run Pythonwin.exe... which halts with a Python Traceback complaining of the absent scintilla.dll 3. Restore C:\Python26\Lib\site-packages\pythonwin\scintilla.dll to its correct name 4. Pythonwin.exe now functions correctly unless and until 'Browse Pythonpath' is used again. I have checked this behaviour in a clean virtual machine, Windows XP patched up to date. I installed freshly downloaded copies of: 1. python-2.6.1.msi 2. pywin32-212.win32-py2.6.exe ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2747402&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2009-04-06 17:50:00
|
Bugs item #2736298, was opened at 2009-04-05 23:55 Message generated for change (Comment added) made by rupole You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2736298&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: markt (metolone) Assigned to: Nobody/Anonymous (nobody) Summary: input() crashes pythonwin 213 py3.0 Initial Comment: Any input() command, whether by interactive window, running or debugging script crashes pythonwin. I'm using Python 3.0.1 and pywin32-213.win32-py3.0. It works fine on Python 2.6.1 and pywin32-213.win32-py2.6. ---------------------------------------------------------------------- >Comment By: Roger Upole (rupole) Date: 2009-04-06 12:49 Message: This has been fixed since the last release. See \Pythonwin\pywin\framework\app.py r1.17. ---------------------------------------------------------------------- Comment By: markt (metolone) Date: 2009-04-06 09:51 Message: A simple "x=input()" in the interactive window causes a hard crash. Faulting application pythonwin.exe, version 3.0.213.0, faulting module python30.dll, version 3.0.1150.1013, fault address 0x000923c3. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2009-04-06 06:50 Message: Works for me - what do you mean by "crashes"? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2736298&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2009-04-06 14:51:12
|
Bugs item #2736298, was opened at 2009-04-05 21:55 Message generated for change (Comment added) made by metolone You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2736298&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: markt (metolone) Assigned to: Nobody/Anonymous (nobody) Summary: input() crashes pythonwin 213 py3.0 Initial Comment: Any input() command, whether by interactive window, running or debugging script crashes pythonwin. I'm using Python 3.0.1 and pywin32-213.win32-py3.0. It works fine on Python 2.6.1 and pywin32-213.win32-py2.6. ---------------------------------------------------------------------- >Comment By: markt (metolone) Date: 2009-04-06 07:51 Message: A simple "x=input()" in the interactive window causes a hard crash. Faulting application pythonwin.exe, version 3.0.213.0, faulting module python30.dll, version 3.0.1150.1013, fault address 0x000923c3. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2009-04-06 04:50 Message: Works for me - what do you mean by "crashes"? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2736298&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2009-04-06 12:20:57
|
Bugs item #2686042, was opened at 2009-03-13 21:59 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2686042&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: blair sutton (bsdz) Assigned to: Nobody/Anonymous (nobody) Summary: pythonwin documentation out of date Initial Comment: The Pythonwin GUI Environment documentation, specifically the Command Line Arguments are not in sync with those described in the source code file intpyapp.py. For example, in docs /runargs is actually /rundlg in the code. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2009-04-06 22:20 Message: Thanks! Checking in doc/guienvironment.html; new revision: 1.2; previous revision: 1.1 Checking in pywin/framework/intpyapp.py; new revision: 1.17; previous revision: 1.16 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2686042&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2009-04-06 11:59:46
|
Bugs item #2726704, was opened at 2009-04-02 23:31 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2726704&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: Pending Resolution: None Priority: 5 Private: No Submitted By: Christoffer Jezek (shkvall) Assigned to: Nobody/Anonymous (nobody) Summary: Debugger fills Registry with 100s of ToolbarDefault-Bar-n Initial Comment: PythonWin creates hundreds of ToolbarDefault-Bar-n keys in the registry once the debugger is invoked (either by debug or post-mortem) and the 'go' or 'close' button is clicked. This seems to be the same problem as in bugid #1017504. Environment: PythonWin Build 210 PythonWin 2.5.1 (r251:1.3, Sep 3 2007, 11:08:48) [MSC v.1310 32 bit (Intel)] on win32. Windows XP Pro ver.2002, SP2. Regards Christoffer ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2009-04-06 21:59 Message: Please try a later version - there have been a number of fixed since build 210, including some related to this. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2726704&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2009-04-06 11:58:32
|
Bugs item #2726657, was opened at 2009-04-02 23:01 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2726657&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: Patricio Stegmann (kpoman) Assigned to: Nobody/Anonymous (nobody) Summary: getting PyIUnknown for a known return type Initial Comment: Hello all, I am getting a strange behaviour for a generated clsid: class IAcquisitionDevice(DispatchBaseClass): # SOME CODE STRIPPED HERE # Result is of type IAcquisitionDeviceInfo def EnumerateDevices(self): return self._ApplyTypes_(1610743823, 1, (8201, 0), (), u'EnumerateDevices', '{7ED03FE9-4DCC-4F5D-BDF8-4D4D22C1FA10}',) def GetNumberOfDevices(self): return self._oleobj_.InvokeTypes(1610743822, LCID, 1, (3, 0), (),) # SOME CODE STRIPPED HERE # THEN SOME LINES LATER class IAcquisitionDeviceInfo(DispatchBaseClass): CLSID = IID('{7ED03FE9-4DCC-4F5D-BDF8-4D4D22C1FA10}') coclass_clsid = IID('{DDD89560-8B0E-4D6F-9BDF-7E14068C1DEB}') _prop_map_get_ = { "Properties": (1610743809, 2, (8, 0), (), "Properties", None), "SerialNumber": (1610743808, 2, (8, 0), (), "SerialNumber", None), } _prop_map_put_ = { } I saved all this on a mk4 file. Then I perform some tests: >>> import mk4 >>> dev = mk4.AcquisitionDevice() >>> print dev.GetNumberOfDevices() 1 >>> print dev.EnumerateDevices() (<PyIUnknown at 0x00BCB4C0 with obj at 0x0509FF90>,) >>> I dont know why I am getting a PyIUnknown if it should now I am returning IAcquisitionDevice object ! I guess there is some error somewhere and I really need to fix it. From that ActiveX documentation I see this: void EnumerateDevices (AcquisitionDeviceInfo infos[]) enumerate all connected acquisition devices So it should return an array of infos and not only one info (this array contains infos for all the different compatible devices). So somehow the python cache file got wrongly generated. How can I fix this please ? How to declare it should be an array of deviceinfos instead of a single deviceinfo ? Thank you all for any help, Patricio ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2009-04-06 21:58 Message: Do you have any information about the API exposed by this object. Looking at: # Result is of type IAcquisitionDeviceInfo def EnumerateDevices(self): return self._ApplyTypes_(1610743823, 1, (8201, 0), (), u'EnumerateDevices', '{7ED03FE9-4DCC-4F5D-BDF8-4D4D22C1FA10}',) It seems something (maybe pywin32, maybe the object) is confused about the enumeration. A function named 'EnumerateDevices' would be expected to return a list/enum of IAcquisitionDeviceInfo's, not an IAcquisitionDeviceInfo directly, and I suspect this is the root of the problem. To confirm, adding a print to the __init__ of IAcquisitionDeviceInfo might tell you if we are trying to create such an object, but failing (presumably as we have an enum) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2726657&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2009-04-06 11:50:11
|
Bugs item #2736298, was opened at 2009-04-06 14:55 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2736298&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: markt (metolone) Assigned to: Nobody/Anonymous (nobody) Summary: input() crashes pythonwin 213 py3.0 Initial Comment: Any input() command, whether by interactive window, running or debugging script crashes pythonwin. I'm using Python 3.0.1 and pywin32-213.win32-py3.0. It works fine on Python 2.6.1 and pywin32-213.win32-py2.6. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2009-04-06 21:50 Message: Works for me - what do you mean by "crashes"? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2736298&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2009-04-06 04:55:58
|
Bugs item #2736298, was opened at 2009-04-05 21:55 Message generated for change (Tracker Item Submitted) made by metolone You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2736298&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: markt (metolone) Assigned to: Nobody/Anonymous (nobody) Summary: input() crashes pythonwin 213 py3.0 Initial Comment: Any input() command, whether by interactive window, running or debugging script crashes pythonwin. I'm using Python 3.0.1 and pywin32-213.win32-py3.0. It works fine on Python 2.6.1 and pywin32-213.win32-py2.6. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2736298&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2009-04-04 18:39:08
|
Patches item #2731813, was opened at 2009-04-04 20:39 Message generated for change (Tracker Item Submitted) made by fhoech You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=2731813&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: Florian Höch (fhoech) Assigned to: Nobody/Anonymous (nobody) Summary: Patch to add win32api.GetICMProfile to pywin32 build 213 Initial Comment: This patch allows to get the ICM profile filename of a given device context via win32api.GetICMProfile(hdc) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=2731813&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2009-04-02 14:54:59
|
Bugs item #2726852, was opened at 2009-04-02 16:04 Message generated for change (Comment added) made by kwill You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2726852&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: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: d<3vid seaward (kwill) Assigned to: Nobody/Anonymous (nobody) Summary: 213 install fails on Vista (when it didn't before) Initial Comment: While installing pywin32-213 I get the following error. I have previously been able to install pywin32 without problems (not sure what version number I installed last, though). I tried installing 211 and got the same error. "The procedure entry point ?PyWinObject_AsHANDLE@@YAHPAU_object@@PAPAXH@Z could not be located in the dynamic link library pywintypes25.dll" Traceback (most recent call last): File "<string>", line 601, in <module> File "<string>", line 313, in install ImportError: DLL load failed: The specified procedure could not be found. *** run_installscript: internal error 0xFFFFFFFF *** I am running Vista Home Premium 32, with all recent updates installed. ---------------------------------------------------------------------- >Comment By: d<3vid seaward (kwill) Date: 2009-04-02 16:54 Message: This seems to have been caused by previously installing via an egg and now trying to install via the exe. Removed the egg and now can install OK. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2726852&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2009-04-02 14:04:11
|
Bugs item #2726852, was opened at 2009-04-02 16:04 Message generated for change (Tracker Item Submitted) made by kwill You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2726852&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: d<3vid seaward (kwill) Assigned to: Nobody/Anonymous (nobody) Summary: 213 install fails on Vista (when it didn't before) Initial Comment: While installing pywin32-213 I get the following error. I have previously been able to install pywin32 without problems (not sure what version number I installed last, though). I tried installing 211 and got the same error. "The procedure entry point ?PyWinObject_AsHANDLE@@YAHPAU_object@@PAPAXH@Z could not be located in the dynamic link library pywintypes25.dll" Traceback (most recent call last): File "<string>", line 601, in <module> File "<string>", line 313, in install ImportError: DLL load failed: The specified procedure could not be found. *** run_installscript: internal error 0xFFFFFFFF *** I am running Vista Home Premium 32, with all recent updates installed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2726852&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2009-04-02 12:31:53
|
Bugs item #2726704, was opened at 2009-04-02 14:31 Message generated for change (Tracker Item Submitted) made by shkvall You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2726704&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: Christoffer Jezek (shkvall) Assigned to: Nobody/Anonymous (nobody) Summary: Debugger fills Registry with 100s of ToolbarDefault-Bar-n Initial Comment: PythonWin creates hundreds of ToolbarDefault-Bar-n keys in the registry once the debugger is invoked (either by debug or post-mortem) and the 'go' or 'close' button is clicked. This seems to be the same problem as in bugid #1017504. Environment: PythonWin Build 210 PythonWin 2.5.1 (r251:1.3, Sep 3 2007, 11:08:48) [MSC v.1310 32 bit (Intel)] on win32. Windows XP Pro ver.2002, SP2. Regards Christoffer ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2726704&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2009-04-02 12:01:58
|
Bugs item #2726657, was opened at 2009-04-02 14:01 Message generated for change (Tracker Item Submitted) made by kpoman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2726657&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: Patricio Stegmann (kpoman) Assigned to: Nobody/Anonymous (nobody) Summary: getting PyIUnknown for a known return type Initial Comment: Hello all, I am getting a strange behaviour for a generated clsid: class IAcquisitionDevice(DispatchBaseClass): # SOME CODE STRIPPED HERE # Result is of type IAcquisitionDeviceInfo def EnumerateDevices(self): return self._ApplyTypes_(1610743823, 1, (8201, 0), (), u'EnumerateDevices', '{7ED03FE9-4DCC-4F5D-BDF8-4D4D22C1FA10}',) def GetNumberOfDevices(self): return self._oleobj_.InvokeTypes(1610743822, LCID, 1, (3, 0), (),) # SOME CODE STRIPPED HERE # THEN SOME LINES LATER class IAcquisitionDeviceInfo(DispatchBaseClass): CLSID = IID('{7ED03FE9-4DCC-4F5D-BDF8-4D4D22C1FA10}') coclass_clsid = IID('{DDD89560-8B0E-4D6F-9BDF-7E14068C1DEB}') _prop_map_get_ = { "Properties": (1610743809, 2, (8, 0), (), "Properties", None), "SerialNumber": (1610743808, 2, (8, 0), (), "SerialNumber", None), } _prop_map_put_ = { } I saved all this on a mk4 file. Then I perform some tests: >>> import mk4 >>> dev = mk4.AcquisitionDevice() >>> print dev.GetNumberOfDevices() 1 >>> print dev.EnumerateDevices() (<PyIUnknown at 0x00BCB4C0 with obj at 0x0509FF90>,) >>> I dont know why I am getting a PyIUnknown if it should now I am returning IAcquisitionDevice object ! I guess there is some error somewhere and I really need to fix it. From that ActiveX documentation I see this: void EnumerateDevices (AcquisitionDeviceInfo infos[]) enumerate all connected acquisition devices So it should return an array of infos and not only one info (this array contains infos for all the different compatible devices). So somehow the python cache file got wrongly generated. How can I fix this please ? How to declare it should be an array of deviceinfos instead of a single deviceinfo ? Thank you all for any help, Patricio ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2726657&group_id=78018 |
|
From: Mark H. <mha...@sk...> - 2009-04-02 07:57:07
|
Sorry, this list isn't for bug reports, but for automated messages from the
sourceforge bug tracker. Please open a bug at sourceforge - I'm afraid its
not all all obvious why you are seeing this, and it will probably be
necessary to 'print debug' what is going on.
Cheers,
Mark
From: Patricio Stegmann [mailto:kp...@ho...]
Sent: Thursday, 2 April 2009 2:21 PM
To: pyw...@li...
Subject: [pywin32-bugs] getting PyIUnknown for a known return type
Hello all,
I am getting a strange behaviour for a generated clsid:
class IAcquisitionDevice(DispatchBaseClass):
# SOME CODE STRIPPED HERE
# Result is of type IAcquisitionDeviceInfo
def EnumerateDevices(self):
return self._ApplyTypes_(1610743823, 1, (8201, 0), (),
u'EnumerateDevices', '{7ED03FE9-4DCC-4F5D-BDF8-4D4D22C1FA10}',)
def GetNumberOfDevices(self):
return self._oleobj_.InvokeTypes(1610743822, LCID, 1, (3, 0), (),)
# SOME CODE STRIPPED HERE
# THEN SOME LINES LATER
class IAcquisitionDeviceInfo(DispatchBaseClass):
CLSID = IID('{7ED03FE9-4DCC-4F5D-BDF8-4D4D22C1FA10}')
coclass_clsid = IID('{DDD89560-8B0E-4D6F-9BDF-7E14068C1DEB}')
_prop_map_get_ = {
"Properties": (1610743809, 2, (8, 0), (), "Properties", None),
"SerialNumber": (1610743808, 2, (8, 0), (), "SerialNumber", None),
}
_prop_map_put_ = {
}
I saved all this on a mk4 file.
Then I perform some tests:
>>> import mk4
>>> dev = mk4.AcquisitionDevice()
>>> print dev.GetNumberOfDevices()
1
>>> print dev.EnumerateDevices()
(<PyIUnknown at 0x00BCB4C0 with obj at 0x0509FF90>,)
>>>
I dont know why I am getting a PyIUnknown if it should now I am returning
IAcquisitionDevice object !
I guess there is some error somewhere and I really need to fix it. From that
ActiveX documentation I see this:
void EnumerateDevices (AcquisitionDeviceInfo infos[])
enumerate all connected acquisition devices
So it should return an array of infos and not only one info (this array
contains infos for all the different compatible devices).
So somehow the python cache file got wrongly generated. How can I fix this
please ? How to declare it should be an array of deviceinfos instead of a
single deviceinfo ?
Thank you all for any help,
Patricio
_____
See all the ways you can stay connected to
<http://www.microsoft.com/windows/windowslive/default.aspx> friends and
family
|
|
From: Patricio S. <kp...@ho...> - 2009-04-02 03:21:43
|
Hello all,
I am getting a strange behaviour for a generated clsid:
class IAcquisitionDevice(DispatchBaseClass):
# SOME CODE STRIPPED HERE
# Result is of type IAcquisitionDeviceInfo
def EnumerateDevices(self):
return self._ApplyTypes_(1610743823, 1, (8201, 0), (), u'EnumerateDevices', '{7ED03FE9-4DCC-4F5D-BDF8-4D4D22C1FA10}',)
def GetNumberOfDevices(self):
return self._oleobj_.InvokeTypes(1610743822, LCID, 1, (3, 0), (),)
# SOME CODE STRIPPED HERE
# THEN SOME LINES LATER
class IAcquisitionDeviceInfo(DispatchBaseClass):
CLSID = IID('{7ED03FE9-4DCC-4F5D-BDF8-4D4D22C1FA10}')
coclass_clsid = IID('{DDD89560-8B0E-4D6F-9BDF-7E14068C1DEB}')
_prop_map_get_ = {
"Properties": (1610743809, 2, (8, 0), (), "Properties", None),
"SerialNumber": (1610743808, 2, (8, 0), (), "SerialNumber", None),
}
_prop_map_put_ = {
}
I saved all this on a mk4 file.
Then I perform some tests:
>>> import mk4
>>> dev = mk4.AcquisitionDevice()
>>> print dev.GetNumberOfDevices()
1
>>> print dev.EnumerateDevices()
(<PyIUnknown at 0x00BCB4C0 with obj at 0x0509FF90>,)
>>>
I dont know why I am getting a PyIUnknown if it should now I am returning IAcquisitionDevice object !
I guess there is some error somewhere and I really need to fix it. From that ActiveX documentation I see this:
void EnumerateDevices (AcquisitionDeviceInfo infos[])
enumerate all connected acquisition devices
So it should return an array of infos and not only one info (this array contains infos for all the different compatible devices).
So somehow the python cache file got wrongly generated. How can I fix this please ? How to declare it should be an array of deviceinfos instead of a single deviceinfo ?
Thank you all for any help,
Patricio
_________________________________________________________________
Show them the way! Add maps and directions to your party invites.
http://www.microsoft.com/windows/windowslive/products/events.aspx |
|
From: SourceForge.net <no...@so...> - 2009-04-01 12:48:49
|
Bugs item #2693152, was opened at 2009-03-18 20:01 Message generated for change (Comment added) made by rupole You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2693152&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: pythoncom fails to import due to CreateURLMonikerEx Initial Comment: Noticed on the 'bzr' mailing list which recently released a binary using build 213 """ Entry point to procedure CreateURLMonikerEx does not found in DLL urlmon.dll I've tried to install on Windows 2000 machine. """ Note this machine was running the Russian version which may be relevant, as MSDN says it should be there... ---------------------------------------------------------------------- >Comment By: Roger Upole (rupole) Date: 2009-04-01 07:48 Message: This should be fixed in pythoncom.cpp r 1.60. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2009-03-31 03:37 Message: >From private mail: second -- i noticed a bug filed against pywin32, build 213. just wanted you to know that we're seeing the same problem here on an old win2k SP4 vm, which ships the urlmon.dll at the link below. dependency walker indicates it can't import CreateURLMonikerEx, and hacking up pythoncom_CreateURLMonikerEx in PythonCOM.cpp to remove that call fixes the import issue. http://dl.getdropbox.com/u/2/urlmon.dll bug subject line: [ pywin32-Bugs-2693152 ] pythoncom fails to import due to CreateURLMonikerEx just letting you know, as the bug was marked closed, but it does cause py2exe-created exes to barf (fails to memoryloadlibrary pythoncom25.dll) where they worked in versions < 213 -- hope this is helpful. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2009-03-22 23:58 Message: Followup from the original reporter: I've discovered that I had semi-broken IE installation on that machine. Reinstalled IE6 did fix the problem. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2693152&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2009-03-31 08:37:58
|
Bugs item #2693152, was opened at 2009-03-19 12:01 Message generated for change (Settings changed) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2693152&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: Accepted Priority: 5 Private: No Submitted By: Mark Hammond (mhammond) Assigned to: Nobody/Anonymous (nobody) Summary: pythoncom fails to import due to CreateURLMonikerEx Initial Comment: Noticed on the 'bzr' mailing list which recently released a binary using build 213 """ Entry point to procedure CreateURLMonikerEx does not found in DLL urlmon.dll I've tried to install on Windows 2000 machine. """ Note this machine was running the Russian version which may be relevant, as MSDN says it should be there... ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2009-03-31 19:37 Message: >From private mail: second -- i noticed a bug filed against pywin32, build 213. just wanted you to know that we're seeing the same problem here on an old win2k SP4 vm, which ships the urlmon.dll at the link below. dependency walker indicates it can't import CreateURLMonikerEx, and hacking up pythoncom_CreateURLMonikerEx in PythonCOM.cpp to remove that call fixes the import issue. http://dl.getdropbox.com/u/2/urlmon.dll bug subject line: [ pywin32-Bugs-2693152 ] pythoncom fails to import due to CreateURLMonikerEx just letting you know, as the bug was marked closed, but it does cause py2exe-created exes to barf (fails to memoryloadlibrary pythoncom25.dll) where they worked in versions < 213 -- hope this is helpful. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2009-03-23 15:58 Message: Followup from the original reporter: I've discovered that I had semi-broken IE installation on that machine. Reinstalled IE6 did fix the problem. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2693152&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2009-03-30 12:34:40
|
Bugs item #2555415, was opened at 2009-02-01 21:43 Message generated for change (Settings changed) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2555415&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: Duplicate Priority: 5 Private: No Submitted By: Mark Hammond (mhammond) Assigned to: Nobody/Anonymous (nobody) Summary: backspacing over extended chars is incorrect Initial Comment: >From Mark Tolonen, and is only relevant for build 213 and later: Backspacing over a multibyte character in the file editor doesn't delete the whole character. It deletes the first byte of the multibyte sequence. The result for a single press of backspace over a Chinese character (3 > bytes) prints the graphic byte codes of the two remaining bytes. The interactive window works correctly. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2009-03-30 23:34 Message: oops - just closed a duplicate which included a fix. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2555415&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2009-03-30 12:31:54
|
Bugs item #2704124, was opened at 2009-03-22 20:26 Message generated for change (Settings changed) made by tjgolden You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2704124&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: Later Priority: 7 Private: No Submitted By: Tim Golden (tjgolden) Assigned to: Nobody/Anonymous (nobody) Summary: GetCompressedFileSize fails for some unicode filenames Initial Comment: I have a filename which contains the unicode codepoint U+F022. win32file.GetCompressedFileSize fails to cope with this name, returning error ERROR_INVALID_NAME. I can, however, call the underlying -W function from ctypes which works correctly. I suspect that the -W version of the function isn't in fact being used. My experience is that the -A functions will work on "simple" unicode -- those which can be encoded/decoded by the default encoding -- but will fail on "deeper" unicode, such as my example above which uses a private-space code point. (It's a real-life example, altho' I've no idea how it got there). Example: <code> filename = u"\uf022.txt" open (filename, "w").close () import win32file print win32file.GetCompressedFileSize (filename) import ctypes from ctypes import wintypes size = wintypes.DWORD () print ctypes.windll.kernel32.GetCompressedFileSizeW (filename, ctypes.byref (size)) </code> ---------------------------------------------------------------------- >Comment By: Tim Golden (tjgolden) Date: 2009-03-30 12:31 Message: Fine by me. I have to workaround it in any case for earlier versions. Appreciate the attention. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2009-03-30 12:28 Message: It is a slippery-slope from here, and I'm inclined to agree with Roger that moving to unicode builds everywhere is a better strategy than hacking every function taking a string to handle those different types. Maybe later this year - when the dust fully settles from the recent py3k-enabled builds, I'll stir more up by moving everything to unicode... ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2009-03-27 11:06 Message: This should work correctly in Python 3, where the module is built so that unicode API functions are called. Pywin32 can now be built with UNICODE defined for 2.x also, although it hasn't been released that way yet. Roger ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2704124&group_id=78018 |
2 messages has been excluded from this view by a project administrator.
