pywin32-bugs Mailing List for Python for Windows Extensions (Page 4)
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...> - 2013-03-11 22:14:17
|
Bugs item #3607350, was opened at 2013-03-08 08:28 Message generated for change (Settings changed) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3607350&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: Wont Fix Priority: 5 Private: No Submitted By: atthecorner (mkearney) Assigned to: Nobody/Anonymous (nobody) Summary: pywin32 218 amd64 vista py3.3.0 installation Issue Initial Comment: I had to build a custom python3.3 from source to resolve a python/pyramid problem. Thus I wanted to inform the pywin32 installer of the location of my custom python. The pywin installer accomodates just this very problem, The installer knows that it is looking for a python 3.3. However the field of the popup for specifying the path to my python was not writable. The installer did inform me that it could not find a version of python 3.3 in the registry after I had removed the version of python 3.3 that I had installed by the msi file. That was a useful enough clue so that I could solve the problem. I reinstalled the "bad" but std python 3.3.0 release which created the proper registry entry, Then used regedit to modify all paths to point to my local python. That worked but I suspect that is not really the proper long term solution. Knowing this problem exists, I'll keep an eye out for pywin future releases and test if resolution has been attempted. -m pywin32 218 amd64 vista py3.3.0 installation Issue ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2013-03-11 15:14 Message: Unfortunately this is a limitation in the builtin distutils library used by pywin32 for installation. I believe there is already a core bug on file for that and there is nothing pywin32 can do to work around the problem other than to abandon distutils. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3607350&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2013-03-08 16:28:43
|
Bugs item #3607350, was opened at 2013-03-08 08:28 Message generated for change (Tracker Item Submitted) made by mkearney You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3607350&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: atthecorner (mkearney) Assigned to: Nobody/Anonymous (nobody) Summary: pywin32 218 amd64 vista py3.3.0 installation Issue Initial Comment: I had to build a custom python3.3 from source to resolve a python/pyramid problem. Thus I wanted to inform the pywin32 installer of the location of my custom python. The pywin installer accomodates just this very problem, The installer knows that it is looking for a python 3.3. However the field of the popup for specifying the path to my python was not writable. The installer did inform me that it could not find a version of python 3.3 in the registry after I had removed the version of python 3.3 that I had installed by the msi file. That was a useful enough clue so that I could solve the problem. I reinstalled the "bad" but std python 3.3.0 release which created the proper registry entry, Then used regedit to modify all paths to point to my local python. That worked but I suspect that is not really the proper long term solution. Knowing this problem exists, I'll keep an eye out for pywin future releases and test if resolution has been attempted. -m pywin32 218 amd64 vista py3.3.0 installation Issue ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3607350&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2013-02-27 10:06:02
|
Bugs item #3606190, was opened at 2013-02-27 02:05 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3606190&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: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: win32print.OpenPrinter is blocking Initial Comment: In win32print\win32print.cpp, the call to OpenPrinter is not enclosed in a pair Py_BEGIN_ALLOW_THREADS / Py_END_ALLOW_THREADS. This causes multi-threaded programs to freeze until OpenPrinter returns. OpenPrinter can generally be very slow (see remarks in the Microsoft docs). In my tests it took between 4 and 90 (!) seconds when I tried to access a printer which is connected to a powered-off network PC, before OpenPrinter would return an error. The fix should be simple enough. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3606190&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2013-02-08 11:41:37
|
Bugs item #3074702, was opened at 2010-09-24 03:03 Message generated for change (Comment added) made by mikalaaksonen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3074702&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: kxroberto (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: frequent KeyDot failed, UnicodeError in interactive Initial Comment: build214 Firing event 'KeyDot' failed. Traceback (most recent call last): File "C:\Python23\Lib\site-packages\pythonwin\pywin\scintilla\bindings.py", line 145, in fire rc = binding.handler(*args) File "C:\Python23\Lib\site-packages\pythonwin\pywin\scintilla\view.py", line 307, in KeyDotEvent self._AutoComplete() File "C:\Python23\Lib\site-packages\pythonwin\pywin\scintilla\view.py", line 467, in _AutoComplete text = self.GetTextRange(self.LineIndex(minline),endpos) File "C:\Python23\Lib\site-packages\pythonwin\pywin\scintilla\control.py", line 362, in GetTextRange ret = ret.decode(default_scintilla_encoding) UnicodeDecodeError: 'utf8' codec can't decode byte 0xff in position 5946: unexpected code byte ---------------------------------------------------------------------- Comment By: Mika (mikalaaksonen) Date: 2013-02-08 03:41 Message: I get always this error only when class browser in left panel is visible. My workaround is just to outcomment the line from where error comes e.g. #if not browser.list: return (minline,maxline,None) Seems to work without error after that. I'm just wondering what functionality I'm missing when out-commenting the line. AFAIK : The error comes because __getattr__ of browser is overloaded and when there is "browser." in code it starts infinite loop. ---------------------------------------------------------------------- Comment By: kxroberto (kxroberto) Date: 2011-11-22 06:51 Message: I have still this same "maximum recursion" kind of error in build 216. The solution probably: browser.list => browser.listControl And the recursive "return getattr(self, attr)" in HierList.__getattr__ probably makes no sense. (if attr in .__dict__ then .__getattr__ is not called. ) --- --- _orig/view.py 2011-02-25 11:04:38 +0000 +++ ./view.py 2011-11-22 14:46:18 +0000 @@ -510,7 +510,7 @@ pass if browser is None: return (minline,maxline,None) # Current window has no browser - if not browser.list: return (minline,maxline,None) # Not initialized + if not browser.listControl: return (minline,maxline,None) # Not initialized path = self.GetDocument().GetPathName() if not path: return (minline,maxline,None) # No current path --- _orig/hierlist.py 2009-02-16 17:43:26 +0000 +++ ./hierlist.py 2011-11-22 14:43:35 +0000 @@ -56,10 +56,10 @@ self.filledItemHandlesMap = {} self.bitmapMask = bitmapMask def __getattr__(self, attr): - try: + ##try: return getattr(self.listControl, attr) - except AttributeError: - return getattr(self, attr) + ##except AttributeError: + ## return getattr(self, attr) def ItemFromHandle(self, handle): return self.itemHandleMap[handle] ---------------------------------------------------------------------- Comment By: Michael Toews (mwtoews) Date: 2011-05-29 22:25 Message: I frequently (daily) have a similar error, typically while editing code or comments in Python scripts where I happen to type letters followed by the "." character. This edited error was 2000 lines long: Firing event 'KeyDot' failed. Traceback (most recent call last): File "C:\Python25\Lib\site-packages\pythonwin\pywin\scintilla\bindings.py", line 142, in fire rc = binding.handler(*args) File "C:\Python25\Lib\site-packages\pythonwin\pywin\scintilla\view.py", line 307, in KeyDotEvent self._AutoComplete() File "C:\Python25\Lib\site-packages\pythonwin\pywin\scintilla\view.py", line 465, in _AutoComplete minline, maxline, curclass = self._GetClassInfoFromBrowser() File "C:\Python25\Lib\site-packages\pythonwin\pywin\scintilla\view.py", line 520, in _GetClassInfoFromBrowser if not browser.list: return (minline,maxline,None) # Not initialized File "C:\Python25\Lib\site-packages\pythonwin\pywin\tools\hierlist.py", line 62, in __getattr__ return getattr(self, attr) File "C:\Python25\Lib\site-packages\pythonwin\pywin\tools\hierlist.py", line 62, in __getattr__ return getattr(self, attr) 80 lines deleted File "C:\Python25\Lib\site-packages\pythonwin\pywin\tools\hierlist.py", line 62, in __getattr__ return getattr(self, attr) File "C:\Python25\Lib\site-packages\pythonwin\pywin\tools\hierlist.py", line 60, in __getattr__ return getattr(self.listControl, attr) RuntimeError: maximum recursion depth exceeded I'm using pywin32 build 214, WinXP, Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2011-04-25 23:10 Message: Yeah - we are sending the GETTESTRANGE message, but the start and end pos have both come directly from LineIndex (EM_LINEINDEX). This is basically the same strategy taken by GetLine(): start = self.LineIndex(line) end = self.LineIndex(line+1) return self.GetTextRange(start, end) the docs for EM_GETTEXTRANGE say end if "Character position immediately following the last character in the range.", so this looks correct. The above all assumes scintilla doesn't have a bug in some corner case:) It also seems strange the exception refers to 0xff - best I can tell, 0xff is not a leading utf8 byte. So I guess I need instructions for a repro so I can see what is going on via the debugger! ---------------------------------------------------------------------- Comment By: kxroberto (kxroberto) Date: 2010-10-28 05:06 Message: the start/end for this GetTextRange come unchecked from LineIndex() 's. The lineno's unchecked from _GetClassInfoFromBrowser Maybe just a line is -1 or so. If always complete valid lines are decoded completely, may there should be no such problem? ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2010-09-28 10:24 Message: The underlying problem is how Scintilla handles (or fails to handle) multibyte characters when in utf-8 mode. None of the text handling messages (SCI_GETTEXTRANGE in this case) take continuation characters into account. If you ask for say 10 characters, what you get back is 10 bytes, which may contain partial characters at the start or the end of the buffer. The only way I can see to deal with discrete characters are the SCI_POSITIONBEFORE and SCI_POSITIONAFTER messages, which means all operations would have to be done one character at a time. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3074702&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2013-02-07 14:59:01
|
Bugs item #3603451, was opened at 2013-02-05 12:09 Message generated for change (Comment added) made by rupole You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3603451&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: Wesley Tanaka (wtanaka) Assigned to: Nobody/Anonymous (nobody) Summary: __getitem__ stopped getting created between v.214 => v.218 Initial Comment: See: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3603059&group_id=78018 for background I confirmed that the Pages.py file in gen_py did have a __getitem__ method when generated by version 214, and did not have a __getitem__ method when generated by version 218. I'm filing this bug per the thread in https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3603059&group_id=78018 ---------------------------------------------------------------------- >Comment By: Roger Upole (rupole) Date: 2013-02-07 06:59 Message: Probably a result of this commit: http://pywin32.hg.sourceforge.net/hgweb/pywin32/pywin32/rev/2ad7e595084e It removed support for old-style __getitem__ iterators. They caused a number of problems, chiefly in that the result returned by object[x] may be different from the result returned by object.Item(x) if the object doesn't use zero-based indexing as python does. Also, the way the iterator was cached could cause a stale result if the object changed. Right now, __getitem__ is only generated if the object has an Item method. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3603451&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2013-02-05 20:09:51
|
Bugs item #3603451, was opened at 2013-02-05 12:09 Message generated for change (Tracker Item Submitted) made by wtanaka You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3603451&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: Wesley Tanaka (wtanaka) Assigned to: Nobody/Anonymous (nobody) Summary: __getitem__ stopped getting created between v.214 => v.218 Initial Comment: See: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3603059&group_id=78018 for background I confirmed that the Pages.py file in gen_py did have a __getitem__ method when generated by version 214, and did not have a __getitem__ method when generated by version 218. I'm filing this bug per the thread in https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3603059&group_id=78018 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3603451&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2013-02-05 03:11:02
|
Bugs item #3603059, was opened at 2013-02-01 19:19 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3603059&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: Wont Fix Priority: 5 Private: No Submitted By: Wesley Tanaka (wtanaka) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot pass array of arrays Initial Comment: With code that looks like this: instance = win32com.client.gencache.EnsureDispatch("InDesign.Application") doc = instance.Open("some_path") pages = doc.Pages page0 = pages.FirstItem() opposing_corners=((0.0, 0.0), (72.0, 72.0)) page0.Reframe( In=2021222766, OpposingCorners=opposing_corners) The reframe method: http://cssdk.host.adobe.com/sdk/1.0/docs/WebHelp/references/csawlib/com/adobe/indesign/Page.html#reframe%28%29 expects an array containing two arrays, where each of those two arrays contains two doubles. If I pass in a scalar like 5.0 or a 1-D array like (1.0, 1.0) or even if I add an extra item to the array like ((0.0, 0.0), (72.0, 72.0), 5.0) or ((0.0, 0.0), (72.0, 72.0), None), the exception coming back from InDesign references the value that I passed to the Reframe method. However, if I pass ((0.0, 0.0), (72.0, 72.0)), then InDesign says that it is receiving "()" This thread looks similar: http://stackoverflow.com/questions/10166064/python-win32com-and-2-dimensional-arrays/10167882#10167882 and the solution there is to use comtypes instead of win32com. Is this a known issue with win32com? I tried looking at the underlying InvokeTypes call but stopped when I saw this mailing list post saying that it's poorly documented: http://mail.python.org/pipermail/python-win32/2005-December/004031.html ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2013-02-04 19:11 Message: > Was support for __getitem__ removed between 214 and 218? Is there a way to > get it back, or do I need to switch to calling the object-specific methods > like: I can't recall any such change. It would be interesting to know if the generated file (probably in win32com\gen_py) has __getitem__ in 214 but doesn't in 218. The other possibility is that you were not using the generated file in 214. > Question 2. I didn't find VT_DOUBLE in pythoncom. I did find VT_R8, and > that seemed to work. Am I doing something wrong/looking in the wrong > place? No, I was mistaken - VT_R8 is how COM spells a double. Closing this issue as there isn't much we can do to correctly guess what variant type is necessary in the array. If there turns out to be a problem with __getitem__ we should open a new bug for that ---------------------------------------------------------------------- Comment By: Wesley Tanaka (wtanaka) Date: 2013-02-04 18:42 Message: Thanks for that tip! The COM object was expecting this: topleft = VARIANT(pythoncom.VT_ARRAY | pythoncom.VT_R8, (0.0, 0.0)) bottomright = VARIANT(pythoncom.VT_ARRAY | pythoncom.VT_R8, (72.0, 72.0)) opposing_corners = VARIANT(pythoncom.VT_ARRAY | pythoncom.VT_VARIANT, (topleft, bottomright)) If you don't mind too terribly, this has brought up a few other questions: 1. To get VARIANT, I needed to upgrade pywin32 from version 214 to the latest version 218. When I was running version 214, this class: http://cssdk.host.adobe.com/sdk/1.0/docs/WebHelp/references/csawlib/com/adobe/indesign/Pages.html had a __getitem__() function defined, allowing me to do things like: doc = instance.Open("some_path") pages = doc.Pages page0 = pages[0] But after the upgrade to 218 (with no other changes), this leads to an error: ... File "C:\Python27\lib\site-packages\win32com\client\__init__.py", line 465, in __getattr__ raise AttributeError("'%s' object has no attribute '%s'" % (repr(self), attr )) AttributeError: '<win32com.gen_py.Adobe InDesign CS5.5 Type Library.Pages instance at 0x94471592>' object has no attribute '__getitem__' Was support for __getitem__ removed between 214 and 218? Is there a way to get it back, or do I need to switch to calling the object-specific methods like: page0 = pages.FirstItem() Question 2. I didn't find VT_DOUBLE in pythoncom. I did find VT_R8, and that seemed to work. Am I doing something wrong/looking in the wrong place? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2013-02-03 13:37 Message: Multi-dimension arrays are covered by the tests and work fine with other objects. It might be that the COM object isn't given appropriate type information for the method, meaning python might be passing arrays of, eg, doubles or variants, where the object expects just floats. You could try something like: from win32com.client import VARIANT import pythoncom arg = VARIANT(pythoncom.VT_ARRAY | pythoncom.VT_DOUBLE, [(1.0, 1.0), (10.0, 10.0)) and pass 'arg' as the array argument - this will force the type of the param to double. Unfortunately the docs don't indicate what specific type is needed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3603059&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2013-02-05 02:42:26
|
Bugs item #3603059, was opened at 2013-02-01 19:19 Message generated for change (Comment added) made by wtanaka You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3603059&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: Wesley Tanaka (wtanaka) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot pass array of arrays Initial Comment: With code that looks like this: instance = win32com.client.gencache.EnsureDispatch("InDesign.Application") doc = instance.Open("some_path") pages = doc.Pages page0 = pages.FirstItem() opposing_corners=((0.0, 0.0), (72.0, 72.0)) page0.Reframe( In=2021222766, OpposingCorners=opposing_corners) The reframe method: http://cssdk.host.adobe.com/sdk/1.0/docs/WebHelp/references/csawlib/com/adobe/indesign/Page.html#reframe%28%29 expects an array containing two arrays, where each of those two arrays contains two doubles. If I pass in a scalar like 5.0 or a 1-D array like (1.0, 1.0) or even if I add an extra item to the array like ((0.0, 0.0), (72.0, 72.0), 5.0) or ((0.0, 0.0), (72.0, 72.0), None), the exception coming back from InDesign references the value that I passed to the Reframe method. However, if I pass ((0.0, 0.0), (72.0, 72.0)), then InDesign says that it is receiving "()" This thread looks similar: http://stackoverflow.com/questions/10166064/python-win32com-and-2-dimensional-arrays/10167882#10167882 and the solution there is to use comtypes instead of win32com. Is this a known issue with win32com? I tried looking at the underlying InvokeTypes call but stopped when I saw this mailing list post saying that it's poorly documented: http://mail.python.org/pipermail/python-win32/2005-December/004031.html ---------------------------------------------------------------------- >Comment By: Wesley Tanaka (wtanaka) Date: 2013-02-04 18:42 Message: Thanks for that tip! The COM object was expecting this: topleft = VARIANT(pythoncom.VT_ARRAY | pythoncom.VT_R8, (0.0, 0.0)) bottomright = VARIANT(pythoncom.VT_ARRAY | pythoncom.VT_R8, (72.0, 72.0)) opposing_corners = VARIANT(pythoncom.VT_ARRAY | pythoncom.VT_VARIANT, (topleft, bottomright)) If you don't mind too terribly, this has brought up a few other questions: 1. To get VARIANT, I needed to upgrade pywin32 from version 214 to the latest version 218. When I was running version 214, this class: http://cssdk.host.adobe.com/sdk/1.0/docs/WebHelp/references/csawlib/com/adobe/indesign/Pages.html had a __getitem__() function defined, allowing me to do things like: doc = instance.Open("some_path") pages = doc.Pages page0 = pages[0] But after the upgrade to 218 (with no other changes), this leads to an error: ... File "C:\Python27\lib\site-packages\win32com\client\__init__.py", line 465, in __getattr__ raise AttributeError("'%s' object has no attribute '%s'" % (repr(self), attr )) AttributeError: '<win32com.gen_py.Adobe InDesign CS5.5 Type Library.Pages instance at 0x94471592>' object has no attribute '__getitem__' Was support for __getitem__ removed between 214 and 218? Is there a way to get it back, or do I need to switch to calling the object-specific methods like: page0 = pages.FirstItem() Question 2. I didn't find VT_DOUBLE in pythoncom. I did find VT_R8, and that seemed to work. Am I doing something wrong/looking in the wrong place? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2013-02-03 13:37 Message: Multi-dimension arrays are covered by the tests and work fine with other objects. It might be that the COM object isn't given appropriate type information for the method, meaning python might be passing arrays of, eg, doubles or variants, where the object expects just floats. You could try something like: from win32com.client import VARIANT import pythoncom arg = VARIANT(pythoncom.VT_ARRAY | pythoncom.VT_DOUBLE, [(1.0, 1.0), (10.0, 10.0)) and pass 'arg' as the array argument - this will force the type of the param to double. Unfortunately the docs don't indicate what specific type is needed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3603059&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2013-02-03 21:37:38
|
Bugs item #3603059, was opened at 2013-02-01 19:19 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3603059&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: Wesley Tanaka (wtanaka) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot pass array of arrays Initial Comment: With code that looks like this: instance = win32com.client.gencache.EnsureDispatch("InDesign.Application") doc = instance.Open("some_path") pages = doc.Pages page0 = pages.FirstItem() opposing_corners=((0.0, 0.0), (72.0, 72.0)) page0.Reframe( In=2021222766, OpposingCorners=opposing_corners) The reframe method: http://cssdk.host.adobe.com/sdk/1.0/docs/WebHelp/references/csawlib/com/adobe/indesign/Page.html#reframe%28%29 expects an array containing two arrays, where each of those two arrays contains two doubles. If I pass in a scalar like 5.0 or a 1-D array like (1.0, 1.0) or even if I add an extra item to the array like ((0.0, 0.0), (72.0, 72.0), 5.0) or ((0.0, 0.0), (72.0, 72.0), None), the exception coming back from InDesign references the value that I passed to the Reframe method. However, if I pass ((0.0, 0.0), (72.0, 72.0)), then InDesign says that it is receiving "()" This thread looks similar: http://stackoverflow.com/questions/10166064/python-win32com-and-2-dimensional-arrays/10167882#10167882 and the solution there is to use comtypes instead of win32com. Is this a known issue with win32com? I tried looking at the underlying InvokeTypes call but stopped when I saw this mailing list post saying that it's poorly documented: http://mail.python.org/pipermail/python-win32/2005-December/004031.html ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2013-02-03 13:37 Message: Multi-dimension arrays are covered by the tests and work fine with other objects. It might be that the COM object isn't given appropriate type information for the method, meaning python might be passing arrays of, eg, doubles or variants, where the object expects just floats. You could try something like: from win32com.client import VARIANT import pythoncom arg = VARIANT(pythoncom.VT_ARRAY | pythoncom.VT_DOUBLE, [(1.0, 1.0), (10.0, 10.0)) and pass 'arg' as the array argument - this will force the type of the param to double. Unfortunately the docs don't indicate what specific type is needed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3603059&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2013-02-02 03:19:49
|
Bugs item #3603059, was opened at 2013-02-01 19:19 Message generated for change (Tracker Item Submitted) made by wtanaka You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3603059&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: Wesley Tanaka (wtanaka) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot pass array of arrays Initial Comment: With code that looks like this: instance = win32com.client.gencache.EnsureDispatch("InDesign.Application") doc = instance.Open("some_path") pages = doc.Pages page0 = pages.FirstItem() opposing_corners=((0.0, 0.0), (72.0, 72.0)) page0.Reframe( In=2021222766, OpposingCorners=opposing_corners) The reframe method: http://cssdk.host.adobe.com/sdk/1.0/docs/WebHelp/references/csawlib/com/adobe/indesign/Page.html#reframe%28%29 expects an array containing two arrays, where each of those two arrays contains two doubles. If I pass in a scalar like 5.0 or a 1-D array like (1.0, 1.0) or even if I add an extra item to the array like ((0.0, 0.0), (72.0, 72.0), 5.0) or ((0.0, 0.0), (72.0, 72.0), None), the exception coming back from InDesign references the value that I passed to the Reframe method. However, if I pass ((0.0, 0.0), (72.0, 72.0)), then InDesign says that it is receiving "()" This thread looks similar: http://stackoverflow.com/questions/10166064/python-win32com-and-2-dimensional-arrays/10167882#10167882 and the solution there is to use comtypes instead of win32com. Is this a known issue with win32com? I tried looking at the underlying InvokeTypes call but stopped when I saw this mailing list post saying that it's poorly documented: http://mail.python.org/pipermail/python-win32/2005-December/004031.html ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3603059&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2013-01-11 10:43:54
|
Bugs item #3600371, was opened at 2013-01-11 02:43 Message generated for change (Tracker Item Submitted) made by cpu2 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3600371&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: Yes Submitted By: BHM (cpu2) Assigned to: Nobody/Anonymous (nobody) Summary: Installer error message on pywin32-218.win32-py2.7 Initial Comment: Installer completed with error message: close failed in file object destructor: sys.excepthook is missing lost sys.stderr ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3600371&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2013-01-05 17:47:09
|
Bugs item #2846720, was opened at 2009-08-28 22:56 Message generated for change (Comment added) made by bloominator You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2846720&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: win32ui crash in embedded app (212 -> 213 & 214 regression) Initial Comment: I have an application that embeds python and uses the win32ui module. Everything worked fine until I upgraded from 212 to 214. After the upgrade my application crashes on exit. The Visual Studio debugger is showing that the crash is occurring after my application calls CoUninitialize. Here is a rough outline of what my app does: CoInitialize(NULL) InitPython() RunPythonCode() //This code will import win32ui ClosePython() CoUninitialize() Simply importing the win32ui module causes the crash. I don't even need to call any of the modules functions. If I don't import win32ui then my application exits cleanly. I tried downgrading to version 213 but the crash still occurs. Version 212 seems to be the last version that was stable with my application. ---------------------------------------------------------------------- Comment By: Gary Bloom (bloominator) Date: 2013-01-05 09:47 Message: I see a similar (and I'm sure related) problem. The following Python code snippet causes a hang on exit: ################################# import Tkinter import win32ui #including this library causes hang on exit master = Tkinter.Tk() #Label not needed to reproduce hang Tkinter.Label(text=" Will hang on exit if win32ui has been imported ").pack() master.mainloop() ################################# This regression problem did not exist with PyWin32-212. It began with 213 and still exists in every version since then, up to 218. I build and test with 32-bit Python on Win7 (both 32-bit and 64-bit platforms). The problem exists in 32-bit Python on both platforms. I haven't looked at 64-bit Python. This bug is preventing me from upgrading my build to Python 2.7, because: 1) I need pywin32, 2) pywin32-212 is the last version that does not have the hang regression, and 3) pywin32-212 Windows builds stop at Python 2.6. ---------------------------------------------------------------------- Comment By: s ANCELOT (sancelot2) Date: 2011-12-12 09:08 Message: I have exactly the same problem using python 2.6 32 bits version on win7 64 bits. on a win32 32 bits platform it has worked, but It did when launching the same application on 64 bits platform. after lot of researchs I found that loading win32ui was the problem. I tried the 212 build and the problem disappeared. I think it does not seem complicated to watch at changes between 212 and 216 build.? ---------------------------------------------------------------------- Comment By: Farshid Lashkari (farshizzo) Date: 2010-09-30 14:43 Message: I've experienced this crash on 2.4, 2.6, and 2.7. Since reporting this issue, I've abandoned the use of win32ui, so it's not a big deal for me anymore. But if you come up with a fix, I am willing to test it out. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2010-09-30 00:57 Message: I can reproduce a problem after Py_Finalize is called - win32ui is trying to process a message (presumably sent during CoUninitialize) and getting upset as Python has been torn down. I can't explain how that has changed in recent versions though. If I change the example to CoUninitialize before the finalize everything seems to work fine. ---------------------------------------------------------------------- Comment By: Christoph Gohlke (cjgohlke) Date: 2010-09-29 23:27 Message: I can reproduce the crash with pywin32-214.win-amd64-py2.6 and main.cpp. The following code worked for me when compiled with msvc9 "cl.exe main.cpp /MD /link python26.lib ole32.lib": #include "Python.h" #include <windows.h> int main( int argc, char **argv ) { Py_Initialize(); CoInitialize(NULL); PyRun_SimpleString("import win32ui"); CoUninitialize(); Py_Finalize(); return 0; } ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2010-09-29 18:20 Message: I tried to reproduce this but hit manifest related issues trying python 2.6 - what python version are you using? ---------------------------------------------------------------------- Comment By: SourceForge Robot (sf-robot) Date: 2010-09-29 12:30 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Farshid Lashkari (farshizzo) Date: 2010-09-13 16:03 Message: I just attached a simple console app that reproduces the issue for me using Python 2.7. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2010-08-29 21:34 Message: I'm going to need either a repo or more details information on the crash. ---------------------------------------------------------------------- Comment By: Farshid Lashkari (farshizzo) Date: 2009-08-28 23:02 Message: Forgot to mention that I'm using Python 2.4 & 2.6, and both exhibit the same behavior. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2846720&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2013-01-01 23:00:17
|
Bugs item #3598993, was opened at 2012-12-31 01:38 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3598993&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: Invalid Priority: 5 Private: No Submitted By: caizhenkun (caizhenkun) Assigned to: Nobody/Anonymous (nobody) Summary: The program passes on Win7 but fails on Win8 Initial Comment: Hi, Sir. I wrote the following program. It could not pass on Win8, but it can pass on Win7. It will try to simulate the action to click the Next button on a dialog (I use JDK installation dialog). I believe the issue comes from the statement 'win32gui.SendMessage(win32gui.GetParent(hButton), win32con.WM_COMMAND, win32con.BN_CLICKED, hButton)'. import win32gui import win32con import win32api print "abc" hWindow = win32gui.FindWindow('MsiDialogCloseClass', None) if hWindow <> 0: print hWindow hButton = win32gui.FindWindowEx(hWindow, 0, 'Button', '&Next >') if hButton <> 0: print hButton win32gui.SendMessage(win32gui.GetParent(hButton), win32con.WM_COMMAND, win32con.BN_CLICKED, hButton) else: print "ghi" else: print "def" However, I wrote another program to validate the SendMessage function. It will try to add some texts into an existing notepad program. But it can get passed on both Win7 and Win8. print "abc" hWindow2 = win32gui.FindWindow('Notepad', None) if hWindow2 <> 0: print hWindow2 hEdit = win32gui.FindWindowEx(hWindow2, 0, 'Edit', None) if hEdit <> 0: print hEdit win32gui.SendMessage(hEdit, win32con.WM_SETTEXT, None, 'hello, czk') else: print "ghi" else: print "def" So I wonder whether it is caused by the reason that win32gui.SendMessage only partially supports Win8? As in my examples, you can see win32gui.SendMessage with parameter win32con.WM_SETTEXT is OK while with parameters win32con.WM_COMMAND and win32con.BN_CLICKED are not supporting win8. It's only my guessing. If you found I had typed some code wrong, please help to point out. Thanks ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2013-01-01 15:00 Message: This is a thin wrapper around the win32 function, so I doubt the failure has anything to do specifically with pywin32. Try emailing the python-win32 list to see if any others have an idea. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2013-01-01 15:00 Message: Thanks for your report, but this tracker is for reporting bugs in pywin32 rather than a support forum. Please email support requests to the python-win32 mailing list where many more people will see your request and be able to help. You need to be subscribed to the list before you can post to it - see http://mail.python.org/mailman/listinfo/python-win32 for subscription options. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3598993&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2012-12-31 09:38:14
|
Bugs item #3598993, was opened at 2012-12-31 01:38 Message generated for change (Tracker Item Submitted) made by caizhenkun You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3598993&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: caizhenkun (caizhenkun) Assigned to: Nobody/Anonymous (nobody) Summary: The program passes on Win7 but fails on Win8 Initial Comment: Hi, Sir. I wrote the following program. It could not pass on Win8, but it can pass on Win7. It will try to simulate the action to click the Next button on a dialog (I use JDK installation dialog). I believe the issue comes from the statement 'win32gui.SendMessage(win32gui.GetParent(hButton), win32con.WM_COMMAND, win32con.BN_CLICKED, hButton)'. import win32gui import win32con import win32api print "abc" hWindow = win32gui.FindWindow('MsiDialogCloseClass', None) if hWindow <> 0: print hWindow hButton = win32gui.FindWindowEx(hWindow, 0, 'Button', '&Next >') if hButton <> 0: print hButton win32gui.SendMessage(win32gui.GetParent(hButton), win32con.WM_COMMAND, win32con.BN_CLICKED, hButton) else: print "ghi" else: print "def" However, I wrote another program to validate the SendMessage function. It will try to add some texts into an existing notepad program. But it can get passed on both Win7 and Win8. print "abc" hWindow2 = win32gui.FindWindow('Notepad', None) if hWindow2 <> 0: print hWindow2 hEdit = win32gui.FindWindowEx(hWindow2, 0, 'Edit', None) if hEdit <> 0: print hEdit win32gui.SendMessage(hEdit, win32con.WM_SETTEXT, None, 'hello, czk') else: print "ghi" else: print "def" So I wonder whether it is caused by the reason that win32gui.SendMessage only partially supports Win8? As in my examples, you can see win32gui.SendMessage with parameter win32con.WM_SETTEXT is OK while with parameters win32con.WM_COMMAND and win32con.BN_CLICKED are not supporting win8. It's only my guessing. If you found I had typed some code wrong, please help to point out. Thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3598993&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2012-12-27 05:38:46
|
Bugs item #3597965, was opened at 2012-12-20 16:31 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3597965&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: com Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Kevin Smyth () Assigned to: Nobody/Anonymous (nobody) Summary: pythoncomloader.dll and undefined LoadLibraryEx behavior Initial Comment: MSDN's documentation for LoadLibraryEx states "The behavior is undefined when LOAD_WITH_ALTERED_SEARCH_PATHflag is set, and lpFileName specifiies a relative path." com/win32com/src/PythonCOMLoader.cpp: HMODULE hpycom = LoadLibraryEx(DLL_DELEGATE, NULL, LOAD_WITH_ALTERED_SEARCH_PATH); setup.py: ccargs.append('/DDLL_DELEGATE=\\"pythoncom%s.dll\\"' % (suffix,)) An absolute path should be used instead. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2012-12-26 21:38 Message: Awesome, thanks! Checked in as rev 4295:860ef545eb60 ---------------------------------------------------------------------- Comment By: Kevin Smyth () Date: 2012-12-21 09:26 Message: Yes, a global HINSTANCE works fine. Patch attached. (Please disregard previous patch, it neglects to actaully assign hpycom. I didn't have a VS2008 compiler to test with) The current patch fixes my issue with loading out of a virtual env. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2012-12-20 18:01 Message: oops - I was too quick in my scan of the patch. It can't be passed as a param, but having it as a global is probably still fine IMO. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2012-12-20 16:40 Message: Thanks for the patch! It seems to be that instead of referencing __ImageBase we could just pass the HINSTANCE from DllMain as a param - is there any reason that would not work? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3597965&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2012-12-21 17:26:35
|
Bugs item #3597965, was opened at 2012-12-20 16:31 Message generated for change (Comment added) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3597965&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: Kevin Smyth () Assigned to: Nobody/Anonymous (nobody) Summary: pythoncomloader.dll and undefined LoadLibraryEx behavior Initial Comment: MSDN's documentation for LoadLibraryEx states "The behavior is undefined when LOAD_WITH_ALTERED_SEARCH_PATHflag is set, and lpFileName specifiies a relative path." com/win32com/src/PythonCOMLoader.cpp: HMODULE hpycom = LoadLibraryEx(DLL_DELEGATE, NULL, LOAD_WITH_ALTERED_SEARCH_PATH); setup.py: ccargs.append('/DDLL_DELEGATE=\\"pythoncom%s.dll\\"' % (suffix,)) An absolute path should be used instead. ---------------------------------------------------------------------- >Comment By: Kevin Smyth () Date: 2012-12-21 09:26 Message: Yes, a global HINSTANCE works fine. Patch attached. (Please disregard previous patch, it neglects to actaully assign hpycom. I didn't have a VS2008 compiler to test with) The current patch fixes my issue with loading out of a virtual env. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2012-12-20 18:01 Message: oops - I was too quick in my scan of the patch. It can't be passed as a param, but having it as a global is probably still fine IMO. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2012-12-20 16:40 Message: Thanks for the patch! It seems to be that instead of referencing __ImageBase we could just pass the HINSTANCE from DllMain as a param - is there any reason that would not work? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3597965&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2012-12-21 02:01:42
|
Bugs item #3597965, was opened at 2012-12-20 16:31 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3597965&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: Kevin Smyth () Assigned to: Nobody/Anonymous (nobody) Summary: pythoncomloader.dll and undefined LoadLibraryEx behavior Initial Comment: MSDN's documentation for LoadLibraryEx states "The behavior is undefined when LOAD_WITH_ALTERED_SEARCH_PATHflag is set, and lpFileName specifiies a relative path." com/win32com/src/PythonCOMLoader.cpp: HMODULE hpycom = LoadLibraryEx(DLL_DELEGATE, NULL, LOAD_WITH_ALTERED_SEARCH_PATH); setup.py: ccargs.append('/DDLL_DELEGATE=\\"pythoncom%s.dll\\"' % (suffix,)) An absolute path should be used instead. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2012-12-20 18:01 Message: oops - I was too quick in my scan of the patch. It can't be passed as a param, but having it as a global is probably still fine IMO. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2012-12-20 16:40 Message: Thanks for the patch! It seems to be that instead of referencing __ImageBase we could just pass the HINSTANCE from DllMain as a param - is there any reason that would not work? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3597965&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2012-12-21 00:43:52
|
Bugs item #3597875, was opened at 2012-12-20 11:53 Message generated for change (Settings changed) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3597875&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: Deleted >Resolution: Duplicate Priority: 5 Private: No Submitted By: Kevin Smyth () Assigned to: Nobody/Anonymous (nobody) Summary: pythoncomloader.dll and undefined LoadLibraryEx behavior Initial Comment: MSDN's documentation for LoadLibraryEx states "The behavior is undefined when LOAD_WITH_ALTERED_SEARCH_PATHflag is set, and lpFileName specifiies a relative path." com/win32com/src/PythonCOMLoader.cpp: HMODULE hpycom = LoadLibraryEx(DLL_DELEGATE, NULL, LOAD_WITH_ALTERED_SEARCH_PATH); setup.py: ccargs.append('/DDLL_DELEGATE=\\"pythoncom%s.dll\\"' % (suffix,)) An absolute path should be used instead. ---------------------------------------------------------------------- Comment By: Kevin Smyth () Date: 2012-12-20 12:16 Message: On Windows 7, this undefined behavior seems to result in the standard dll search order. So if pythoncom27.dll isn't on the %PATH%, in System32, in the exe's directory, or in the current working directory (some machines), the LoadLibraryEx call fails. I'm running into this when pywin32 is installed into a virtual env. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3597875&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2012-12-21 00:40:08
|
Bugs item #3597965, was opened at 2012-12-20 16:31 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3597965&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: Kevin Smyth () Assigned to: Nobody/Anonymous (nobody) Summary: pythoncomloader.dll and undefined LoadLibraryEx behavior Initial Comment: MSDN's documentation for LoadLibraryEx states "The behavior is undefined when LOAD_WITH_ALTERED_SEARCH_PATHflag is set, and lpFileName specifiies a relative path." com/win32com/src/PythonCOMLoader.cpp: HMODULE hpycom = LoadLibraryEx(DLL_DELEGATE, NULL, LOAD_WITH_ALTERED_SEARCH_PATH); setup.py: ccargs.append('/DDLL_DELEGATE=\\"pythoncom%s.dll\\"' % (suffix,)) An absolute path should be used instead. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2012-12-20 16:40 Message: Thanks for the patch! It seems to be that instead of referencing __ImageBase we could just pass the HINSTANCE from DllMain as a param - is there any reason that would not work? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3597965&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2012-12-21 00:31:33
|
Bugs item #3597965, was opened at 2012-12-20 16:31 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3597965&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: Kevin Smyth () Assigned to: Nobody/Anonymous (nobody) Summary: pythoncomloader.dll and undefined LoadLibraryEx behavior Initial Comment: MSDN's documentation for LoadLibraryEx states "The behavior is undefined when LOAD_WITH_ALTERED_SEARCH_PATHflag is set, and lpFileName specifiies a relative path." com/win32com/src/PythonCOMLoader.cpp: HMODULE hpycom = LoadLibraryEx(DLL_DELEGATE, NULL, LOAD_WITH_ALTERED_SEARCH_PATH); setup.py: ccargs.append('/DDLL_DELEGATE=\\"pythoncom%s.dll\\"' % (suffix,)) An absolute path should be used instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3597965&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2012-12-20 20:16:10
|
Bugs item #3597875, was opened at 2012-12-20 11:53 Message generated for change (Comment added) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3597875&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: Kevin Smyth () Assigned to: Nobody/Anonymous (nobody) Summary: pythoncomloader.dll and undefined LoadLibraryEx behavior Initial Comment: MSDN's documentation for LoadLibraryEx states "The behavior is undefined when LOAD_WITH_ALTERED_SEARCH_PATHflag is set, and lpFileName specifiies a relative path." com/win32com/src/PythonCOMLoader.cpp: HMODULE hpycom = LoadLibraryEx(DLL_DELEGATE, NULL, LOAD_WITH_ALTERED_SEARCH_PATH); setup.py: ccargs.append('/DDLL_DELEGATE=\\"pythoncom%s.dll\\"' % (suffix,)) An absolute path should be used instead. ---------------------------------------------------------------------- Comment By: Kevin Smyth () Date: 2012-12-20 12:16 Message: On Windows 7, this undefined behavior seems to result in the standard dll search order. So if pythoncom27.dll isn't on the %PATH%, in System32, in the exe's directory, or in the current working directory (some machines), the LoadLibraryEx call fails. I'm running into this when pywin32 is installed into a virtual env. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3597875&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2012-12-20 19:53:14
|
Bugs item #3597875, was opened at 2012-12-20 11:53 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3597875&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: Kevin Smyth () Assigned to: Nobody/Anonymous (nobody) Summary: pythoncomloader.dll and undefined LoadLibraryEx behavior Initial Comment: MSDN's documentation for LoadLibraryEx states "The behavior is undefined when LOAD_WITH_ALTERED_SEARCH_PATHflag is set, and lpFileName specifiies a relative path." com/win32com/src/PythonCOMLoader.cpp: HMODULE hpycom = LoadLibraryEx(DLL_DELEGATE, NULL, LOAD_WITH_ALTERED_SEARCH_PATH); setup.py: ccargs.append('/DDLL_DELEGATE=\\"pythoncom%s.dll\\"' % (suffix,)) An absolute path should be used instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3597875&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2012-11-30 11:58:31
|
Bugs item #3591103, was opened at 2012-11-29 09:22 Message generated for change (Comment added) made by n-perestoronin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3591103&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: Nikita Perestoronin (n-perestoronin) Assigned to: Nobody/Anonymous (nobody) Summary: Dynamic dispatch and passing arguments by reference Initial Comment: I have the following problem when calling methods that accept arguments passed by reference. Consider the following code: import win32com.client import pythoncom sldworks = win32com.client.gencache.EnsureModule('{83A33D31-27C5-11CE-BFD4-00400513BB57}', 0, 21, 0) swconst = win32com.client.gencache.EnsureModule('{4687F359-55D0-4CD3-B6CF-2EB42C11F989}', 0, 21, 0) sw = sldworks.SldWorks() model_path = 'C:\Demo\model.SLDPRT' model, errors, warnings = sw.OpenDoc6(model_path, swconst.constants.swDocPART, swconst.constants.swOpenDocOptions_Silent, '', pythoncom.Missing, pythoncom.Missing) ext = model.Extension In case of static dispatch it works correctly: >>> ext >>> <win32com.gen_py.SldWorks 2013 Type Library.IModelDocExtension instance at 0x206388400> >>> ext.GetAdvancedSpotLightProperties('Ambient') >>> (0.0, 1.0, 0.0, 0.0) In case of dynamic dispatch it sets wrong value for the last argument: dext = win32com.client.dynamic.DumbDispatch(ext) arg1 = win32com.client.VARIANT(pythoncom.VT_BYREF | pythoncom.VT_R8, 0.0) arg2 = win32com.client.VARIANT(pythoncom.VT_BYREF | pythoncom.VT_R8, 0.0) arg3 = win32com.client.VARIANT(pythoncom.VT_BYREF | pythoncom.VT_R8, 0.0) arg4 = win32com.client.VARIANT(pythoncom.VT_BYREF | pythoncom.VT_R8, 0.0) >>> dext >>> <COMObject <unknown>> >>> dext.GetAdvancedSpotLightProperties('Ambient', arg1, arg2, arg3, arg4) >>> arg1.value, arg2.value, arg3.value, arg4.value >>> (0.0, 1.0, 0.0, u'Ambient') I've checked more methods in SolidWorks API: in case of dynamic dispatch, when arguments are passed by reference, value of the last argument equals to the value of the first argument after call. Since pywin32 fails to provide static dispatch object in some cases, (for example, if I call model.SelectionManager, it returns <COMObject SelectionManager>), I can't use some methods in SolidWorks API. ---------------------------------------------------------------------- >Comment By: Nikita Perestoronin (n-perestoronin) Date: 2012-11-30 03:58 Message: I seems that arguments are written in reverse order. Possible hack is to pass all arguments by reference and reverse them after: arg0 = win32com.client.VARIANT(pythoncom.VT_BYREF | pythoncom.VT_BSTR, 'Ambient') arg1 = win32com.client.VARIANT(pythoncom.VT_BYREF | pythoncom.VT_R8, 0.0) arg2 = win32com.client.VARIANT(pythoncom.VT_BYREF | pythoncom.VT_R8, 0.0) arg3 = win32com.client.VARIANT(pythoncom.VT_BYREF | pythoncom.VT_R8, 0.0) arg4 = win32com.client.VARIANT(pythoncom.VT_BYREF | pythoncom.VT_R8, 0.0) >>> dext.GetAdvancedSpotLightProperties(arg0, arg1, arg2, arg3, arg4) >>> arg3.value, arg2.value, arg1.value, arg0.value >>> (0.0, 1.0, 0.0, 0.0) ---------------------------------------------------------------------- Comment By: Nikita Perestoronin (n-perestoronin) Date: 2012-11-29 09:29 Message: Build 218 is used. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3591103&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2012-11-29 17:29:06
|
Bugs item #3591103, was opened at 2012-11-29 09:22 Message generated for change (Comment added) made by n-perestoronin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3591103&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: Nikita Perestoronin (n-perestoronin) Assigned to: Nobody/Anonymous (nobody) Summary: Dynamic dispatch and passing arguments by reference Initial Comment: I have the following problem when calling methods that accept arguments passed by reference. Consider the following code: import win32com.client import pythoncom sldworks = win32com.client.gencache.EnsureModule('{83A33D31-27C5-11CE-BFD4-00400513BB57}', 0, 21, 0) swconst = win32com.client.gencache.EnsureModule('{4687F359-55D0-4CD3-B6CF-2EB42C11F989}', 0, 21, 0) sw = sldworks.SldWorks() model_path = 'C:\Demo\model.SLDPRT' model, errors, warnings = sw.OpenDoc6(model_path, swconst.constants.swDocPART, swconst.constants.swOpenDocOptions_Silent, '', pythoncom.Missing, pythoncom.Missing) ext = model.Extension In case of static dispatch it works correctly: >>> ext >>> <win32com.gen_py.SldWorks 2013 Type Library.IModelDocExtension instance at 0x206388400> >>> ext.GetAdvancedSpotLightProperties('Ambient') >>> (0.0, 1.0, 0.0, 0.0) In case of dynamic dispatch it sets wrong value for the last argument: dext = win32com.client.dynamic.DumbDispatch(ext) arg1 = win32com.client.VARIANT(pythoncom.VT_BYREF | pythoncom.VT_R8, 0.0) arg2 = win32com.client.VARIANT(pythoncom.VT_BYREF | pythoncom.VT_R8, 0.0) arg3 = win32com.client.VARIANT(pythoncom.VT_BYREF | pythoncom.VT_R8, 0.0) arg4 = win32com.client.VARIANT(pythoncom.VT_BYREF | pythoncom.VT_R8, 0.0) >>> dext >>> <COMObject <unknown>> >>> dext.GetAdvancedSpotLightProperties('Ambient', arg1, arg2, arg3, arg4) >>> arg1.value, arg2.value, arg3.value, arg4.value >>> (0.0, 1.0, 0.0, u'Ambient') I've checked more methods in SolidWorks API: in case of dynamic dispatch, when arguments are passed by reference, value of the last argument equals to the value of the first argument after call. Since pywin32 fails to provide static dispatch object in some cases, (for example, if I call model.SelectionManager, it returns <COMObject SelectionManager>), I can't use some methods in SolidWorks API. ---------------------------------------------------------------------- >Comment By: Nikita Perestoronin (n-perestoronin) Date: 2012-11-29 09:29 Message: Build 218 is used. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3591103&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2012-11-29 17:22:58
|
Bugs item #3591103, was opened at 2012-11-29 09:22 Message generated for change (Tracker Item Submitted) made by n-perestoronin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3591103&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: Nikita Perestoronin (n-perestoronin) Assigned to: Nobody/Anonymous (nobody) Summary: Dynamic dispatch and passing arguments by reference Initial Comment: I have the following problem when calling methods that accept arguments passed by reference. Consider the following code: import win32com.client import pythoncom sldworks = win32com.client.gencache.EnsureModule('{83A33D31-27C5-11CE-BFD4-00400513BB57}', 0, 21, 0) swconst = win32com.client.gencache.EnsureModule('{4687F359-55D0-4CD3-B6CF-2EB42C11F989}', 0, 21, 0) sw = sldworks.SldWorks() model_path = 'C:\Demo\model.SLDPRT' model, errors, warnings = sw.OpenDoc6(model_path, swconst.constants.swDocPART, swconst.constants.swOpenDocOptions_Silent, '', pythoncom.Missing, pythoncom.Missing) ext = model.Extension In case of static dispatch it works correctly: >>> ext >>> <win32com.gen_py.SldWorks 2013 Type Library.IModelDocExtension instance at 0x206388400> >>> ext.GetAdvancedSpotLightProperties('Ambient') >>> (0.0, 1.0, 0.0, 0.0) In case of dynamic dispatch it sets wrong value for the last argument: dext = win32com.client.dynamic.DumbDispatch(ext) arg1 = win32com.client.VARIANT(pythoncom.VT_BYREF | pythoncom.VT_R8, 0.0) arg2 = win32com.client.VARIANT(pythoncom.VT_BYREF | pythoncom.VT_R8, 0.0) arg3 = win32com.client.VARIANT(pythoncom.VT_BYREF | pythoncom.VT_R8, 0.0) arg4 = win32com.client.VARIANT(pythoncom.VT_BYREF | pythoncom.VT_R8, 0.0) >>> dext >>> <COMObject <unknown>> >>> dext.GetAdvancedSpotLightProperties('Ambient', arg1, arg2, arg3, arg4) >>> arg1.value, arg2.value, arg3.value, arg4.value >>> (0.0, 1.0, 0.0, u'Ambient') I've checked more methods in SolidWorks API: in case of dynamic dispatch, when arguments are passed by reference, value of the last argument equals to the value of the first argument after call. Since pywin32 fails to provide static dispatch object in some cases, (for example, if I call model.SelectionManager, it returns <COMObject SelectionManager>), I can't use some methods in SolidWorks API. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3591103&group_id=78018 |
2 messages has been excluded from this view by a project administrator.
