pywin32-bugs Mailing List for Python for Windows Extensions (Page 38)
OLD project page for the Python extensions for Windows
Brought to you by:
mhammond
Menu
▾
▴
pywin32-bugs — Automated tracker notifications (not for bug reports!)
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
(24) |
May
(19) |
Jun
(15) |
Jul
(43) |
Aug
(39) |
Sep
(25) |
Oct
(43) |
Nov
(19) |
Dec
(4) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(21) |
Feb
(18) |
Mar
(14) |
Apr
(80) |
May
(56) |
Jun
(24) |
Jul
(30) |
Aug
(17) |
Sep
(36) |
Oct
(106) |
Nov
(38) |
Dec
(30) |
| 2005 |
Jan
(14) |
Feb
(14) |
Mar
(48) |
Apr
(28) |
May
(49) |
Jun
(23) |
Jul
(9) |
Aug
(13) |
Sep
(28) |
Oct
(21) |
Nov
(8) |
Dec
(26) |
| 2006 |
Jan
(56) |
Feb
(33) |
Mar
(33) |
Apr
(18) |
May
(16) |
Jun
(9) |
Jul
(24) |
Aug
(16) |
Sep
(14) |
Oct
(37) |
Nov
(38) |
Dec
(22) |
| 2007 |
Jan
(7) |
Feb
(16) |
Mar
(11) |
Apr
(15) |
May
(15) |
Jun
(8) |
Jul
(24) |
Aug
(26) |
Sep
(18) |
Oct
(11) |
Nov
(20) |
Dec
(1) |
| 2008 |
Jan
(19) |
Feb
(55) |
Mar
(7) |
Apr
(35) |
May
(66) |
Jun
(38) |
Jul
(26) |
Aug
(5) |
Sep
(25) |
Oct
(25) |
Nov
(18) |
Dec
(18) |
| 2009 |
Jan
(25) |
Feb
(38) |
Mar
(29) |
Apr
(25) |
May
(5) |
Jun
(11) |
Jul
(16) |
Aug
(16) |
Sep
(16) |
Oct
(1) |
Nov
(15) |
Dec
(33) |
| 2010 |
Jan
(13) |
Feb
(11) |
Mar
(1) |
Apr
(24) |
May
(26) |
Jun
(19) |
Jul
(22) |
Aug
(51) |
Sep
(38) |
Oct
(39) |
Nov
(25) |
Dec
(27) |
| 2011 |
Jan
(40) |
Feb
(31) |
Mar
(21) |
Apr
(42) |
May
(11) |
Jun
(16) |
Jul
(20) |
Aug
(14) |
Sep
(6) |
Oct
(8) |
Nov
(34) |
Dec
(7) |
| 2012 |
Jan
(60) |
Feb
(24) |
Mar
(6) |
Apr
(28) |
May
(41) |
Jun
(15) |
Jul
(14) |
Aug
(25) |
Sep
(30) |
Oct
(18) |
Nov
(30) |
Dec
(9) |
| 2013 |
Jan
(3) |
Feb
(8) |
Mar
(17) |
Apr
(23) |
May
(34) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
|
From: SourceForge.net <no...@so...> - 2010-01-18 15:39:47
|
Bugs item #2934349, was opened at 2010-01-18 17:39 Message generated for change (Tracker Item Submitted) made by emakital You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2934349&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: Eino Mäkitalo (emakital) Assigned to: Nobody/Anonymous (nobody) Summary: python 3.1 and pywin 214 gives some errors when installing Initial Comment: python 3.1 and pywin 214 gives some errors when installing: Traceback (most recent call last): File "<string>", line 601, in <module> File "<string>", line 329, in install File "<string>", line 15, in write AttributeError: 'NoneType' object has no attribute 'write' ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2934349&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-01-16 18:54:34
|
Bugs item #2933477, was opened at 2010-01-16 12:51 Message generated for change (Settings changed) made by programmer09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2933477&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: 9 Private: No Submitted By: Tyler (programmer09) Assigned to: Nobody/Anonymous (nobody) Summary: Two Link Errors: LNK2001 and LNK1120 Initial Comment: I was able to fix the previous issue (ID 2929574) by inserting this line in win32/src/win32job_py2_swig.cpp (generated in setup.py): long JOB_OBJECT_LIMIT_RESERVED2=0X00000000L; right before the call to PyInt_FromLong() on the next line. With that issue resolved, I continued the build, but then I got two errors (both linker errors, no compiler errors): ...Previous output... Creating library build\temp.win32-2.6\Release\com/win32comext/axdebug/src\axdebug.lib and object build\temp.win32-2.6\Release\com/win32comext/axdebug/src\axdebug.exp AXDebug.obj : error LNK2001: unresolved external symbol _CLSID_MachineDebugManager build\lib.win32-2.6\win32comext/axdebug\axdebug.pyd : fatal error LNK1120: 1 unresolved externals error: command '"C:\Program Files\Microsoft Visual Studio 9.0\VC\BIN\link.exe"' failed with exit status 1120 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2933477&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-01-16 18:51:56
|
Bugs item #2933477, was opened at 2010-01-16 12:51 Message generated for change (Tracker Item Submitted) made by programmer09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2933477&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: Tyler (programmer09) Assigned to: Nobody/Anonymous (nobody) Summary: Two Link Errors: LNK2001 and LNK1120 Initial Comment: I was able to fix the previous issue (ID 2929574) by inserting this line in win32/src/win32job_py2_swig.cpp (generated in setup.py): long JOB_OBJECT_LIMIT_RESERVED2=0X00000000L; right before the call to PyInt_FromLong() on the next line. With that issue resolved, I continued the build, but then I got two errors (both linker errors, no compiler errors): ...Previous output... Creating library build\temp.win32-2.6\Release\com/win32comext/axdebug/src\axdebug.lib and object build\temp.win32-2.6\Release\com/win32comext/axdebug/src\axdebug.exp AXDebug.obj : error LNK2001: unresolved external symbol _CLSID_MachineDebugManager build\lib.win32-2.6\win32comext/axdebug\axdebug.pyd : fatal error LNK1120: 1 unresolved externals error: command '"C:\Program Files\Microsoft Visual Studio 9.0\VC\BIN\link.exe"' failed with exit status 1120 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2933477&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-01-11 03:01:57
|
Bugs item #2929574, was opened at 2010-01-10 21:01 Message generated for change (Tracker Item Submitted) made by programmer09 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2929574&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: Tyler (programmer09) Assigned to: Nobody/Anonymous (nobody) Summary: Win32Job Fails to Build Initial Comment: I get an error about an undeclared identifier when I try to build PyWin32-214. I have Visual Studio 2008, with the Windows SDK for Windows 7, Windows XP Pro (SP3), Python 2.6.4. Attached is the output of python setup.py -v build that I redirected to a file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2929574&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-01-08 18:41:33
|
Bugs item #2928439, was opened at 2010-01-08 19:40 Message generated for change (Settings changed) made by asklucas You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2928439&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: asklucas (asklucas) Assigned to: Nobody/Anonymous (nobody) Summary: win32com.mapi.mapi missing in 3.1 release? Initial Comment: I'm just a Python newbie so forgive me, if I did something wrong. The demo mapisend.py works fine using the 2.6 release, but using the 3.1 release I get the error below. I also noticed that the library mapi.pyd ist missing in 3.1. PythonWin 3.1.1 (r311:74483, Aug 17 2009, 17:02:12) [MSC v.1500 32 bit (Intel)] on win32. Portions Copyright 1994-2008 Mark Hammond - see 'Help/About PythonWin' for further copyright information. Traceback (most recent call last): File "C:\dev\Python31\Lib\site-packages\pythonwin\pywin\framework\scriptutils.py", line 322, in RunScript debugger.run(codeObject, __main__.__dict__, start_stepping=0) File "C:\dev\Python31\Lib\site-packages\pythonwin\pywin\debugger\__init__.py", line 60, in run _GetCurrentDebugger().run(cmd, globals,locals, start_stepping) File "C:\dev\Python31\Lib\site-packages\pythonwin\pywin\debugger\debugger.py", line 655, in run exec(cmd, globals, locals) File "C:\dev\PyMAPIAddMailbox\mapisend.py", line 9, in <module> from win32com.mapi import mapi ImportError: cannot import name mapi >>> from win32com.mapi import mapi Traceback (most recent call last): File "<interactive input>", line 1, in <module> ImportError: cannot import name mapi >>> from win32com.mapi import mapitags >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2928439&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-01-08 18:40:22
|
Bugs item #2928439, was opened at 2010-01-08 19:40 Message generated for change (Tracker Item Submitted) made by asklucas You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2928439&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: asklucas (asklucas) Assigned to: Nobody/Anonymous (nobody) Summary: win32com.mapi.mapi missing in 3.1 release? Initial Comment: I'm just a Python newbie so forgive me, if I did something wrong. The demo mapisend.py works fine using the 2.6 release, but using the 3.1 release I get the error below. I also noticed that the library mapi.pyd ist missing in 3.1. PythonWin 3.1.1 (r311:74483, Aug 17 2009, 17:02:12) [MSC v.1500 32 bit (Intel)] on win32. Portions Copyright 1994-2008 Mark Hammond - see 'Help/About PythonWin' for further copyright information. Traceback (most recent call last): File "C:\dev\Python31\Lib\site-packages\pythonwin\pywin\framework\scriptutils.py", line 322, in RunScript debugger.run(codeObject, __main__.__dict__, start_stepping=0) File "C:\dev\Python31\Lib\site-packages\pythonwin\pywin\debugger\__init__.py", line 60, in run _GetCurrentDebugger().run(cmd, globals,locals, start_stepping) File "C:\dev\Python31\Lib\site-packages\pythonwin\pywin\debugger\debugger.py", line 655, in run exec(cmd, globals, locals) File "C:\dev\PyMAPIAddMailbox\mapisend.py", line 9, in <module> from win32com.mapi import mapi ImportError: cannot import name mapi >>> from win32com.mapi import mapi Traceback (most recent call last): File "<interactive input>", line 1, in <module> ImportError: cannot import name mapi >>> from win32com.mapi import mapitags >>> ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2928439&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-01-08 13:24:07
|
Bugs item #2928261, was opened at 2010-01-08 14:20 Message generated for change (Settings changed) made by uloebich You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2928261&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: vdb3000 (uloebich) Assigned to: Nobody/Anonymous (nobody) Summary: Installation pywin32-214.win32-py2.6.exe fails (ImportError) Initial Comment: After copying all(?) files the installation procedure terminates with the following message: Traceback (most recent call last): File "<string>", line 601, in <module> File "<string>", line 311, in install File "<string>", line 149, in LoadSystemModule ImportError: DLL load failed: Diese Anwendung konnte nicht gestartet werden, weil die Anwenungskonfiguration nicht korrekt ist. Zur Problembehebung sollten Sie die Anwendung neu installieren. OS is WInXP Professional SP3; I installed everything as normal Win-User, not Admin! Latest Python version is installed (python-2.6.4.msi). Older Version 2.4 can be installed without any trouble. I could not find any error report containing the above in conjunction with branch 214. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2928261&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-01-08 13:20:53
|
Bugs item #2928261, was opened at 2010-01-08 14:20 Message generated for change (Tracker Item Submitted) made by uloebich You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2928261&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: vdb3000 (uloebich) Assigned to: Nobody/Anonymous (nobody) Summary: Installation pywin32-214.win32-py2.6.exe fails (ImportError) Initial Comment: After copying all(?) files the installation procedure terminates with the following message: Traceback (most recent call last): File "<string>", line 601, in <module> File "<string>", line 311, in install File "<string>", line 149, in LoadSystemModule ImportError: DLL load failed: Diese Anwendung konnte nicht gestartet werden, weil die Anwenungskonfiguration nicht korrekt ist. Zur Problembehebung sollten Sie die Anwendung neu installieren. OS is WInXP Professional SP3; I installed everything as normal Win-User, not Admin! Latest Python version is installed (python-2.6.4.msi). Older Version 2.4 can be installed without any trouble. I could not find any error report containing the above in conjunction with branch 214. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2928261&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2010-01-02 02:10:57
|
Bugs item #2924128, was opened at 2009-12-31 22:25 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2924128&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open >Resolution: Accepted Priority: 5 Private: No Submitted By: rolyapples (rolyapples) >Assigned to: Mark Hammond (mhammond) Summary: Crash in dispatchServiceCtrl() for service with power event Initial Comment: If you create a service that accepts power events (by overriding GetAcceptedControls), the service will crash in dispatchServiceCtrl() when any power event other than PBT_POWERSETTINGCHANGE occurs. The problem is that the code assumes eventData for a SERVICE_CONTROL_POWEREVENT is always a pointer to a POWERBROADCAST_SETTING structure, however that is only the case when dwEventType is PBT_POWERSETTINGCHANGE. For other event types (e.g. PBT_APMSUSPEND), the eventData is null. To reproduce: 1. From your python install directory run "python Lib\site-packages\win32\Demos\service\serviceEvents.py install" 2. Run "python Lib\site-packages\win32\Demos\service\serviceEvents.py start" 3. Put your machine to sleep 4. Wake your machine 5. Check the windows application event log - see that there's an error for the service & that the service is no longer running Changing this in dispatchServiceCtrl() in PythonService.cpp: case SERVICE_CONTROL_POWEREVENT: { POWERBROADCAST_SETTING *pbs = (POWERBROADCAST_SETTING *)eventData; sub = Py_BuildValue("NN", PyWinObject_FromIID(pbs->PowerSetting), PyString_FromStringAndSize((char *)pbs->Data, pbs->DataLength)); break; To the following is working for me: case SERVICE_CONTROL_POWEREVENT: { if (dwEventType == PBT_POWERSETTINGCHANGE) { POWERBROADCAST_SETTING *pbs = (POWERBROADCAST_SETTING *)eventData; sub = Py_BuildValue("NN", PyWinObject_FromIID(pbs->PowerSetting), PyString_FromStringAndSize((char *)pbs->Data, pbs->DataLength)); } else { sub = Py_None; Py_INCREF(sub); } break; ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2010-01-02 13:10 Message: looks good, thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2924128&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2009-12-31 11:25:48
|
Bugs item #2924128, was opened at 2009-12-31 11:25 Message generated for change (Tracker Item Submitted) made by rolyapples You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2924128&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: rolyapples (rolyapples) Assigned to: Nobody/Anonymous (nobody) Summary: Crash in dispatchServiceCtrl() for service with power event Initial Comment: If you create a service that accepts power events (by overriding GetAcceptedControls), the service will crash in dispatchServiceCtrl() when any power event other than PBT_POWERSETTINGCHANGE occurs. The problem is that the code assumes eventData for a SERVICE_CONTROL_POWEREVENT is always a pointer to a POWERBROADCAST_SETTING structure, however that is only the case when dwEventType is PBT_POWERSETTINGCHANGE. For other event types (e.g. PBT_APMSUSPEND), the eventData is null. To reproduce: 1. From your python install directory run "python Lib\site-packages\win32\Demos\service\serviceEvents.py install" 2. Run "python Lib\site-packages\win32\Demos\service\serviceEvents.py start" 3. Put your machine to sleep 4. Wake your machine 5. Check the windows application event log - see that there's an error for the service & that the service is no longer running Changing this in dispatchServiceCtrl() in PythonService.cpp: case SERVICE_CONTROL_POWEREVENT: { POWERBROADCAST_SETTING *pbs = (POWERBROADCAST_SETTING *)eventData; sub = Py_BuildValue("NN", PyWinObject_FromIID(pbs->PowerSetting), PyString_FromStringAndSize((char *)pbs->Data, pbs->DataLength)); break; To the following is working for me: case SERVICE_CONTROL_POWEREVENT: { if (dwEventType == PBT_POWERSETTINGCHANGE) { POWERBROADCAST_SETTING *pbs = (POWERBROADCAST_SETTING *)eventData; sub = Py_BuildValue("NN", PyWinObject_FromIID(pbs->PowerSetting), PyString_FromStringAndSize((char *)pbs->Data, pbs->DataLength)); } else { sub = Py_None; Py_INCREF(sub); } break; ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2924128&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2009-12-30 03:36:16
|
Feature Requests item #2803660, was opened at 2009-06-09 13:06 Message generated for change (Comment added) made by bbondy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=2803660&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: Neno Ganchev (talon_karrde) Assigned to: Nobody/Anonymous (nobody) Summary: WNetGetConnection not exposed Initial Comment: WNetGetConnection is not available in the win32wnet module. I noticed similar feature requests for other routines but didn't find one for WNetGetConnection, so I thought I should report it. ---------------------------------------------------------------------- >Comment By: Brian R. Bondy (bbondy) Date: 2009-12-29 22:36 Message: This is implemented and working, will submit patch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=2803660&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2009-12-24 07:47:31
|
Bugs item #2920544, was opened at 2009-12-24 07:47 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2920544&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: happyhondje () Assigned to: Nobody/Anonymous (nobody) Summary: SetScriptSite() returns E_FAIL Initial Comment: When using Python 3.0 or 3.1 (and the corresponding Pywin32 package) programs can't initialize the scripting engine properly. When using SetScriptSite, they get E_FAIL (80040005) thus preventing initalization. Using pywin32 with the 2.x tree works fine. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2920544&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2009-12-24 07:43:52
|
Bugs item #2920507, was opened at 2009-12-24 05:24 Message generated for change (Comment added) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2920507&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: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: Cannot register active scripting with pyscript.py Initial Comment: Using Windows 7 Ultimate, I am having trouble installing active scripting for Python 3.1. I'm talking about the following installers: python-3.1.1.msi pywin32-214.win32-py3.1.exe On WXP, it would usually install active scripting fine from the get-go, but I knew from experience that failed sometimes, which it did now. So I went to C:\Python31\Lib\site-packages\win32comext\axscript\client and ran pyscript.py. Whereas in the past, that would work, I get very colourful errors. First one dialog that is littered with random characters that seem like chinese right after displaying the 'Requesting elevation and retrying...' line, once even a full page of that corrupted junk. Example: '[Window Title] 㩃坜湩潤獷獜獹整㍭尲浣硥e†ɛ础䫁湥耀ɂ洨ɂ欠ɂ쥨ɂ槠ɂ즸ɂ죈ɂ棈ɂ硋䫁睯耀ɂ辀ɂ輰ɂ쩘ɂ計ɂ뱠ɂ歯湥⠠硎䫁汰耀 ɂ쭈ɂ苘ɂ莠ɂ쯨ɂ衸ɂ걨Ɂ靐Ɂ硑䫁杮耀%ɂ蟘ɂ蠀ɂ챠ɂ諸ɂ軠ɂ鿨ḟ雠Ɂ硔䫁漠耀*?痨?и?欰Ḝ畂汩偤瑡彨牟敶硟䫁琊耀/ḟ锐Ɂ铠Ɂ钀Ɂ鑰ɁꮐɁꯀɁ隰Ɂ硢䫁敭耀4ḟ鿨ḟ需Ɂ鿨ḟ鿨ḟ陀Ɂ鿨ḟ靀Ɂ硥䫁耀9ḟ鿨ḟ꤈Ɂ隐Ɂ鿨ḟ隀Ɂ鿨ḟ霰Ɂ硨䫁桴耀>久佃䥄䝎琠歯湥眊楨档琠汥獬礠畯硳䫁档耀C摯湩慷獵摥琠敤潣敤琠敨戠硶䫁猠耀H᩵ [Content] Windows cannot find '㩃坜湩潤獷獜獹整㍭尲浣硥e†ɛ础䫁湥耀ɂ洨ɂ欠ɂ쥨ɂ槠ɂ즸ɂ죈ɂ棈ɂ硋䫁睯耀ɂ辀ɂ輰ɂ쩘ɂ計ɂ뱠ɂ歯湥⠠硎䫁汰耀 ɂ쭈ɂ苘ɂ莠ɂ쯨ɂ衸ɂ걨Ɂ靐Ɂ硑䫁杮耀%ɂ蟘ɂ蠀ɂ챠ɂ諸ɂ軠ɂ鿨ḟ雠Ɂ硔䫁漠耀*?痨?и?欰Ḝ畂汩偤瑡彨牟敶硟䫁琊耀/ḟ锐Ɂ铠Ɂ钀Ɂ鑰ɁꮐɁꯀɁ隰Ɂ硢䫁敭耀4ḟ鿨ḟ需Ɂ鿨ḟ鿨ḟ陀Ɂ鿨ḟ靀Ɂ硥䫁耀9ḟ鿨ḟ꤈Ɂ隐Ɂ鿨ḟ隀Ɂ鿨ḟ霰Ɂ硨䫁桴耀>久佃䥄䝎琠歯湥眊楨档琠汥獬礠畯硳䫁档耀C摯湩慷獵摥琠敤潣敤琠敨戠硶䫁猠耀H᩵'. Make sure you typed the name correctly, and then try again. [OK] This makes me think buffer overrun or some codepage/encoding issues. After that I get an ordinary stacktrace: Requesting elevation and retrying... Failed to remove tempfile 'c:\users\me\appdata\local\temp\tmpx2_leopycomserverreg.out': [Error 2] The system cannot find the file specified: 'c:\\users\\me\\appdata\\local\\temp\\tmpx2_leopycomserverreg.out' Traceback (most recent call last): File "C:\Python31\lib\site-packages\win32com\server\register.py", line 566, in UseCommandLine RegisterClasses(*classes, **flags) File "C:\Python31\lib\site-packages\win32com\server\register.py", line 421, in RegisterClasses addPyComCat, dispatcherSpec, clsctx, addnPath) File "C:\Python31\lib\site-packages\win32com\server\register.py", line 187, in RegisterServer _set_string(keyNameRoot, desc) File "C:\Python31\lib\site-packages\win32com\server\register.py", line 32, in _set_string value) pywintypes.error: (5, 'RegSetValue', 'Access is denied.') During handling of the above exception, another exception occurred: Traceback (most recent call last): File "C:\Python31\Lib\site-packages\win32comext\axscript\client\pyscript.py", line 372, in <module> Register() File "C:\Python31\Lib\site-packages\win32comext\axscript\client\pyscript.py", line 368, in Register finalize_register=DllRegisterServer) File "C:\Python31\lib\site-packages\win32com\server\register.py", line 574, in UseCommandLine ReExecuteElevated(flags) File "C:\Python31\lib\site-packages\win32com\server\register.py", line 531, in ReExecuteElevated nShow=win32con.SW_SHOW) pywintypes.error: (2, 'ShellExecuteEx', 'The system cannot find the file specified.') Are there any simple temporary fixes for this? I'd love to get this up and running. :) ---------------------------------------------------------------------- >Comment By: https://www.google.com/accounts () Date: 2009-12-24 07:43 Message: Yeah I found that out myself after like one hour of code-sifting. Thanks :) ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2009-12-24 05:30 Message: A work around may be to use an elevated command prompt (ie, started with "Run as Administrator") and executing pyscript.py there. If that fails too, I suspect it will be a general problem with Python 3.x - trying Python 2.6 should also work. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2920507&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2009-12-24 05:30:41
|
Bugs item #2920507, was opened at 2009-12-24 16:24 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2920507&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: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: Cannot register active scripting with pyscript.py Initial Comment: Using Windows 7 Ultimate, I am having trouble installing active scripting for Python 3.1. I'm talking about the following installers: python-3.1.1.msi pywin32-214.win32-py3.1.exe On WXP, it would usually install active scripting fine from the get-go, but I knew from experience that failed sometimes, which it did now. So I went to C:\Python31\Lib\site-packages\win32comext\axscript\client and ran pyscript.py. Whereas in the past, that would work, I get very colourful errors. First one dialog that is littered with random characters that seem like chinese right after displaying the 'Requesting elevation and retrying...' line, once even a full page of that corrupted junk. Example: '[Window Title] 㩃坜湩潤獷獜獹整㍭尲浣硥e†ɛ础䫁湥耀ɂ洨ɂ欠ɂ쥨ɂ槠ɂ즸ɂ죈ɂ棈ɂ硋䫁睯耀ɂ辀ɂ輰ɂ쩘ɂ計ɂ뱠ɂ歯湥⠠硎䫁汰耀 ɂ쭈ɂ苘ɂ莠ɂ쯨ɂ衸ɂ걨Ɂ靐Ɂ硑䫁杮耀%ɂ蟘ɂ蠀ɂ챠ɂ諸ɂ軠ɂ鿨ḟ雠Ɂ硔䫁漠耀*?痨?и?欰Ḝ畂汩偤瑡彨牟敶硟䫁琊耀/ḟ锐Ɂ铠Ɂ钀Ɂ鑰ɁꮐɁꯀɁ隰Ɂ硢䫁敭耀4ḟ鿨ḟ需Ɂ鿨ḟ鿨ḟ陀Ɂ鿨ḟ靀Ɂ硥䫁耀9ḟ鿨ḟ꤈Ɂ隐Ɂ鿨ḟ隀Ɂ鿨ḟ霰Ɂ硨䫁桴耀>久佃䥄䝎琠歯湥眊楨档琠汥獬礠畯硳䫁档耀C摯湩慷獵摥琠敤潣敤琠敨戠硶䫁猠耀H᩵ [Content] Windows cannot find '㩃坜湩潤獷獜獹整㍭尲浣硥e†ɛ础䫁湥耀ɂ洨ɂ欠ɂ쥨ɂ槠ɂ즸ɂ죈ɂ棈ɂ硋䫁睯耀ɂ辀ɂ輰ɂ쩘ɂ計ɂ뱠ɂ歯湥⠠硎䫁汰耀 ɂ쭈ɂ苘ɂ莠ɂ쯨ɂ衸ɂ걨Ɂ靐Ɂ硑䫁杮耀%ɂ蟘ɂ蠀ɂ챠ɂ諸ɂ軠ɂ鿨ḟ雠Ɂ硔䫁漠耀*?痨?и?欰Ḝ畂汩偤瑡彨牟敶硟䫁琊耀/ḟ锐Ɂ铠Ɂ钀Ɂ鑰ɁꮐɁꯀɁ隰Ɂ硢䫁敭耀4ḟ鿨ḟ需Ɂ鿨ḟ鿨ḟ陀Ɂ鿨ḟ靀Ɂ硥䫁耀9ḟ鿨ḟ꤈Ɂ隐Ɂ鿨ḟ隀Ɂ鿨ḟ霰Ɂ硨䫁桴耀>久佃䥄䝎琠歯湥眊楨档琠汥獬礠畯硳䫁档耀C摯湩慷獵摥琠敤潣敤琠敨戠硶䫁猠耀H᩵'. Make sure you typed the name correctly, and then try again. [OK] This makes me think buffer overrun or some codepage/encoding issues. After that I get an ordinary stacktrace: Requesting elevation and retrying... Failed to remove tempfile 'c:\users\me\appdata\local\temp\tmpx2_leopycomserverreg.out': [Error 2] The system cannot find the file specified: 'c:\\users\\me\\appdata\\local\\temp\\tmpx2_leopycomserverreg.out' Traceback (most recent call last): File "C:\Python31\lib\site-packages\win32com\server\register.py", line 566, in UseCommandLine RegisterClasses(*classes, **flags) File "C:\Python31\lib\site-packages\win32com\server\register.py", line 421, in RegisterClasses addPyComCat, dispatcherSpec, clsctx, addnPath) File "C:\Python31\lib\site-packages\win32com\server\register.py", line 187, in RegisterServer _set_string(keyNameRoot, desc) File "C:\Python31\lib\site-packages\win32com\server\register.py", line 32, in _set_string value) pywintypes.error: (5, 'RegSetValue', 'Access is denied.') During handling of the above exception, another exception occurred: Traceback (most recent call last): File "C:\Python31\Lib\site-packages\win32comext\axscript\client\pyscript.py", line 372, in <module> Register() File "C:\Python31\Lib\site-packages\win32comext\axscript\client\pyscript.py", line 368, in Register finalize_register=DllRegisterServer) File "C:\Python31\lib\site-packages\win32com\server\register.py", line 574, in UseCommandLine ReExecuteElevated(flags) File "C:\Python31\lib\site-packages\win32com\server\register.py", line 531, in ReExecuteElevated nShow=win32con.SW_SHOW) pywintypes.error: (2, 'ShellExecuteEx', 'The system cannot find the file specified.') Are there any simple temporary fixes for this? I'd love to get this up and running. :) ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2009-12-24 16:30 Message: A work around may be to use an elevated command prompt (ie, started with "Run as Administrator") and executing pyscript.py there. If that fails too, I suspect it will be a general problem with Python 3.x - trying Python 2.6 should also work. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2920507&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2009-12-24 05:24:26
|
Bugs item #2920507, was opened at 2009-12-24 05:24 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2920507&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: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: Cannot register active scripting with pyscript.py Initial Comment: Using Windows 7 Ultimate, I am having trouble installing active scripting for Python 3.1. I'm talking about the following installers: python-3.1.1.msi pywin32-214.win32-py3.1.exe On WXP, it would usually install active scripting fine from the get-go, but I knew from experience that failed sometimes, which it did now. So I went to C:\Python31\Lib\site-packages\win32comext\axscript\client and ran pyscript.py. Whereas in the past, that would work, I get very colourful errors. First one dialog that is littered with random characters that seem like chinese right after displaying the 'Requesting elevation and retrying...' line, once even a full page of that corrupted junk. Example: '[Window Title] 㩃坜湩潤獷獜獹整㍭尲浣硥e†ɛ础䫁湥耀ɂ洨ɂ欠ɂ쥨ɂ槠ɂ즸ɂ죈ɂ棈ɂ硋䫁睯耀ɂ辀ɂ輰ɂ쩘ɂ計ɂ뱠ɂ歯湥⠠硎䫁汰耀 ɂ쭈ɂ苘ɂ莠ɂ쯨ɂ衸ɂ걨Ɂ靐Ɂ硑䫁杮耀%ɂ蟘ɂ蠀ɂ챠ɂ諸ɂ軠ɂ鿨ḟ雠Ɂ硔䫁漠耀*?痨?и?欰Ḝ畂汩偤瑡彨牟敶硟䫁琊耀/ḟ锐Ɂ铠Ɂ钀Ɂ鑰ɁꮐɁꯀɁ隰Ɂ硢䫁敭耀4ḟ鿨ḟ需Ɂ鿨ḟ鿨ḟ陀Ɂ鿨ḟ靀Ɂ硥䫁耀9ḟ鿨ḟ꤈Ɂ隐Ɂ鿨ḟ隀Ɂ鿨ḟ霰Ɂ硨䫁桴耀>久佃䥄䝎琠歯湥眊楨档琠汥獬礠畯硳䫁档耀C摯湩慷獵摥琠敤潣敤琠敨戠硶䫁猠耀H᩵ [Content] Windows cannot find '㩃坜湩潤獷獜獹整㍭尲浣硥e†ɛ础䫁湥耀ɂ洨ɂ欠ɂ쥨ɂ槠ɂ즸ɂ죈ɂ棈ɂ硋䫁睯耀ɂ辀ɂ輰ɂ쩘ɂ計ɂ뱠ɂ歯湥⠠硎䫁汰耀 ɂ쭈ɂ苘ɂ莠ɂ쯨ɂ衸ɂ걨Ɂ靐Ɂ硑䫁杮耀%ɂ蟘ɂ蠀ɂ챠ɂ諸ɂ軠ɂ鿨ḟ雠Ɂ硔䫁漠耀*?痨?и?欰Ḝ畂汩偤瑡彨牟敶硟䫁琊耀/ḟ锐Ɂ铠Ɂ钀Ɂ鑰ɁꮐɁꯀɁ隰Ɂ硢䫁敭耀4ḟ鿨ḟ需Ɂ鿨ḟ鿨ḟ陀Ɂ鿨ḟ靀Ɂ硥䫁耀9ḟ鿨ḟ꤈Ɂ隐Ɂ鿨ḟ隀Ɂ鿨ḟ霰Ɂ硨䫁桴耀>久佃䥄䝎琠歯湥眊楨档琠汥獬礠畯硳䫁档耀C摯湩慷獵摥琠敤潣敤琠敨戠硶䫁猠耀H᩵'. Make sure you typed the name correctly, and then try again. [OK] This makes me think buffer overrun or some codepage/encoding issues. After that I get an ordinary stacktrace: Requesting elevation and retrying... Failed to remove tempfile 'c:\users\me\appdata\local\temp\tmpx2_leopycomserverreg.out': [Error 2] The system cannot find the file specified: 'c:\\users\\me\\appdata\\local\\temp\\tmpx2_leopycomserverreg.out' Traceback (most recent call last): File "C:\Python31\lib\site-packages\win32com\server\register.py", line 566, in UseCommandLine RegisterClasses(*classes, **flags) File "C:\Python31\lib\site-packages\win32com\server\register.py", line 421, in RegisterClasses addPyComCat, dispatcherSpec, clsctx, addnPath) File "C:\Python31\lib\site-packages\win32com\server\register.py", line 187, in RegisterServer _set_string(keyNameRoot, desc) File "C:\Python31\lib\site-packages\win32com\server\register.py", line 32, in _set_string value) pywintypes.error: (5, 'RegSetValue', 'Access is denied.') During handling of the above exception, another exception occurred: Traceback (most recent call last): File "C:\Python31\Lib\site-packages\win32comext\axscript\client\pyscript.py", line 372, in <module> Register() File "C:\Python31\Lib\site-packages\win32comext\axscript\client\pyscript.py", line 368, in Register finalize_register=DllRegisterServer) File "C:\Python31\lib\site-packages\win32com\server\register.py", line 574, in UseCommandLine ReExecuteElevated(flags) File "C:\Python31\lib\site-packages\win32com\server\register.py", line 531, in ReExecuteElevated nShow=win32con.SW_SHOW) pywintypes.error: (2, 'ShellExecuteEx', 'The system cannot find the file specified.') Are there any simple temporary fixes for this? I'd love to get this up and running. :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2920507&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2009-12-21 10:12:52
|
Bugs item #2918564, was opened at 2009-12-21 10:12 Message generated for change (Tracker Item Submitted) made by rockthesmurf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2918564&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: Steven Craft (rockthesmurf) Assigned to: Nobody/Anonymous (nobody) Summary: DuplicateHandle to different process Initial Comment: I am not sure if this is necessarily a bug - it feels like it to me, but either way it would be helpful if the documentation at least mentioned it. If you call win32api.DuplicateHandle and specify the target process NOT to be the current process, the handle you get back will be ref counted etc. and when it goes out of scope CloseHandle will be called on it, but of course the handle in question is not owned by the current process, so causing CloseHandle on it is not the right thing to do, doing this will cause problems much later on (in my case, it doesn't complain when the handle is closed, but at some point later, when I call win32pipe.CreatePipe I get a bad handle back (and it has the same number as the handle that was incorrectly closed previously). The manual fix for this is easy, I just need to call Detach( ) on any handles that I duplicate in to other processes, but it took me a while to track this down etc. which is why I though it is worth logging a bug, so if nothing else it could be documented to save others having similar problems! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2918564&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2009-12-19 02:20:21
|
Bugs item #2908261, was opened at 2009-12-03 16:52 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2908261&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: com Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Sebastian Reichelt (sreichelt) Assigned to: Nobody/Anonymous (nobody) Summary: Access violation exception with wxPython via ActiveScript Initial Comment: Hello! After years of using PyWin32 successfully via ActiveScript, we (PTV AG) are now experiencing some crashes in certain situations. While trying to debug these, we found several access violation exceptions that seem to happen deep inside some Windows code after importing wxPython, creating a wx app object, and then closing the session. Although they don't actually lead to visible crashes - apparently they are caught somewhere - we suspect that they may be related to other crashes that we do see but for which we don't have any simple test case. One way to reliably reproduce the access violation is to open a standard "open file" dialog afterwards, as in the attached test case (compilable with VS 2005, but small enough to be easily portable, hopefully). It is probably easiest to tell the VS debugger to stop at all Windows exceptions. The access violation does not happen in our program if the dialog is opened before the script ends (i.e., while the script is waiting for some input), so we think it might be some cleanup code that destroys part of the host program's state. Of course, we have no idea whether PyWin32 or wxPython causes the problem, or whether PyWin32 is simply incompatible with wxPython (that's why I'm posting here first, just in case it's already known), or whether this access violation is really the cause for our crashes in other situations. But since it does indicate that something is broken, and we have no better guess at the moment, we are putting all of our hope into the idea that this can be fixed, and that the fix will also free us of the actual crashes. For the record, we have tried versions 212 and 214 of PyWin32, with Python 2.5 32-bit and 2.6 64-bit, different versions of wxPython including the latest, and both debug and release builds of our program. The symptoms are always the same, except that on 32-bit, the debugger does not show any meaningful call stack entries. If you have any idea how to debug this, that could help us already. In any case, thanks for making app scripting using Python possible in the first place! Best regards, Sebastian Reichelt ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2009-12-19 02: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: Vernon Cole (kf7xm) Date: 2009-12-16 15:18 Message: I have been experiencing some random crashes lately on an application which uses wxPython and does NOT use pywin32. (Actually, it does use win32timezone) I wonder if the problem may be in the wxPython code. I have been quite frustrated with this, but have not been able to delve as deeply into the problem as you have. -- Vernon Cole ---------------------------------------------------------------------- Comment By: Sebastian Reichelt (sreichelt) Date: 2009-12-07 10:37 Message: Well, the test case is a two-line script. Yes, technically it could be called a wx app. In fact, all scripts that use wx seem to cause this problem. But that's also one of the reasons why I would like to figure out if it's a pywin32 issue first. Did you get a chance to run the test case? In any case, thanks for your help so far. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2009-12-04 22:42 Message: It isn't clear to me how you are using pywin32 here - if it is a wx app which crashes, you are probably best off looking for help on the wx list ---------------------------------------------------------------------- Comment By: Sebastian Reichelt (sreichelt) Date: 2009-12-04 10:43 Message: I don't think I have any Python-implemented shell extensions installed, and looking at the DLLs that are loaded when the file dialog opens, I can't see anything related to Python. So I think the test case should hopefully work even on a clean Windows installation (oh - we are using Vista, btw - forgot that) with just Python, PyWin32, and wxPython. But: python26.dll, pythoncom26.dll, and pywintypes26.dll are never unloaded after the script exits. It's the same with an empty script, though. Does this already indicate a problem? Are we making a mistake in the way we use ActiveScript, maybe? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2009-12-03 21:45 Message: Do you have any Python implemented shell extensions (eg, Tortoise HG or Tortoise BZR?). I'd suggest you look in the debugger to try and work out if the file open dialog is causing another Python interpreter to be loaded into the process. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2908261&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2009-12-17 12:04:22
|
Bugs item #2916140, was opened at 2009-12-17 17:42 Message generated for change (Comment added) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2916140&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: Wont Fix Priority: 5 Private: No Submitted By: RaymondTay () Assigned to: Nobody/Anonymous (nobody) Summary: Interactive window does not return printf properly Initial Comment: In a nutshell, when i use PythonWin to run a simple function using ctypes on Windows Vista 64-bit (Python 2.5.4 is 32-bit) i wasn't seeing the expected output but when i ran the same function using the Windows command prompt it was alright re-pro steps: ---------------------- 1. Start PythonWin interactively (This is present after a successful installation of Python 2.5.4) 2. Key the following into the interactive window >>> from ctypes import * >>> cdll.msvcrt.printf(c_char_p('hello world')) expected results: -------------------------- the string 'hello world11' actual results: ---------------------- the string '11' (The 'hello world' appears to be gobbled) additional info: ----------------------- When i ran the same sequence as described in the re-pro using a normal Win32 command prompt and starting python interactively like that, i got what i expected. ---------------------------------------------------------------------- Comment By: RaymondTay () Date: 2009-12-17 20:04 Message: Thanks Mark for your comments, appreciate your response ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2009-12-17 19:26 Message: Thanks for the report - but there is very little I can do here - pythonwin overrides Python's sys.stdout etc, but overriding the C runtime concept of stdout/stderr is far harder and beyond what pythonwin tries to do. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2916140&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2009-12-17 11:26:55
|
Bugs item #2916140, was opened at 2009-12-17 20:42 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2916140&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: Wont Fix Priority: 5 Private: No Submitted By: RaymondTay () Assigned to: Nobody/Anonymous (nobody) Summary: Interactive window does not return printf properly Initial Comment: In a nutshell, when i use PythonWin to run a simple function using ctypes on Windows Vista 64-bit (Python 2.5.4 is 32-bit) i wasn't seeing the expected output but when i ran the same function using the Windows command prompt it was alright re-pro steps: ---------------------- 1. Start PythonWin interactively (This is present after a successful installation of Python 2.5.4) 2. Key the following into the interactive window >>> from ctypes import * >>> cdll.msvcrt.printf(c_char_p('hello world')) expected results: -------------------------- the string 'hello world11' actual results: ---------------------- the string '11' (The 'hello world' appears to be gobbled) additional info: ----------------------- When i ran the same sequence as described in the re-pro using a normal Win32 command prompt and starting python interactively like that, i got what i expected. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2009-12-17 22:26 Message: Thanks for the report - but there is very little I can do here - pythonwin overrides Python's sys.stdout etc, but overriding the C runtime concept of stdout/stderr is far harder and beyond what pythonwin tries to do. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2916140&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2009-12-17 09:42:39
|
Bugs item #2916140, was opened at 2009-12-17 17:42 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2916140&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: RaymondTay () Assigned to: Nobody/Anonymous (nobody) Summary: Interactive window does not return printf properly Initial Comment: In a nutshell, when i use PythonWin to run a simple function using ctypes on Windows Vista 64-bit (Python 2.5.4 is 32-bit) i wasn't seeing the expected output but when i ran the same function using the Windows command prompt it was alright re-pro steps: ---------------------- 1. Start PythonWin interactively (This is present after a successful installation of Python 2.5.4) 2. Key the following into the interactive window >>> from ctypes import * >>> cdll.msvcrt.printf(c_char_p('hello world')) expected results: -------------------------- the string 'hello world11' actual results: ---------------------- the string '11' (The 'hello world' appears to be gobbled) additional info: ----------------------- When i ran the same sequence as described in the re-pro using a normal Win32 command prompt and starting python interactively like that, i got what i expected. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2916140&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2009-12-16 18:31:34
|
Bugs item #2571020, was opened at 2009-02-05 20:25 Message generated for change (Comment added) made by kf7xm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2571020&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: win32 Group: None >Status: Closed >Resolution: Fixed Priority: 2 Private: No Submitted By: George Hebert (g_hebert) Assigned to: Vernon Cole (kf7xm) Summary: ADODBAPI - py2exe bug Initial Comment: If a Python application uses adodbapi and is compiled into an exe using Py2exe, that app will fail on importing as soon as it is executed because of the following line: version = __doc__.split('-',2)[0] #v2.1 Cole It appears as though __doc__ is None if being used within a compiled python app (exe). This could be fixed if the version was simply set to a string... ex: version = 'adodbapi 2.x.x'. There may be other ways of fixing this but I believe this would be the easiest. ---------------------------------------------------------------------- >Comment By: Vernon Cole (kf7xm) Date: 2009-12-16 11:31 Message: Will be fixed in adodbapi v 2.3. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2571020&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2009-12-16 15:18:31
|
Bugs item #2908261, was opened at 2009-12-03 09:52 Message generated for change (Comment added) made by kf7xm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2908261&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: Pending Resolution: None Priority: 5 Private: No Submitted By: Sebastian Reichelt (sreichelt) Assigned to: Nobody/Anonymous (nobody) Summary: Access violation exception with wxPython via ActiveScript Initial Comment: Hello! After years of using PyWin32 successfully via ActiveScript, we (PTV AG) are now experiencing some crashes in certain situations. While trying to debug these, we found several access violation exceptions that seem to happen deep inside some Windows code after importing wxPython, creating a wx app object, and then closing the session. Although they don't actually lead to visible crashes - apparently they are caught somewhere - we suspect that they may be related to other crashes that we do see but for which we don't have any simple test case. One way to reliably reproduce the access violation is to open a standard "open file" dialog afterwards, as in the attached test case (compilable with VS 2005, but small enough to be easily portable, hopefully). It is probably easiest to tell the VS debugger to stop at all Windows exceptions. The access violation does not happen in our program if the dialog is opened before the script ends (i.e., while the script is waiting for some input), so we think it might be some cleanup code that destroys part of the host program's state. Of course, we have no idea whether PyWin32 or wxPython causes the problem, or whether PyWin32 is simply incompatible with wxPython (that's why I'm posting here first, just in case it's already known), or whether this access violation is really the cause for our crashes in other situations. But since it does indicate that something is broken, and we have no better guess at the moment, we are putting all of our hope into the idea that this can be fixed, and that the fix will also free us of the actual crashes. For the record, we have tried versions 212 and 214 of PyWin32, with Python 2.5 32-bit and 2.6 64-bit, different versions of wxPython including the latest, and both debug and release builds of our program. The symptoms are always the same, except that on 32-bit, the debugger does not show any meaningful call stack entries. If you have any idea how to debug this, that could help us already. In any case, thanks for making app scripting using Python possible in the first place! Best regards, Sebastian Reichelt ---------------------------------------------------------------------- >Comment By: Vernon Cole (kf7xm) Date: 2009-12-16 08:18 Message: I have been experiencing some random crashes lately on an application which uses wxPython and does NOT use pywin32. (Actually, it does use win32timezone) I wonder if the problem may be in the wxPython code. I have been quite frustrated with this, but have not been able to delve as deeply into the problem as you have. -- Vernon Cole ---------------------------------------------------------------------- Comment By: Sebastian Reichelt (sreichelt) Date: 2009-12-07 03:37 Message: Well, the test case is a two-line script. Yes, technically it could be called a wx app. In fact, all scripts that use wx seem to cause this problem. But that's also one of the reasons why I would like to figure out if it's a pywin32 issue first. Did you get a chance to run the test case? In any case, thanks for your help so far. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2009-12-04 15:42 Message: It isn't clear to me how you are using pywin32 here - if it is a wx app which crashes, you are probably best off looking for help on the wx list ---------------------------------------------------------------------- Comment By: Sebastian Reichelt (sreichelt) Date: 2009-12-04 03:43 Message: I don't think I have any Python-implemented shell extensions installed, and looking at the DLLs that are loaded when the file dialog opens, I can't see anything related to Python. So I think the test case should hopefully work even on a clean Windows installation (oh - we are using Vista, btw - forgot that) with just Python, PyWin32, and wxPython. But: python26.dll, pythoncom26.dll, and pywintypes26.dll are never unloaded after the script exits. It's the same with an empty script, though. Does this already indicate a problem? Are we making a mistake in the way we use ActiveScript, maybe? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2009-12-03 14:45 Message: Do you have any Python implemented shell extensions (eg, Tortoise HG or Tortoise BZR?). I'd suggest you look in the debugger to try and work out if the file open dialog is causing another Python interpreter to be loaded into the process. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2908261&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2009-12-16 02:20:44
|
Bugs item #2906625, was opened at 2009-12-01 08:57 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2906625&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: jpiron (jpiron) Assigned to: Nobody/Anonymous (nobody) Summary: Windows service with logging to FILES module Initial Comment: Dears, I'm sorry to reopen this bug, but the former was closed abruptly... The last paragraph is about the log-to-files-that-fails part. When I try to use the logging module in a script that is called by a general script intended to create a windows service that runs the script in a separated thread, I get an IOError: Bad file descriptor For exemple, I have a script that polls a value and logs it every second. It runs flawlessly alone and in debug mode in a service. But once it is started normally. the log process is successfull several times (8 for exemple, and always 8) and the next time, the IOError is raised. I ave tried with several handlers: RotatingFileHandler, FileHandler, and even StreamHandler, with different polling times, different numberd of successive writes and some other parameters. ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2009-12-16 02: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: 2009-12-01 10:51 Message: I closed the bug after indicating the problem. Note that stdio buffering is what causes the problem to fail after what appears to be 8 log calls (but in reality, it fails after a fixed number of bytes are written). Unless you can show this is a problem with pywin32's service support, I'll be forced to close this bug eventually too... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2906625&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2009-12-13 10:04:11
|
Bugs item #2831327, was opened at 2009-08-03 09:22 Message generated for change (Comment added) made by pchambon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2831327&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: lplatypus (ldeller) Assigned to: Nobody/Anonymous (nobody) Summary: GetProcessTimes converts wrongly to PyTime Initial Comment: win32process.GetProcessTimes returns PyTime objects which are off by time.timezone seconds. It appears that Windows returns a UTC time, but this is interpreted as if it were a local time. See attached example which demonstrates the bug. A similar problem probably exists with the win32process.GetThreadTimes function. ---------------------------------------------------------------------- Comment By: Pascal Chambon (pchambon) Date: 2009-12-13 11:04 Message: I've had a hard time with that bug too :p The problem is that indeed the current pywin32 implementation uses FileTimeToSystemTime to get an UTC datetime, but then when converting to unix timestamp it uses mktime which expects localtime and automatically guesses the timzone/daylightsaving, so we get wrong values. Couldn't we just remove the #undef which prevents using python datetime api before py3k ? Or replace FileTimeToSystemTime by FileTimeToLocalTime and only work with local pytimes, by adding (SystemTimeToTzSpecificLocalTime(NULL, &st, <)) after FileTimeToSystemTime(&t, &st); ? ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2009-08-06 03:05 Message: Good catch - I should therefore nuke that function supporting a SYSTEMTIME seeing we have managed without *really* needing one so far... ---------------------------------------------------------------------- Comment By: lplatypus (ldeller) Date: 2009-08-06 02:40 Message: That sounds good to me. I see that the code for the py3k builds assumes that SYSTEMTIME always contains UTC, which contradicts the MSDN documentation for SYSTEMTIME [ http://msdn.microsoft.com/en-us/library/ms724950%28VS.85%29.aspx ]. Maybe this is not so bad: the only example I can find where SYSTEMTIME contains a local time is the return value of GetLocalTime(), and pywin's wrapper for this function return a tuple thus sidestepping the problem. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2009-08-04 05:06 Message: Note the py3k builds use a datetime objects; I think a better solution is to allow these objects to also be used in py2k and let the PyTime object die a graceful death... ---------------------------------------------------------------------- Comment By: lplatypus (ldeller) Date: 2009-08-04 03:15 Message: Following through the C++ code, I see that the type conversion sequence is: FILETIME -> SYSTEMTIME -> DATE -> struct tm -> time_t Now with MSDN documentation handy I see that: - FILETIME is always UTC - SYSTEMTIME can be either UTC or the system's local time depending on the function being called - DATE documentation does not mention timezones at all - struct tm can contain UTC or the system's local time - time_t is always UTC In the present example, we have a UTC time all the way through to struct tm, but then it is converted to time_t using the mktime() function which expects the struct tm to be in local time. This occurs in PyTime::asLong() in PyTime.cpp How to fix this? I think that the PyTime object needs to be extended to know whether it contains UTC or local time. When constructed from a FILETIME value it needs to be marked as containing UTC. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2831327&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2009-12-11 03:10:36
|
Bugs item #2905909, was opened at 2009-11-30 22:10 Message generated for change (Comment added) made by stevemccusker You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2905909&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pythonwin Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: assert sys.modules[modname] is old_mod error in pywintypes Initial Comment: When running Apache+Mod Python (Python 2.4), I was getting this error - [Mon Nov 30 15:13:50 2009] [error] [client 127.0.0.1] Traceback (most recent call last): [Mon Nov 30 15:13:50 2009] [error] [client 127.0.0.1] File "C:\\Python24\\Lib\\site-packages\\mod_python\\importer.py", line 1537, in HandlerDispatch\n default=default_handler, arg=req, silent=hlist.silent) [Mon Nov 30 15:13:50 2009] [error] [client 127.0.0.1] File "C:\\Python24\\Lib\\site-packages\\mod_python\\importer.py", line 1229, in _process_target\n result = _execute_target(config, req, object, arg) [Mon Nov 30 15:13:50 2009] [error] [client 127.0.0.1] File "C:\\Python24\\Lib\\site-packages\\mod_python\\importer.py", line 1128, in _execute_target\n result = object(arg) [Mon Nov 30 15:13:50 2009] [error] [client 127.0.0.1] File "c:\\python24\\Lib\\site-packages\\django\\core\\handlers\\modpython.py", line 228, in handler\n return ModPythonHandler()(req) [Mon Nov 30 15:13:50 2009] [error] [client 127.0.0.1] File "c:\\python24\\Lib\\site-packages\\django\\core\\handlers\\modpython.py", line 201, in __call__\n response = self.get_response(request) [Mon Nov 30 15:13:50 2009] [error] [client 127.0.0.1] File "c:\\python24\\Lib\\site-packages\\django\\core\\handlers\\base.py", line 73, in get_response\n response = middleware_method(request) [Mon Nov 30 15:13:50 2009] [error] [client 127.0.0.1] File "c:\\python24\\Lib\\site-packages\\django\\contrib\\sessions\\middleware.py", line 10, in process_request\n engine = import_module(settings.SESSION_ENGINE) [Mon Nov 30 15:13:50 2009] [error] [client 127.0.0.1] File "c:\\python24\\Lib\\site-packages\\django\\utils\\importlib.py", line 35, in import_module\n __import__(name) [Mon Nov 30 15:13:50 2009] [error] [client 127.0.0.1] File "c:\\python24\\Lib\\site-packages\\django\\contrib\\sessions\\backends\\db.py", line 2, in ?\n from django.contrib.sessions.models import Session [Mon Nov 30 15:13:50 2009] [error] [client 127.0.0.1] File "c:\\python24\\Lib\\site-packages\\django\\contrib\\sessions\\models.py", line 4, in ?\n from django.db import models [Mon Nov 30 15:13:50 2009] [error] [client 127.0.0.1] File "c:\\python24\\Lib\\site-packages\\django\\db\\models\\__init__.py", line 12, in ?\n from django.db.models.fields.files import FileField, ImageField [Mon Nov 30 15:13:50 2009] [error] [client 127.0.0.1] File "c:\\python24\\Lib\\site-packages\\django\\db\\models\\fields\\files.py", line 8, in ?\n from django.core.files.storage import default_storage [Mon Nov 30 15:13:50 2009] [error] [client 127.0.0.1] File "c:\\python24\\Lib\\site-packages\\django\\core\\files\\storage.py", line 7, in ?\n from django.core.files import locks, File [Mon Nov 30 15:13:50 2009] [error] [client 127.0.0.1] File "c:\\python24\\Lib\\site-packages\\django\\core\\files\\locks.py", line 25, in ?\n import pywintypes [Mon Nov 30 15:13:50 2009] [error] [client 127.0.0.1] File "C:\\Python24\\Lib\\site-packages\\win32\\lib\\pywintypes.py", line 124, in ?\n __import_pywin32_system_module__("pywintypes", globals()) [Mon Nov 30 15:13:50 2009] [error] [client 127.0.0.1] File "C:\\Python24\\Lib\\site-packages\\win32\\lib\\pywintypes.py", line 114, in __import_pywin32_system_module__\n assert sys.modules[modname] is old_mod [Mon Nov 30 15:13:50 2009] [error] [client 127.0.0.1] AssertionError With PythonDebug = On, assert took effect. I removed it and it worked without any issues. I found that another user - <a href="http://markmail.org/message/hqnf6obaillzspxj#query:assert%20sys.modules[modname]%20is%20old_mod+page:1+mid:nahkqunchycwqtd4+state:results">here</a> also has the same issue. He solved it by going back a version. ---------------------------------------------------------------------- Comment By: Steve McCusker (stevemccusker) Date: 2009-12-11 14:10 Message: I have just come across this problem. I am using Apache 2.2, Django 1.1, Python 2.6.2 and mod_wsgi (mod_wsgi-win32-ap22py26-2.5.so) on Win XP Pro (SP3). It allworked fine until PayPal POSTed a notification. This was , of course, from a different IP address from the previous GETs and POSTs. It caused the above error. After I read this bug report I simple commented out the two Assert statements and it then seemed to work OK. I did do a debug dump from pywintypes just before the assert statements just using the python unicode() function on the two modules (old_mod and mod) and they looked the same from that. Changing back to the older version as reported above did not help. Cheers Steve McCusker ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2009-12-01 10:25 Message: My concern is that assertion may be indicating pywintypesxx.dll has been loaded twice by the process, causing subtle problems with the types. It would be interesting to know what the __file__ attribute is on the 2 objects. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2905909&group_id=78018 |
2 messages has been excluded from this view by a project administrator.
