pywin32-bugs Mailing List for Python for Windows Extensions (Page 26)
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...> - 2011-01-07 19:04:09
|
Bugs item #3153014, was opened at 2011-01-07 09:43 Message generated for change (Comment added) made by rlerche You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3153014&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: Robert Lerche (rlerche) Assigned to: Nobody/Anonymous (nobody) Summary: still can\'t build pywin32-214 from source (alas!) Initial Comment: I downloaded mapilib.i from http://pywin32.cvs.sourceforge.net/viewvc/pywin32/pywin32/com/win32comext/mapi/src/ I deleted and then unzipped pywin32-214.zip, copied mapilib.i and retried \"python setup.py install\". It gets much further but now fails at: E:\\Microsoft Visual Studio 9.0\\VC\\BIN\\nmake.exe /nologo /f makefile_pythonwin SUB_DIR_O=c:\\pywin32-214\\build\\temp.win32-2.7\\Release\\scintilla SUB_DIR_BIN=c:\\pywin32-214\\build\\temp.win32-2.7\\Release\\scintilla DIR_PYTHON=c:\\p\\python-2.7 c:\\p\\python-2.7\\tools\\scripts\\h2py.py Include\\scintilla.h # Generated by h2py from stdin c:\\p\\python-2.7\\tools\\scripts\\h2py.py Include\\scilexer.h # Generated by h2py from stdin type scintilla.py > ..\\pywin\\scintilla\\scintillacon.py The system cannot find the file specified. NMAKE : fatal error U1077: \'type\' : return code \'0x1\' Stop. error: command \'nmake.exe\' failed with exit status 2 I attach the build log and a system info dump. I noticed a bunch of warnings: \"WINVER not defined. Defaulting to 0x0600 (Windows Vista)\". In fact this is Windows/XP SP3 in a VMWare virtual machine. Thanks in advance. Hmmm... "uploaded files must be no larger than 256K". I'm deleting the beginning to comply. ---------------------------------------------------------------------- >Comment By: Robert Lerche (rlerche) Date: 2011-01-07 11:04 Message: Aha again! Some web searching turned up this: Command line arguments in Windows : Python http://objectmix.com/python/355959-command-line-arguments-windows.html My file association for ".py" doesn't include a %* so arguments are not passed to a script! I don't know how this happened. This is what I get for building everything from source. :-) ---------------------------------------------------------------------- Comment By: Robert Lerche (rlerche) Date: 2011-01-07 10:42 Message: OK, it seems like h2py.py is not seeing the filename argument. I don't understand why as yet. ---------------------------------------------------------------------- Comment By: Robert Lerche (rlerche) Date: 2011-01-07 10:15 Message: oops ... nope, it seems to be unable to find "scintilla.py". ---------------------------------------------------------------------- Comment By: Robert Lerche (rlerche) Date: 2011-01-07 09:59 Message: Aha! There's a bug in c:/pywin32-214/pythonwin/Scintilla/makefile_pythonwin: line 49 has 4 spaces instead of a tab before the "type" command (nmake is like Unix make, requires a tab). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3153014&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2011-01-07 18:42:06
|
Bugs item #3153014, was opened at 2011-01-07 09:43 Message generated for change (Comment added) made by rlerche You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3153014&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: Robert Lerche (rlerche) Assigned to: Nobody/Anonymous (nobody) Summary: still can\'t build pywin32-214 from source (alas!) Initial Comment: I downloaded mapilib.i from http://pywin32.cvs.sourceforge.net/viewvc/pywin32/pywin32/com/win32comext/mapi/src/ I deleted and then unzipped pywin32-214.zip, copied mapilib.i and retried \"python setup.py install\". It gets much further but now fails at: E:\\Microsoft Visual Studio 9.0\\VC\\BIN\\nmake.exe /nologo /f makefile_pythonwin SUB_DIR_O=c:\\pywin32-214\\build\\temp.win32-2.7\\Release\\scintilla SUB_DIR_BIN=c:\\pywin32-214\\build\\temp.win32-2.7\\Release\\scintilla DIR_PYTHON=c:\\p\\python-2.7 c:\\p\\python-2.7\\tools\\scripts\\h2py.py Include\\scintilla.h # Generated by h2py from stdin c:\\p\\python-2.7\\tools\\scripts\\h2py.py Include\\scilexer.h # Generated by h2py from stdin type scintilla.py > ..\\pywin\\scintilla\\scintillacon.py The system cannot find the file specified. NMAKE : fatal error U1077: \'type\' : return code \'0x1\' Stop. error: command \'nmake.exe\' failed with exit status 2 I attach the build log and a system info dump. I noticed a bunch of warnings: \"WINVER not defined. Defaulting to 0x0600 (Windows Vista)\". In fact this is Windows/XP SP3 in a VMWare virtual machine. Thanks in advance. Hmmm... "uploaded files must be no larger than 256K". I'm deleting the beginning to comply. ---------------------------------------------------------------------- >Comment By: Robert Lerche (rlerche) Date: 2011-01-07 10:42 Message: OK, it seems like h2py.py is not seeing the filename argument. I don't understand why as yet. ---------------------------------------------------------------------- Comment By: Robert Lerche (rlerche) Date: 2011-01-07 10:15 Message: oops ... nope, it seems to be unable to find "scintilla.py". ---------------------------------------------------------------------- Comment By: Robert Lerche (rlerche) Date: 2011-01-07 09:59 Message: Aha! There's a bug in c:/pywin32-214/pythonwin/Scintilla/makefile_pythonwin: line 49 has 4 spaces instead of a tab before the "type" command (nmake is like Unix make, requires a tab). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3153014&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2011-01-07 18:15:11
|
Bugs item #3153014, was opened at 2011-01-07 09:43 Message generated for change (Comment added) made by rlerche You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3153014&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: Robert Lerche (rlerche) Assigned to: Nobody/Anonymous (nobody) Summary: still can\'t build pywin32-214 from source (alas!) Initial Comment: I downloaded mapilib.i from http://pywin32.cvs.sourceforge.net/viewvc/pywin32/pywin32/com/win32comext/mapi/src/ I deleted and then unzipped pywin32-214.zip, copied mapilib.i and retried \"python setup.py install\". It gets much further but now fails at: E:\\Microsoft Visual Studio 9.0\\VC\\BIN\\nmake.exe /nologo /f makefile_pythonwin SUB_DIR_O=c:\\pywin32-214\\build\\temp.win32-2.7\\Release\\scintilla SUB_DIR_BIN=c:\\pywin32-214\\build\\temp.win32-2.7\\Release\\scintilla DIR_PYTHON=c:\\p\\python-2.7 c:\\p\\python-2.7\\tools\\scripts\\h2py.py Include\\scintilla.h # Generated by h2py from stdin c:\\p\\python-2.7\\tools\\scripts\\h2py.py Include\\scilexer.h # Generated by h2py from stdin type scintilla.py > ..\\pywin\\scintilla\\scintillacon.py The system cannot find the file specified. NMAKE : fatal error U1077: \'type\' : return code \'0x1\' Stop. error: command \'nmake.exe\' failed with exit status 2 I attach the build log and a system info dump. I noticed a bunch of warnings: \"WINVER not defined. Defaulting to 0x0600 (Windows Vista)\". In fact this is Windows/XP SP3 in a VMWare virtual machine. Thanks in advance. Hmmm... "uploaded files must be no larger than 256K". I'm deleting the beginning to comply. ---------------------------------------------------------------------- >Comment By: Robert Lerche (rlerche) Date: 2011-01-07 10:15 Message: oops ... nope, it seems to be unable to find "scintilla.py". ---------------------------------------------------------------------- Comment By: Robert Lerche (rlerche) Date: 2011-01-07 09:59 Message: Aha! There's a bug in c:/pywin32-214/pythonwin/Scintilla/makefile_pythonwin: line 49 has 4 spaces instead of a tab before the "type" command (nmake is like Unix make, requires a tab). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3153014&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2011-01-07 17:59:40
|
Bugs item #3153014, was opened at 2011-01-07 09:43 Message generated for change (Comment added) made by rlerche You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3153014&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: Robert Lerche (rlerche) Assigned to: Nobody/Anonymous (nobody) Summary: still can\'t build pywin32-214 from source (alas!) Initial Comment: I downloaded mapilib.i from http://pywin32.cvs.sourceforge.net/viewvc/pywin32/pywin32/com/win32comext/mapi/src/ I deleted and then unzipped pywin32-214.zip, copied mapilib.i and retried \"python setup.py install\". It gets much further but now fails at: E:\\Microsoft Visual Studio 9.0\\VC\\BIN\\nmake.exe /nologo /f makefile_pythonwin SUB_DIR_O=c:\\pywin32-214\\build\\temp.win32-2.7\\Release\\scintilla SUB_DIR_BIN=c:\\pywin32-214\\build\\temp.win32-2.7\\Release\\scintilla DIR_PYTHON=c:\\p\\python-2.7 c:\\p\\python-2.7\\tools\\scripts\\h2py.py Include\\scintilla.h # Generated by h2py from stdin c:\\p\\python-2.7\\tools\\scripts\\h2py.py Include\\scilexer.h # Generated by h2py from stdin type scintilla.py > ..\\pywin\\scintilla\\scintillacon.py The system cannot find the file specified. NMAKE : fatal error U1077: \'type\' : return code \'0x1\' Stop. error: command \'nmake.exe\' failed with exit status 2 I attach the build log and a system info dump. I noticed a bunch of warnings: \"WINVER not defined. Defaulting to 0x0600 (Windows Vista)\". In fact this is Windows/XP SP3 in a VMWare virtual machine. Thanks in advance. Hmmm... "uploaded files must be no larger than 256K". I'm deleting the beginning to comply. ---------------------------------------------------------------------- >Comment By: Robert Lerche (rlerche) Date: 2011-01-07 09:59 Message: Aha! There's a bug in c:/pywin32-214/pythonwin/Scintilla/makefile_pythonwin: line 49 has 4 spaces instead of a tab before the "type" command (nmake is like Unix make, requires a tab). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3153014&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2011-01-07 17:43:23
|
Bugs item #3153014, was opened at 2011-01-07 09:43 Message generated for change (Tracker Item Submitted) made by rlerche You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3153014&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: Robert Lerche (rlerche) Assigned to: Nobody/Anonymous (nobody) Summary: still can\'t build pywin32-214 from source (alas!) Initial Comment: I downloaded mapilib.i from http://pywin32.cvs.sourceforge.net/viewvc/pywin32/pywin32/com/win32comext/mapi/src/ I deleted and then unzipped pywin32-214.zip, copied mapilib.i and retried \"python setup.py install\". It gets much further but now fails at: E:\\Microsoft Visual Studio 9.0\\VC\\BIN\\nmake.exe /nologo /f makefile_pythonwin SUB_DIR_O=c:\\pywin32-214\\build\\temp.win32-2.7\\Release\\scintilla SUB_DIR_BIN=c:\\pywin32-214\\build\\temp.win32-2.7\\Release\\scintilla DIR_PYTHON=c:\\p\\python-2.7 c:\\p\\python-2.7\\tools\\scripts\\h2py.py Include\\scintilla.h # Generated by h2py from stdin c:\\p\\python-2.7\\tools\\scripts\\h2py.py Include\\scilexer.h # Generated by h2py from stdin type scintilla.py > ..\\pywin\\scintilla\\scintillacon.py The system cannot find the file specified. NMAKE : fatal error U1077: \'type\' : return code \'0x1\' Stop. error: command \'nmake.exe\' failed with exit status 2 I attach the build log and a system info dump. I noticed a bunch of warnings: \"WINVER not defined. Defaulting to 0x0600 (Windows Vista)\". In fact this is Windows/XP SP3 in a VMWare virtual machine. Thanks in advance. Hmmm... "uploaded files must be no larger than 256K". I'm deleting the beginning to comply. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3153014&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2011-01-07 07:57:17
|
Bugs item #3152800, was opened at 2011-01-07 08:57 Message generated for change (Tracker Item Submitted) made by kahlbutz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3152800&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: Klaus Noekel (kahlbutz) Assigned to: Nobody/Anonymous (nobody) Summary: gen_py fails to map type correctly Initial Comment: Hi, I am calling a COM server (written in C++) from Python. The COM server defines methods: interface IMatrix : IDispatch { ... [id(14), helpstring ("Copy matrix contents to a pointer to a C-style 2D double array")] HRESULT GetValuesRaw ( [in] unsigned int hi, [in] unsigned int lo); [id(15), helpstring ("Copy matrix contents from a pointer to a C-style 2D double array")] HRESULT SetValuesRaw ( [in] unsigned int hi, [in] unsigned int lo); } Pywin32 does not pick up the unsigned int, but generates def GetValuesRaw(self, hi=defaultNamedNotOptArg, lo=defaultNamedNotOptArg): """Copy matrix contents to a pointer to a C-style 2D double array""" return self._oleobj_.InvokeTypes(14, LCID, 1, (24, 0), ((3, 1), (3, 1)),hi , lo) where the type id 3 stands for VT_I4 instead of VT_UI4. As you would expect this fails the first time bit 31 of hi or lo is set. Is it a bug in pywin32? If not, how can I influence gen_py so that it correctly recognizes the type? Do I have to write the IDL differently? Can I include hints? Finally, what I really want to achieve is pass a 64-bit pointer from Python to the C++ COM server. Splitting it into the 32-bit hi/lo parts and passing them separately is my current solution. Am I overlooking a better option? Thanks and best regards, Klaus Noekel ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3152800&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2011-01-06 03:15:37
|
Bugs item #3072046, was opened at 2010-09-21 03:27 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3072046&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: Fixed Priority: 5 Private: No Submitted By: don () Assigned to: Nobody/Anonymous (nobody) Summary: mapi.cpp build error Initial Comment: I'm attempting to build pywin32 on my Windows 7 64-bit system. I wasn't sure if this was a supported environment or not, but I thought I'd post this anyway. VS2008 and VS2010 build environments are failing at the same point: Building pywin32 2.7.214.0 mapi.cpp com/win32comext/mapi/src/mapi.cpp(933) : error C3861: 'OleSetOleError': identifier not found com/win32comext/mapi/src/mapi.cpp(995) : error C3861: 'OleSetOleError': identifier not found com/win32comext/mapi/src/mapi.cpp(1165) : error C3861: 'SWIG_GetPtr': identifier not found com/win32comext/mapi/src/mapi.cpp(1220) : error C3861: 'SWIG_GetPtr': identifier not found com/win32comext/mapi/src/mapi.cpp(1268) : error C3861: 'SWIG_GetPtr': identifier not found com/win32comext/mapi/src/mapi.cpp(1315) : error C3861: 'SWIG_GetPtr': identifier not found com/win32comext/mapi/src/mapi.cpp(1321) : error C3861: 'SWIG_GetPtr': identifier not found com/win32comext/mapi/src/mapi.cpp(1327) : error C3861: 'SWIG_GetPtr': identifier not found com/win32comext/mapi/src/mapi.cpp(1333) : error C3861: 'SWIG_GetPtr': identifier not found com/win32comext/mapi/src/mapi.cpp(1339) : error C3861: 'SWIG_GetPtr': identifier not found com/win32comext/mapi/src/mapi.cpp(1389) : error C3861: 'SWIG_GetPtr': identifier not found com/win32comext/mapi/src/mapi.cpp(1452) : error C3861: 'SWIG_GetPtr': identifier not found com/win32comext/mapi/src/mapi.cpp(1458) : error C3861: 'SWIG_GetPtr': identifier not found error: command '"C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\cl.exe"' failed with exit status 2 ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2011-01-06 14:15 Message: Thanks to Robert Lerche in https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3152207&group_id=78018, this problem is caused by mapilib.i not existing in the source distro - if you grab that file (see the other bug) it should all work fine. ---------------------------------------------------------------------- Comment By: mac-es (mac-es) Date: 2010-09-28 21:33 Message: Had the same error, than extracted the .zip to c:\pywin32 (python is in c:\python27) and compiled again -> Success. So maybe pywin should not be compiled from a "deep" subdirectory. ---------------------------------------------------------------------- Comment By: don () Date: 2010-09-21 03:33 Message: Sorry, forgot some interesting output that comes before this point. There are several lines like this referring to various .i files before it gets to mapi.cpp: Generating wrappers for Python c:\Users\dsmith\Downloads\pywin32-214\pywin32-214\com\win32comext\mapi\src\mapi.i : Line 24. Unable to find include file mapilib.i (ignored). Generating wrappers for Python c:\Users\dsmith\Downloads\pywin32-214\pywin32-214\com\win32comext\mapi\src\PyIABContainer.i : Line 8. Unable to find include file mapilib.i (ignored). Generating wrappers for Python c:\Users\dsmith\Downloads\pywin32-214\pywin32-214\com\win32comext\mapi\src\PyIAddrBook.i : Line 6. Unable to find include file mapilib.i (ignored). Generating wrappers for Python c:\Users\dsmith\Downloads\pywin32-214\pywin32-214\com\win32comext\mapi\src\PyIAttach.i : Line 8. Unable to find include file mapilib.i (ignored). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3072046&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2011-01-06 03:13:09
|
Bugs item #3152207, was opened at 2011-01-06 11:45 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3152207&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: Fixed Priority: 5 Private: No Submitted By: Robert Lerche (rlerche) Assigned to: Nobody/Anonymous (nobody) Summary: can't install pywin32-214 source (see #3094208) Initial Comment: Symptom: same as #3094208 but trying to refresh the tree does *not* resolve the problem (as indicated in that bug). The problem seems to be a missing file: mapilib.i. This is a SWIG interface definition file and it is not present in pywin32-214.zip (fetched today from SourceForge). I attach (1) an "unzip -l" showing that mapilib.i is not present, (2) a grep-find of "mapilib" showing where it is included and (3) the build log that fails. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2011-01-06 14:13 Message: Yeah - you are correct. The reason I hadn't noticed before is that the source-dist also ships the generated .cpp files, so usually swig isn't actually invoked. You can grab the missing file at http://pywin32.cvs.sourceforge.net/viewvc/pywin32/pywin32/com/win32comext/mapi/src/ and I've checked in a fix so it will be included in the next release. Checking in MANIFEST.in; new revision: 1.19; previous revision: 1.18 ---------------------------------------------------------------------- Comment By: Robert Lerche (rlerche) Date: 2011-01-06 13:43 Message: See also #3072046 -- but installing sources at c:\ was no help. I'm pretty sure the problem is the missing file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3152207&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2011-01-06 02:43:15
|
Bugs item #3152207, was opened at 2011-01-05 16:45 Message generated for change (Comment added) made by rlerche You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3152207&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: Robert Lerche (rlerche) Assigned to: Nobody/Anonymous (nobody) Summary: can't install pywin32-214 source (see #3094208) Initial Comment: Symptom: same as #3094208 but trying to refresh the tree does *not* resolve the problem (as indicated in that bug). The problem seems to be a missing file: mapilib.i. This is a SWIG interface definition file and it is not present in pywin32-214.zip (fetched today from SourceForge). I attach (1) an "unzip -l" showing that mapilib.i is not present, (2) a grep-find of "mapilib" showing where it is included and (3) the build log that fails. ---------------------------------------------------------------------- >Comment By: Robert Lerche (rlerche) Date: 2011-01-05 18:43 Message: See also #3072046 -- but installing sources at c:\ was no help. I'm pretty sure the problem is the missing file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3152207&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2011-01-06 00:45:36
|
Bugs item #3152207, was opened at 2011-01-05 16:45 Message generated for change (Tracker Item Submitted) made by rlerche You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3152207&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: Robert Lerche (rlerche) Assigned to: Nobody/Anonymous (nobody) Summary: can't install pywin32-214 source (see #3094208) Initial Comment: Symptom: same as #3094208 but trying to refresh the tree does *not* resolve the problem (as indicated in that bug). The problem seems to be a missing file: mapilib.i. This is a SWIG interface definition file and it is not present in pywin32-214.zip (fetched today from SourceForge). I attach (1) an "unzip -l" showing that mapilib.i is not present, (2) a grep-find of "mapilib" showing where it is included and (3) the build log that fails. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3152207&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2011-01-03 02:20:16
|
Bugs item #3150027, was opened at 2011-01-03 13:15 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3150027&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: Dev Player (devplayer) Assigned to: Nobody/Anonymous (nobody) Summary: python.exe help() modules crashes Initial Comment: On Microsoft Windows XP SP3 intel Pentium 4 3.2Ghz/3.2Ghz pc with Python 2.7 installed I installed the file pywin32-214.win32-py2.7.exe When in pycrust, and type help(), then type "modules" without the quotes I get: the standard output of help """ Welcome to Python 2.7! This is the online help utility. If this is your first time using Python, you should definitely check out bla bla bla, lists installed packages and all... """ all the way until the end of the help() modules I then get: """ Traceback (most recent call last): File "<input>", line 1, in <module> File "Q:\Python27\lib\site.py", line 453, in __call__ return pydoc.help(*args, **kwds) File "Q:\Python27\lib\pydoc.py", line 1723, in __call__ self.interact() File "Q:\Python27\lib\pydoc.py", line 1735, in interact request = self.getline('help> ') File "Q:\Python27\lib\pydoc.py", line 1746, in getline return raw_input(prompt) File "Q:\Python27\Lib\site-packages\pythonwin\pywin\framework\app.py", line 367, in Win32RawInput ret=dialog.GetSimpleInput(prompt) File "Q:\Python27\Lib\site-packages\pythonwin\pywin\mfc\dialog.py", line 223, in GetSimpleInput if title is None: title=win32ui.GetMainFrame().GetWindowText() error: The frame does not exist """ While in pycrust and then doing: import win32ui from win32ui import GetMainFrame dir(win32ui.GetMainFrame) I get: ['__call__', '__class__', '__cmp__', '__delattr__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__gt__', '__hash__', '__init__', '__le__', '__lt__', '__module__', '__name__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__self__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__'] dir(GetMainFrame) ['__call__', '__class__', '__cmp__', '__delattr__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__gt__', '__hash__', '__init__', '__le__', '__lt__', '__module__', '__name__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__self__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__'] Thought I'd just try this to be more complete: from GetMainFrame import GetWindowText Traceback (most recent call last): File "<input>", line 1, in <module> ImportError: No module named GetMainFrame I have tried reinstalling from the windows installer file mentioned above with the same result. Note that if I do a "help()", "modules" in IDLE or python.exe I either get a locked up console, or a crash. I would try to install from the cvn if I knew how. Can anyone else replicate this problem? Also this was reported on python bugs tracekr too: http://bugs.python.org/issue10060 ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2011-01-03 13:20 Message: What we need to understand here is how Q:\Python27\Lib\site-packages\pythonwin\pywin\framework\app.py got loaded into the process in the first place - I suspect pycrust may be doing it, which is the root cause of the problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3150027&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2011-01-03 02:15:04
|
Bugs item #3150027, was opened at 2011-01-02 21:15 Message generated for change (Tracker Item Submitted) made by devplayer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3150027&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: Dev Player (devplayer) Assigned to: Nobody/Anonymous (nobody) Summary: python.exe help() modules crashes Initial Comment: On Microsoft Windows XP SP3 intel Pentium 4 3.2Ghz/3.2Ghz pc with Python 2.7 installed I installed the file pywin32-214.win32-py2.7.exe When in pycrust, and type help(), then type "modules" without the quotes I get: the standard output of help """ Welcome to Python 2.7! This is the online help utility. If this is your first time using Python, you should definitely check out bla bla bla, lists installed packages and all... """ all the way until the end of the help() modules I then get: """ Traceback (most recent call last): File "<input>", line 1, in <module> File "Q:\Python27\lib\site.py", line 453, in __call__ return pydoc.help(*args, **kwds) File "Q:\Python27\lib\pydoc.py", line 1723, in __call__ self.interact() File "Q:\Python27\lib\pydoc.py", line 1735, in interact request = self.getline('help> ') File "Q:\Python27\lib\pydoc.py", line 1746, in getline return raw_input(prompt) File "Q:\Python27\Lib\site-packages\pythonwin\pywin\framework\app.py", line 367, in Win32RawInput ret=dialog.GetSimpleInput(prompt) File "Q:\Python27\Lib\site-packages\pythonwin\pywin\mfc\dialog.py", line 223, in GetSimpleInput if title is None: title=win32ui.GetMainFrame().GetWindowText() error: The frame does not exist """ While in pycrust and then doing: import win32ui from win32ui import GetMainFrame dir(win32ui.GetMainFrame) I get: ['__call__', '__class__', '__cmp__', '__delattr__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__gt__', '__hash__', '__init__', '__le__', '__lt__', '__module__', '__name__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__self__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__'] dir(GetMainFrame) ['__call__', '__class__', '__cmp__', '__delattr__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__gt__', '__hash__', '__init__', '__le__', '__lt__', '__module__', '__name__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__self__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__'] Thought I'd just try this to be more complete: from GetMainFrame import GetWindowText Traceback (most recent call last): File "<input>", line 1, in <module> ImportError: No module named GetMainFrame I have tried reinstalling from the windows installer file mentioned above with the same result. Note that if I do a "help()", "modules" in IDLE or python.exe I either get a locked up console, or a crash. I would try to install from the cvn if I knew how. Can anyone else replicate this problem? Also this was reported on python bugs tracekr too: http://bugs.python.org/issue10060 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3150027&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2011-01-01 00:20:05
|
Bugs item #3013558, was opened at 2010-06-09 05:16 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3013558&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: installation Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: KurzedMetal () Assigned to: Nobody/Anonymous (nobody) Summary: install fails when python is installed only for current user Initial Comment: Installing pywin32-214 on Python 2.6 (installed for current user) on windows seven (all 32bits) makes post-install script fails with an esoteric error. I found this when i was trying to deploy python silently (using msiexec /qn swtich) but without using ALLUSERS=1 to install it system-wide. ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2011-01-01 00:20 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: Mark Hammond (mhammond) Date: 2010-12-17 23:42 Message: What is that esoteric error? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3013558&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-12-20 23:43:00
|
Patches item #3083568, was opened at 2010-10-08 18:56 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3083568&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: Patrick Breucking (marquies) Assigned to: Nobody/Anonymous (nobody) Summary: Adding support for IExchangeModifyTables for Rules and ACLs Initial Comment: This patch provides an implementation of the wrapping IExchangeModifyTable interface and the needed utility methods. The patch contains methods to wrap ROWLIST and ACTIONS structures and a set of flags to work with it. Please give me feedback if something is not conform to coding guidelines or other things to change. Thanks Patrick ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2010-12-21 09:00 Message: If you get the latest from cvs and follow the instructions in setup.py, you should be able to get all the exchange modules building with just MSVC and the most recent platform SDK. ---------------------------------------------------------------------- Comment By: Patrick Breucking (marquies) Date: 2010-12-21 00:17 Message: Hi Mark, I'm glad that you respond this patch. I agree with you that this stuff is exchange specific and could be moved. Do you have a hint where to get the exchange sdk files to build the exchange extensions? I have installed this one [1] but I can't find the expected files to compile. I would be pleased if we can fix this problem to continue the integration of this patch [1] http://www.microsoft.com/downloads/details.aspx?familyid=4afe3504-c209-4a73-ac5d-ff2a4a3b48b7 ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2010-12-18 11:34 Message: Sorry for the delay in looking at this. Any chance this could be moved into the exchange module - it seems specific to exchange itself and I'm reluctant to have mapi itself include headers specific to the exchange SDK as I've been burnt before with mapi building but exchange failing. Also, the addition of blank lines which aren't surrounded by other changes should be removed, and it appears OOF_TEXT isn't used so should be removed too. Any reason you had to stick with integer literals instead of macro names in things like: + case 8: //OP_DELEGATE, + lpAction->acttype = OP_DELEGATE; ? OP_DELEGATE must exist as it is used in the following line. + printf ("Fatal Error, can not parse message ID"); Should set a Python error instead of a simple printf - ditto for a couple of other printfs. The addition of EdkMdb.h etc worries me - the copyright statements don't say they are able to be copied - isn't this stuff in the exchange SDK? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3083568&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-12-20 13:17:47
|
Patches item #3083568, was opened at 2010-10-08 09:56 Message generated for change (Comment added) made by marquies You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3083568&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: Patrick Breucking (marquies) Assigned to: Nobody/Anonymous (nobody) Summary: Adding support for IExchangeModifyTables for Rules and ACLs Initial Comment: This patch provides an implementation of the wrapping IExchangeModifyTable interface and the needed utility methods. The patch contains methods to wrap ROWLIST and ACTIONS structures and a set of flags to work with it. Please give me feedback if something is not conform to coding guidelines or other things to change. Thanks Patrick ---------------------------------------------------------------------- >Comment By: Patrick Breucking (marquies) Date: 2010-12-20 14:17 Message: Hi Mark, I'm glad that you respond this patch. I agree with you that this stuff is exchange specific and could be moved. Do you have a hint where to get the exchange sdk files to build the exchange extensions? I have installed this one [1] but I can't find the expected files to compile. I would be pleased if we can fix this problem to continue the integration of this patch [1] http://www.microsoft.com/downloads/details.aspx?familyid=4afe3504-c209-4a73-ac5d-ff2a4a3b48b7 ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2010-12-18 01:34 Message: Sorry for the delay in looking at this. Any chance this could be moved into the exchange module - it seems specific to exchange itself and I'm reluctant to have mapi itself include headers specific to the exchange SDK as I've been burnt before with mapi building but exchange failing. Also, the addition of blank lines which aren't surrounded by other changes should be removed, and it appears OOF_TEXT isn't used so should be removed too. Any reason you had to stick with integer literals instead of macro names in things like: + case 8: //OP_DELEGATE, + lpAction->acttype = OP_DELEGATE; ? OP_DELEGATE must exist as it is used in the following line. + printf ("Fatal Error, can not parse message ID"); Should set a Python error instead of a simple printf - ditto for a couple of other printfs. The addition of EdkMdb.h etc worries me - the copyright statements don't say they are able to be copied - isn't this stuff in the exchange SDK? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3083568&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-12-18 03:30:41
|
Bugs item #3139486, was opened at 2010-12-18 03:30 Message generated for change (Tracker Item Submitted) made by ghazel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3139486&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pythonwin Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Greg Hazel (ghazel) Assigned to: Nobody/Anonymous (nobody) Summary: Prompt to save file with encoding problems Initial Comment: Related to https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3137807&group_id=78018 and another common case I run in to, it would be useful for pythonwin to provide a prompt when it would currently refuse to save a file, which would allow the user to save the file anyway despite possible incorrect encoding. Notepad has similar behavior, which is the alternative I'm forced to use when pythonwin fails. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3139486&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-12-18 01:10:11
|
Bugs item #3130627, was opened at 2010-12-07 06:13 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3130627&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: Christoph Gohlke (cjgohlke) Assigned to: Nobody/Anonymous (nobody) Summary: build fails with Python3.2b1 Initial Comment: Using current pywin32 sources from CVS and Python 3.2b1 binaries from python.org, the build fails with the following error: win32\src\PyUnicode.cpp(258) : error C2664: 'PyUnicodeUCS2_AsWideChar' : cannot convert parameter 1 from 'PyUnicodeObject *' to 'PyObject *' Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast Same for win32\src\win32consolemodule.cpp, line 112. This is related to Python changeset r85298 <http://svn.python.org/view?view=rev&revision=85298>: PyUnicode_AsWideCharString() takes a PyObject*, not a PyUnicodeObject* All unicode functions uses PyObject* except PyUnicode_AsWideChar(). Fix the prototype for the new function PyUnicode_AsWideCharString(). ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2010-12-18 12:10 Message: Fixed: Checking in PyUnicode.cpp; new revision: 1.35; previous revision: 1.34 Checking in win32consolemodule.cpp; new revision: 1.18; previous revision: 1.17 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3130627&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-12-18 00:40:50
|
Patches item #3048854, was opened at 2010-08-20 04:22 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3048854&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: kxroberto (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: mdi_pychecker_update.patch Initial Comment: few things didn't work smooth ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2010-12-18 11:40 Message: Checked in the first part of the patch - thanks! Checking in mdi_pychecker.py; new revision: 1.6; previous revision: 1.5 ---------------------------------------------------------------------- Comment By: kxroberto (kxroberto) Date: 2010-08-26 19:07 Message: the first part "--only" is just a pychecker default option to test/report errors only of code in the explicitely checked file(s) - reasonable for a pychecker run from IDE, and generally. (most python/3rd party *-imported modules (import * from xyz) otherwise cause a lot of less relevant warnings, as only few people use pychecker/pylint. ) yes, the second part is needless if the other patch was accepted ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2010-08-25 17:52 Message: I just changed scriptutils.JumpToDocument to return None on error and your recent patch changed it to return the view object on success - so I think the second part of this patch is no longer needed. What is the first part for? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3048854&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-12-18 00:34:13
|
Patches item #3083568, was opened at 2010-10-08 18:56 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3083568&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: Patrick Breucking (marquies) Assigned to: Nobody/Anonymous (nobody) Summary: Adding support for IExchangeModifyTables for Rules and ACLs Initial Comment: This patch provides an implementation of the wrapping IExchangeModifyTable interface and the needed utility methods. The patch contains methods to wrap ROWLIST and ACTIONS structures and a set of flags to work with it. Please give me feedback if something is not conform to coding guidelines or other things to change. Thanks Patrick ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2010-12-18 11:34 Message: Sorry for the delay in looking at this. Any chance this could be moved into the exchange module - it seems specific to exchange itself and I'm reluctant to have mapi itself include headers specific to the exchange SDK as I've been burnt before with mapi building but exchange failing. Also, the addition of blank lines which aren't surrounded by other changes should be removed, and it appears OOF_TEXT isn't used so should be removed too. Any reason you had to stick with integer literals instead of macro names in things like: + case 8: //OP_DELEGATE, + lpAction->acttype = OP_DELEGATE; ? OP_DELEGATE must exist as it is used in the following line. + printf ("Fatal Error, can not parse message ID"); Should set a Python error instead of a simple printf - ditto for a couple of other printfs. The addition of EdkMdb.h etc worries me - the copyright statements don't say they are able to be copied - isn't this stuff in the exchange SDK? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3083568&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-12-18 00:15:17
|
Patches item #3136751, was opened at 2010-12-14 07:09 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3136751&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: Ziga Seilnacht (zseil) Assigned to: Nobody/Anonymous (nobody) Summary: All BOOLAPI_NL functions in win32event swallow errors Initial Comment: SetEvent, ResetEvent, ReleaseMutex and SetWaitableTimer can still fail even after their handle argument has been validated (e.g. if the handle is closed or if it is a handle to a different object than the one expected by the function). The attached patch simply removes the BOOLAPI_NL and replaces it with error checking BOOLAPI. Tests are also included. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2010-12-18 11:15 Message: Awesome - thanks! Checking in win32/test/test_win32event.py; new revision: 1.4; previous revision: 1.3 Checking in win32/src/win32event.i; new revision: 1.13; previous revision: 1.12 Checking in CHANGES.txt; new revision: 1.66; previous revision: 1.65 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=3136751&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-12-17 23:42:41
|
Bugs item #3013558, was opened at 2010-06-09 15:16 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3013558&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: installation Group: None >Status: Pending Resolution: None Priority: 5 Private: No Submitted By: KurzedMetal () Assigned to: Nobody/Anonymous (nobody) Summary: install fails when python is installed only for current user Initial Comment: Installing pywin32-214 on Python 2.6 (installed for current user) on windows seven (all 32bits) makes post-install script fails with an esoteric error. I found this when i was trying to deploy python silently (using msiexec /qn swtich) but without using ALLUSERS=1 to install it system-wide. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2010-12-18 10:42 Message: What is that esoteric error? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3013558&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-12-17 23:39:10
|
Bugs item #3137807, was opened at 2010-12-15 22:13 Message generated for change (Settings changed) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3137807&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pythonwin Group: None Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Greg Hazel (ghazel) Assigned to: Nobody/Anonymous (nobody) Summary: Pythonwin can't open a file with # -*- encoding: binary -*- Initial Comment: If a file starts with "# -*- encoding: binary -*-", Pythonwin cannot seem to open it. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2010-12-18 10:38 Message: I checked in a fix - but be warned - pythonwin will now open the file but will refuse the save it - it is much harder to argue Pythonwin should *create* invalid files... Checking in Pythonwin/pywin/scintilla/document.py; new revision: 1.13; previous revision: 1.12 ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2010-12-16 10:50 Message: (which actually *is* what happens if the encoding name is known but the decode fails! - so the current check just needs to be extended to cover the invalid encoding case.) ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2010-12-16 10:48 Message: Yeah - I guess it is reasonable that in the case of an unknown encoding pythonwin should print a warning and treat it as latin-1 (the default) instead of dumping an exception.. ---------------------------------------------------------------------- Comment By: Greg Hazel (ghazel) Date: 2010-12-16 10:40 Message: Well, I'm not the original author of any files I've encountered with this preamble, so I can't say why it was chosen, nor can I use something different to start with. However, I believe the author's intention, and certainly a reasonable approach, would be to treat binary encoding like 8bit ascii, which I assume is the same as you would treat it if there was no encoding specified at all. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2010-12-16 10:24 Message: Hrm - pep 263 which defines this behaviour says the encoding must be "known" and my tests demonstrate python itself refuses to work with such files. It is hard to justify a special case for the string "binary" - can't you just use latin-1 or similar to achieve the same result? The issue is pythonwin uses that encoding to determine how to translate the bytes into characters... ---------------------------------------------------------------------- Comment By: Greg Hazel (ghazel) Date: 2010-12-16 08:49 Message: I have run in to this with several source files, which were some reason marked with that preamble but otherwise perfectly editable. Also, I can open notepad.exe in pythonwin just fine. I'm not expecting pythonwin to work miracles and let me edit binary data correctly, I just think it should let me open files no matter what they say at the beginning (like notepad.exe opens just fine). Otherwise, I have to open the file with Wordpad, strip the preamble, then open with Pythonwin (and remember to put it back later). Very troublesome. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2010-12-16 06:43 Message: pythonwin only supports editing text and without a text based encoding it can't do much. If the problem is that the error message is unclear I can look at fixing that, but will not enable actual editing of the file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3137807&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-12-17 23:39:00
|
Bugs item #3137807, was opened at 2010-12-15 22:13 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3137807&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pythonwin Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Greg Hazel (ghazel) Assigned to: Nobody/Anonymous (nobody) Summary: Pythonwin can't open a file with # -*- encoding: binary -*- Initial Comment: If a file starts with "# -*- encoding: binary -*-", Pythonwin cannot seem to open it. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2010-12-18 10:38 Message: I checked in a fix - but be warned - pythonwin will now open the file but will refuse the save it - it is much harder to argue Pythonwin should *create* invalid files... Checking in Pythonwin/pywin/scintilla/document.py; new revision: 1.13; previous revision: 1.12 ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2010-12-16 10:50 Message: (which actually *is* what happens if the encoding name is known but the decode fails! - so the current check just needs to be extended to cover the invalid encoding case.) ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2010-12-16 10:48 Message: Yeah - I guess it is reasonable that in the case of an unknown encoding pythonwin should print a warning and treat it as latin-1 (the default) instead of dumping an exception.. ---------------------------------------------------------------------- Comment By: Greg Hazel (ghazel) Date: 2010-12-16 10:40 Message: Well, I'm not the original author of any files I've encountered with this preamble, so I can't say why it was chosen, nor can I use something different to start with. However, I believe the author's intention, and certainly a reasonable approach, would be to treat binary encoding like 8bit ascii, which I assume is the same as you would treat it if there was no encoding specified at all. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2010-12-16 10:24 Message: Hrm - pep 263 which defines this behaviour says the encoding must be "known" and my tests demonstrate python itself refuses to work with such files. It is hard to justify a special case for the string "binary" - can't you just use latin-1 or similar to achieve the same result? The issue is pythonwin uses that encoding to determine how to translate the bytes into characters... ---------------------------------------------------------------------- Comment By: Greg Hazel (ghazel) Date: 2010-12-16 08:49 Message: I have run in to this with several source files, which were some reason marked with that preamble but otherwise perfectly editable. Also, I can open notepad.exe in pythonwin just fine. I'm not expecting pythonwin to work miracles and let me edit binary data correctly, I just think it should let me open files no matter what they say at the beginning (like notepad.exe opens just fine). Otherwise, I have to open the file with Wordpad, strip the preamble, then open with Pythonwin (and remember to put it back later). Very troublesome. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2010-12-16 06:43 Message: pythonwin only supports editing text and without a text based encoding it can't do much. If the problem is that the error message is unclear I can look at fixing that, but will not enable actual editing of the file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3137807&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-12-17 23:33:04
|
Bugs item #3106331, was opened at 2010-11-10 10:46 Message generated for change (Settings changed) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3106331&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: Dartdog (dartdog) Assigned to: Nobody/Anonymous (nobody) Summary: Install issue? Initial Comment: on win vista 64 (installing win 32 version for python 6.2) I get an error at the end that I don't know if significant? >>closed failed in file object distructor: error in sysexcepthook: original exception was: It was all blank so that is all I can supply... ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2010-12-18 10:33 Message: Dupe of issue 3057047 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3106331&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-12-15 23:50:03
|
Bugs item #3137807, was opened at 2010-12-15 22:13 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3137807&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: Accepted Priority: 5 Private: No Submitted By: Greg Hazel (ghazel) Assigned to: Nobody/Anonymous (nobody) Summary: Pythonwin can't open a file with # -*- encoding: binary -*- Initial Comment: If a file starts with "# -*- encoding: binary -*-", Pythonwin cannot seem to open it. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2010-12-16 10:50 Message: (which actually *is* what happens if the encoding name is known but the decode fails! - so the current check just needs to be extended to cover the invalid encoding case.) ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2010-12-16 10:48 Message: Yeah - I guess it is reasonable that in the case of an unknown encoding pythonwin should print a warning and treat it as latin-1 (the default) instead of dumping an exception.. ---------------------------------------------------------------------- Comment By: Greg Hazel (ghazel) Date: 2010-12-16 10:40 Message: Well, I'm not the original author of any files I've encountered with this preamble, so I can't say why it was chosen, nor can I use something different to start with. However, I believe the author's intention, and certainly a reasonable approach, would be to treat binary encoding like 8bit ascii, which I assume is the same as you would treat it if there was no encoding specified at all. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2010-12-16 10:24 Message: Hrm - pep 263 which defines this behaviour says the encoding must be "known" and my tests demonstrate python itself refuses to work with such files. It is hard to justify a special case for the string "binary" - can't you just use latin-1 or similar to achieve the same result? The issue is pythonwin uses that encoding to determine how to translate the bytes into characters... ---------------------------------------------------------------------- Comment By: Greg Hazel (ghazel) Date: 2010-12-16 08:49 Message: I have run in to this with several source files, which were some reason marked with that preamble but otherwise perfectly editable. Also, I can open notepad.exe in pythonwin just fine. I'm not expecting pythonwin to work miracles and let me edit binary data correctly, I just think it should let me open files no matter what they say at the beginning (like notepad.exe opens just fine). Otherwise, I have to open the file with Wordpad, strip the preamble, then open with Pythonwin (and remember to put it back later). Very troublesome. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2010-12-16 06:43 Message: pythonwin only supports editing text and without a text based encoding it can't do much. If the problem is that the error message is unclear I can look at fixing that, but will not enable actual editing of the file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=3137807&group_id=78018 |
2 messages has been excluded from this view by a project administrator.
