pywin32-bugs Mailing List for Python for Windows Extensions (Page 96)
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...> - 2004-10-09 06:25:56
|
Bugs item #770248, was opened at 2003-07-13 05:03 Message generated for change (Settings changed) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=770248&group_id=78018 >Category: pythonwin Group: None Status: Open Resolution: None Priority: 5 Submitted By: bob gailer (ramrom) Assigned to: Nobody/Anonymous (nobody) Summary: F9 sets breakpoint in wrong pane Initial Comment: With pane divider about 2/3 way down, cursor in top pane, I hit F9 and a breakpoint is set in the first line of the bottom pane. Top pane is showing lines 157-196; bottom 75-89. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=770248&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-10-09 06:25:54
|
Bugs item #1027556, was opened at 2004-09-14 08:03 Message generated for change (Settings changed) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1027556&group_id=78018 >Category: pythonwin Group: None Status: Open Resolution: None Priority: 5 Submitted By: bob gailer (ramrom) Assigned to: Nobody/Anonymous (nobody) Summary: Double-Clicking item in left pane should scroll active edit Initial Comment: When edit window is split horizontally, double-clicking an item in the left (hierarchy) pane should scroll the active edit pane to the selected item. Instead it always scrolls the lower pane. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1027556&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-10-09 06:25:54
|
Bugs item #973771, was opened at 2004-06-16 18:22 Message generated for change (Settings changed) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=973771&group_id=78018 >Category: pythonwin Group: None Status: Open Resolution: None Priority: 7 Submitted By: Robert Kiendl (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: Grep File Search Tool:doesn't open file anymore Initial Comment: Grep File Search Tool: Double-Click / [RETURN] key doesn't open file anymore. #Search C:\devel\e2x # Files *.py # For thread.start c:\test\test.py(558) thread.start_new(x,()) in earlier versions the file opened. ---------------------------------------------------------------------- Comment By: bob gailer (ramrom) Date: 2004-10-02 04:05 Message: Logged In: YES user_id=587593 See bug 716741. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=973771&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-10-09 06:25:54
|
Bugs item #1013126, was opened at 2004-08-21 06:54 Message generated for change (Settings changed) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1013126&group_id=78018 >Category: pythonwin Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jon McLin (jon_mclin) Assigned to: Nobody/Anonymous (nobody) Summary: PythonWin not installed in context menu. Initial Comment: In earlier builds (142 to 163, at least), PythonWin was installed to the Explorer context menu so I could right-click and "Open with PythonWin". I used this a lot! Where did it go in 202? ---------------------------------------------------------------------- Comment By: Andrew Payn Barnert (payn) Date: 2004-09-09 08:13 Message: Logged In: YES user_id=96775 See bug 990048. I'm willing to bet the installer got an error in the postinstall script, so it skipped all later steps (including the Explorer integration stuff) but still reported success overall. ---------------------------------------------------------------------- Comment By: Jon McLin (jon_mclin) Date: 2004-08-21 06:56 Message: Logged In: YES user_id=1071288 PS - platform is Win XP Pro. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1013126&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-10-09 06:25:54
|
Bugs item #1027853, was opened at 2004-09-14 21:57 Message generated for change (Settings changed) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1027853&group_id=78018 >Category: pythonwin Group: None Status: Open Resolution: None Priority: 5 Submitted By: bob gailer (ramrom) Assigned to: Nobody/Anonymous (nobody) Summary: selected traceback text won't copy Initial Comment: Select traceback text in interactive window & do edit->copy. Clipboard does not change. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1027853&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-10-09 06:16:54
|
Bugs item #968208, was opened at 2004-06-08 00:52 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=968208&group_id=78018 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Geisinger (geisinger) Assigned to: Nobody/Anonymous (nobody) Summary: missing files PyIProvideTaskPage.h/.cpp (pywin32-201.zip) Initial Comment: D:\Src\pywin32-201>setup_win32all.py build --debug running build running build_py running build_ext Found WINDOWS.H version 0x501 in C:\Program Files\Microsoft SDK\Include building 'taskscheduler' extension C:\Program Files\Microsoft Visual Studio\VC98\BIN\cl.exe /c /nologo /Od /MDd /W3 /GX /Z7 /D_DEBUG -DDISTUTILS_BUILD -Ico m/win32com/src/include -Iwin32/src -IC:\Python23\include -IC:\Python23\PC /TpD:\Src\pywin32-201\com\win32comext\tasksche duler\src\taskscheduler.cpp /Fobuild\temp.win32-2.3\Debug\com\win32comext\taskscheduler\src\taskscheduler.obj taskscheduler.cpp D:\Src\pywin32-201\com\win32comext\taskscheduler\src\taskscheduler.cpp(8) : fatal error C1083: Cannot open include file: 'PyIProvideTaskPage.h': No such file or directory error: command '"C:\Program Files\Microsoft Visual Studio\VC98\BIN\cl.exe"' failed with exit status 2 ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-10-09 16:16 Message: Logged In: YES user_id=14198 This should be fixed in the new 203 build - I actually tested I could build from the sdist archive this time :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=968208&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-10-09 06:13:17
|
Bugs item #788285, was opened at 2003-08-14 05:46 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=788285&group_id=78018 Category: win32 Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: José Rui Faustino de Sousa (jrfsousa) Assigned to: Nobody/Anonymous (nobody) Summary: win32all 154 & 156 install fails on ActivePython Initial Comment: Hi! The installation goes well until almost the end when it crashes complaining that it can not find: ? PyWinObject_FromSECURITY_DESCRIPTOR@@YAPAU_obj ect@@PAU_SECURITY_DESCRIPTOR@@I@Z function on PyWinTypes22.dll An it is right... the function is not in the dll the nearest I could find where: ? PyWinObject_FromSECURITY_ATTRIBUTES@@YAPAU_obj ect@@ABU_SECURITY_ATTRIBUTES@@@Z and ? PyWinObject_FromSECURITY_DESCRIPTOR@@YAPAU_obj ect@@PAX@Z Only win32all 152 install OK. Hope I have been of assistance. Best regards José Rui ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-10-09 16:13 Message: Logged In: YES user_id=14198 Sorry for the delay - this has been resolved in the most recent builds. ---------------------------------------------------------------------- Comment By: José Rui Faustino de Sousa (jrfsousa) Date: 2003-08-16 01:57 Message: Logged In: YES user_id=839349 It seems to be possible to uninstall only the win32 part of ActivePython. I did that and then installed win32all 156 with no problems. But when I first run pythonwin ActivePython automagicly reinstalled the old win32all extensions. Maybe there is some workaround but I decided to take your advice uninstalled ActivePython and did a standard Python install. Thank you very much. Best regards José Rui ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2003-08-15 15:22 Message: Logged In: YES user_id=771074 This is the same issue as [ 772804 ]. You'll probably need to do an uninstall first. I don't know if you can uninstall just the win32all portion of ActivePython, if not your best bet would be to do a standard Python install followed by win32all. Roger ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=788285&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-10-09 06:12:12
|
Bugs item #774215, was opened at 2003-07-20 00:40 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=774215&group_id=78018 Category: pythonwin Group: None Status: Open Resolution: None Priority: 5 Submitted By: Art Du Rea (durea) Assigned to: Nobody/Anonymous (nobody) Summary: Can't install on non-std Python installation Initial Comment: ( I also submitted this in the Support section) Esteemed Python People and Lurkers: I would really like to install the Win extensions to Python ... I just started using Python and I LOVE it! I've never seen Python before in my life, and with the PeachPit Press Python Visual Quick Start book, I got a simple HTML Automatic Table generator up and running in a total of about 4 hours! The problem is I can NOT install the Win extensions! My Python is installed in: "F:\Applications\Python" and the Win extension installer (win32all-153.exe) just can't find it. I click the "Continue anyway" button on the popup, but it just jumps back to the same popup and will NOT continue no matter what I do. How can I get the extensions installed on my Non-Standard Python installation? Thank you for your gracious and patient assistance with this issue. Art Du Rea Carlisle, PA USA NoSpam e-mail: imadeptNOGI@NOGOpa-net Remove the caps letters (NO Garbage In : NO Garbage Out) ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-10-09 16:12 Message: Logged In: YES user_id=14198 You can set an "InstallPath" key in the Python part of your registry as a work-around. ---------------------------------------------------------------------- Comment By: Art Du Rea (durea) Date: 2003-07-30 09:31 Message: Logged In: YES user_id=826097 I hope box is where I'm supposed to comment ... it sure would be nice just to have a "REPLY" button ... Anyway, I found another site with a message from a Python user with my exact problem ... There ought to be a big flaming warning to NOT upload the latest version of wxPython ... it is for the BETA Python 2.3! There is virtually no distinction between the boxes to download the win32 for Python 2.2.3 and 2.3, and it is totally trivial to get confused and download the wrong one, which I did! (And I'm obviously not the only one!) I tried to get back to this message thread, but SourceForge is not very friendly IM-notso-HO. I did get wxPython "working" so to speak. I've tried to run all 8 of the sample programs ... at least a couple of them don't run at all or else crash the system. At least a couple of others run, but if I play "musical windows" (make different resident windows active) with WinExplorer or whatever, the system hangs. All I wanted was a couple of quick and easy interface popups, but that is not what wx is. If you want, I'll give you more quantitative data on this ... send a direct e-mail to my_...@NO... ... remove the cap letters. I do LOVE Python and am using it for text file filtering and HTML table generation (120 or so linked entries). I just wish that I had a couple of simple, reliable add-on popups for user interface to go with vanilla Python. Before I would use it heavily, though, I would need to be able to generate execuatbles. This has been a terribly negative letter, but I want to thank you most sincerely for your efforts and your tremendous achievements. I hope you have enjoyed yourself and I look forward to hearing from you! Blessings in abundance, all the best, and ENJOY! Art Du Rea NO Garbage In - NO Garbage Out PC P-II 350 w/192 Meg Win98 SE ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2003-07-29 17:04 Message: Logged In: YES user_id=14198 Please try the latest win32all versions (156/7) - they should work in that case. Please let us know either way. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=774215&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-10-09 06:11:22
|
Bugs item #772804, was opened at 2003-07-17 15:21 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=772804&group_id=78018 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: John Lim (johnlim) Assigned to: Nobody/Anonymous (nobody) Summary: Failed Installation: Entry Point Not Found Initial Comment: Towards the end of the installer, I get this error message: ------- Python Win32 extensions Installation: win32all-154.exe - Entry Point Not Found The procedure entry point ? PyWinObject_FromSECURITY_DESCRIPTOR@@YAPAU_obj ect@@PAU_SECURITY_DESCRIPTOR@@I@Z could not be located in the dynamic link library PyWinTypes22.dll. Error in installer script. Traceback (most recent call last): File "e:\TEMP\FinishInstall.py", line 101, in ApplyEntryPoint apply(ep, args) File "e:\TEMP\FinishInstall.py", line 82, in DoCompileAllAndRegisterCOM FindDuplicates(mod, dir) File "e:\TEMP\FinishInstall.py", line 143, in FindDuplicates import win32api ImportError: DLL load failed: The specified procedure could not be found. ------- If it helps, FYI I tried using the ActivePython 2.2.2 build 224 (unsuccessfully) before attempting to install PyWin32 manually. http://bugs.activestate.com/ActivePython/show_bug. cgi?id=26267 ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-10-09 16:11 Message: Logged In: YES user_id=14198 Is this still an issue? I suspect that a "Modules" subkey in the Python part of the registry may be causing this. Build 202 of the pywin32 extensions may also solve it (it tries to!) Please reopen if you still have problems. ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2003-08-02 11:27 Message: Logged In: YES user_id=771074 The argument types for PyWinObject_FromSECURITY_DESCRIPTOR have changed. Most likely you have an old version of PyWinTypes or win32api hanging around. Try doing a complete uninstall of the win32 extensions first, making sure both of these files are gone. Roger ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2003-07-29 05:32 Message: Logged In: YES user_id=113328 Seems to be fixed in win32all-157 ---------------------------------------------------------------------- Comment By: Paul Moore (pmoore) Date: 2003-07-22 07:33 Message: Logged In: YES user_id=113328 I get this too, with Python 2.3c1 and win32all-155. I'm using Windows 2000 Pro, SP4. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=772804&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-10-09 06:07:36
|
Bugs item #849191, was opened at 2003-11-26 06:24 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=849191&group_id=78018 Category: pythonwin Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Waldemar Osuch (osuchw) Assigned to: Nobody/Anonymous (nobody) Summary: SaveBarState called too many times Initial Comment: I have noticed that after a debuggin session in Pythonwin my HKEY_CURRENT_USER\Software\Python 2.3\Python for Win32 registry key can grow very large. It seems that the way I work: - step trough the code in debuger. - find and fix an error. - stop debugger. - repeat. provokes uncontrollable frenzy of writing to registry the state of toolbars. On a few occasions I ended up with over a thousand 'ToolbarDebugging-Bar%s' %i entries i beeing as high as 1500. If not stopped Pythonwin gives <Could not load toolbar state> message and continue to work but very slowly. My workaround is: - delete the offending registry key - start Pythonwin - set the preferences to my liking. - start debugging sessions. Set prefrences again. - close Pythonwin. - comment out line 462 in Pythonwin\pywin\debugger.py I have observed the same behaviour for versions of Pythonwin going back as far v.154 on Windows2000 and Win98 ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-10-09 16:07 Message: Logged In: YES user_id=14198 *sigh*, yep, and I can't find a solution other than to comment out that line. So it has been. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=849191&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-10-09 06:06:10
|
Bugs item #959162, was opened at 2004-05-24 10:01 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=959162&group_id=78018 Category: pythonwin Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: john wolter (johnswolter) Assigned to: Nobody/Anonymous (nobody) Summary: Win98 SE pythonwin run failure Initial Comment: I installed the 2.3.4rc1 then your 201 build and found an error when I started pywin. The target system is a Win98 SE /w 64 RAM 4 GigaHD, nothing special etc. I've run 2.3.3 and wiin32all previously and all was ok. Let me know if there is anything I can do to correct this. Thanks for your package it has made a real difference. Startup runtime ERROR for pythonwin: File "C:\PYTHON23\Lib\site-packages\pythonwin\pywin\framework\intpyapp.py", line 163, in InitInstance import interact File "C:\PYTHON23\Lib\site-packages\pythonwin\pywin\framework\interact.py", line 26, in ? import winout File "C:\PYTHON23\Lib\site-packages\pythonwin\pywin\framework\winout.py", line 26, in ? from pywintypes import UnicodeType File "C:\PYTHON23\Lib\site-packages\win32\lib\pywintypes.py", line 69, in ? __import_pywin32_system_module__("pywintypes", globals()) File "C:\PYTHON23\Lib\site-packages\win32\lib\pywintypes.py", line 62, in __import_pywin32_system_module__ raise ImportError, "Can not locate " + filename exceptions.ImportError: Can not locate pywintypes23.dll ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-10-09 16:05 Message: Logged In: YES user_id=14198 I think build 202 fixed this. Build 203 (due very soon) should have fixed it even better :) Please reopen if you still have problems. ---------------------------------------------------------------------- Comment By: George Tegos (gtegos) Date: 2004-05-31 23:14 Message: Logged In: YES user_id=464497 We had the same symptoms on WinME and we discovered that the pywintypes dll was on the system directory, only it had 8.3 file name. We renamed the file to pywintypes23.dll (also the pythoncom23.dll) and everything went OK. ---------------------------------------------------------------------- Comment By: HAVOK (havok) Date: 2004-05-27 03:48 Message: Logged In: YES user_id=12566 this is a dupe of bug 917702 Solution: 1. Add C:\WINDOWS\SYSTEM to your PATH (c:\autoexec.bat) OR 2. Move pywintypes23.dll and that other dll (py*.dll) to C:\windows OR 3. Move those files to C:\Python23 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=959162&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-10-09 06:04:51
|
Bugs item #801291, was opened at 2003-09-06 04:39 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=801291&group_id=78018 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason R. Coombs (jaraco) Assigned to: Nobody/Anonymous (nobody) Summary: problem with ADO.CommandeExecute() options Initial Comment: I posted this originally on comp.python. I'm reposting it here since it seems a more appropriate place. I'm hoping this is a coding error on my part, but I've encountered a problem with parameters that I cannot understand. Perhaps someone out there might be willing to assist me with some suggestions. First, here is some VB code that correctly does what I want to do: --------------------------- begin cmdtest.vbs Dim cn Dim rs Dim cmd Set cn = CreateObject( "ADODB.Connection" ) cn.Open( "Provider=SQLOLEDB;Data Source= (local);Initial Catalog=Environmental Monitoring;Integrated Security=SSPI" ) Set rs = CreateObject( "ADODB.Stream" ) rs.Open() Set cmd = CreateObject( "ADODB.Command" ) cmd.ActiveConnection = cn cmd.Properties("Output Stream").Value = rs cmd.CommandText = "SELECT * FROM [Sources] for XML AUTO" cmd.Execute , , 1024 'adExecuteStream rs.Position = 0 WScript.Echo rs.ReadText() --------------------------- end cmdtest.vbs Here is partial output I get: C:\>cscript cmdtest.vbs Microsoft (R) Windows Script Host Version 5.6 Copyright (C) Microsoft Corporation 1996-2001. All rights reserved. <Sources ID="1" Name="South Asia" Type="7"/><Sources ID="2" Name="Japan" Type="2"/>... Now, if I attempt to do the same thing in python, it returns no output. ------------------------- begin cmdtest.py import ADO, sys cn = ADO.Connection() cn.Open( "Provider=SQLOLEDB;Data Source= (local);Initial Catalog=Environmental Monitoring;Integrated Security=SSPI" ) rs = ADO.Stream() rs.Open() cmd = ADO.Command() cmd.ActiveConnection = cn cmd.Properties("Output Stream").Value = rs cmd.CommandText = "SELECT * FROM [Sources] for XML AUTO" cmd.Execute( Options = ADO.constants.adExecuteStream ) rs.Position = 0 sys.stdout.write( rs.ReadText() ) # prints nothing ------------------------- end cmdtest.py If I pass no parameters to cmd.Execute in the VBScript verison, I get no output. Other tests have further led me to conclude that the constant value 1024 is not being properly passed to ADO.Command.Execute in the Python version only. Here are some other points of information: - Using the literal 1024 in the Python code instead of the constant reference make no difference. - The VBScript code does not recognize adExecuteStream by name. - Using win32com.client.Dispatch( 'ADODB.*' ) to create the objects (instead of ADO.py created from make PY) yields the same results. - Using a different PROVIDER in the connection (such as SQLXMLOLEDB) will yield different results, but still indicates that the 'adExecuteStream' is not being set properly. - I'm using "Microsoft ActiveX Data Objects 2.8 Library" for the ADO. I've tried using v2.5 and 2.7, but get identical results. - The first parameter to ADO.Command.Execute appears to be an [out] parameter, but the documentation is confusing and I haven't seen the first parameter used anywhere. Any insight into this problem would be most appreciated. Regards, Jason R. Coombs Sandia National Laboratories ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-10-09 16:04 Message: Logged In: YES user_id=14198 Interesting... The problem will be the way we present these optional params. It may even be that '[ 985980 ] pywin32 custom i/f COM servers do not support var args' has some insights ---------------------------------------------------------------------- Comment By: Jason R. Coombs (jaraco) Date: 2003-09-09 07:47 Message: Logged In: YES user_id=599869 Thanks for the comment, but it doesn't address my issue. I apologize for being unclear. The reason I am passing an ADO.Stream (Prog ID ADODB.Stream) object as the "Output Stream" property of the command is because this is the only way AFAIK to retrieve the results of a "SELECT ... FOR XML" query in SQL Server via ADO. I can use the rs = cmd.Execute(...) syntax to receive the results of a standard query returning a recordset (where rs is a two-tuple containing the recordset and the result status). Upon further investigation, I found that the RecordsAffected (first parameter to cmd.Execute) is involved in the ADO not behaving as expected. By sheer luck, I was able to get the Python code to work by passing something (and as it turns out anything) as the RecordsAffected Parameter. Leaving all other code the same, but replacing the execute line with the following yields the same results as the VB code. cmd.Execute( 1, Options = ADO.constants.adExecuteStream ) Furthermore, passing any value as RecordsAffected or even passing it as a keyword argument seems to alleviate the problem. cmd.Execute( RecordsAffected = None, Options = ADO.constants.adExecuteStream ) cmd.Execute( 'jelly beans', Options = ADO.constants.adExecuteStream ) all work just as well as the control code (VB). The VB code works fine with all such parameters except for a string value (such as "jelly beans"). I hope this sheds some more light on the issue I'm experiencing with passing parameters to the ADO.Command.Execute method. Fortunately, I've found a workaround now, but it would be nice to track down the core of the problem. Any ideas? ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2003-09-06 08:40 Message: Logged In: YES user_id=771074 Output parameters are returned as results of the method call, so you would do rs=cmd.Execute(....). hth Roger ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=801291&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-10-09 06:01:51
|
Bugs item #965610, was opened at 2004-06-03 19:17 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=965610&group_id=78018 Category: pythonwin Group: None >Status: Pending Resolution: None Priority: 5 Submitted By: Robert Kiendl (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: docview.py & COM draw Framework into the machine Initial Comment: docview.py draws the framework into the machine (e.g. py2exe creates output +1MB in size). Software uses unnecessary lots of memory. and: now win32com/server/dispatcher.py also draws the framework/debugger ! i patched it like this ( but not very elegant because i don't overview the framework module design well; but only 2 locations changing ) # docview.py self.MakeView=MakeView self._SetupSharedMenu_() def _SetupSharedMenu_(self): pass #to be replaced by framework! ### todo - _SetupSharedMenu_ should be moved to a framework class. ## def _SetupSharedMenu_(self): ## sharedMenu = self.GetSharedMenu() ## from pywin.framework import toolmenu ## toolmenu.SetToolsMenu(sharedMenu) ## from pywin.framework import help ## help.SetHelpMenuOtherHelp(sharedMenu) def _CreateDocTemplate(self, resourceId): return win32ui.CreateDocTemplate(resourceId) def __del__(self): # intpyapp.py import dbgcommands lastLocateFileName = ".py" # used in the "File/Locate" dialog... # todo - _SetupSharedMenu should be moved to a framework class. def _SetupSharedMenu_(self): sharedMenu = self.GetSharedMenu() from pywin.framework import toolmenu toolmenu.SetToolsMenu(sharedMenu) from pywin.framework import help help.SetHelpMenuOtherHelp(sharedMenu) from pywin.mfc import docview docview.DocTemplate._SetupSharedMenu_=_SetupSharedMenu_ class MainFrame(app.MainFrame): def OnCreate(self, createStruct): self.closing = 0 # dispatcher.py def __init__(self, policyClass, ob): exec "import pywin.debugger" pywin.debugger.brk() ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-10-09 16:01 Message: Logged In: YES user_id=14198 You can tell py2exe to exclude them, but if you could turn your code into either a .patch or the complete files as "clean" as possible, I'd certainly consider it. Please reset the bug status to "open" when you do (or just create a new "patch") Thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=965610&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-10-09 05:58:50
|
Bugs item #968033, was opened at 2004-06-07 18:54 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=968033&group_id=78018 Category: pythonwin Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Aleksander Kowalczyk (thealx) Assigned to: Nobody/Anonymous (nobody) Summary: Interactive window repeats each message from Logger object Initial Comment: Interactive window can display Logger-generated messages (INFO, DEBUG, WARN etc). It works correctly on the first run of the module. But on the next run, each message is repeated twice. On third run - repeated 3 times, and so on. This means that after some runs of the module, You must restart pywin32 because each logger message is repeated many times and You cannot read anything useful. This really pains on hard-debugging sessions. An error occures on build 201, Windows XP. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-10-09 15:58 Message: Logged In: YES user_id=14198 This is because Pythonwin runs your programs in-process. The code that sets up the log handler (quite possibly inside the logging module itself) is probably re-adding a new handler to the same log each run. The only solution is to have pythonwin run/debug in a new process, and this isn't practical. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=968033&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-10-09 05:56:18
|
Bugs item #1003067, was opened at 2004-08-04 16:13 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1003067&group_id=78018 Category: pythonwin Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Michael Bax (mrbax) Assigned to: Nobody/Anonymous (nobody) Summary: Post-install script DLL load failed: pywintypes23.dll, Win95 Initial Comment: The post-install script fails with an error when attempting to load pywintypes23.dll. This happens with pywin32 version 200, 201.1 and 202 with Python 2.3 under Windows 95a. Manually copying pywintypes23.dll to the WINDOWS and WINDOWS\SYSTEM directories did not help. This is the error: python pywin32_postinstall.py -install Creating .PTH file E:\PYTHON23\pywin32.pth Traceback (most recent call last): File "E:\PYTHON23\Scripts\pywin32_postinstall.py", line 313, in ? install() File "E:\PYTHON23\Scripts\pywin32_postinstall.py", line 155, in install LoadSystemModule(lib_dir, "pywintypes") File "E:\PYTHON23\Scripts\pywin32_postinstall.py", line 93, in LoadSystemModule ('.dll', 'rb', imp.C_EXTENSION)) ImportError: DLL load failed: A device attached to the system is not functioning. The function call that fails is: mod = imp.load_module( 'pywintypes', None, 'E: \PYTHON23\Lib\site-packages\pywin32_system32\pywintypes23.dll' ('.dll', 'rb', imp.C_EXTENSION) ) ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-10-09 15:56 Message: Logged In: YES user_id=14198 Sorry, it is too hard to try and keep win95 compatability. I'd be happy to accept patches, but aren't going to track it down. ---------------------------------------------------------------------- Comment By: Michael Bax (mrbax) Date: 2004-09-15 12:14 Message: Logged In: YES user_id=1055057 The latest DCOM update for Windows 95 (1.3) does not help. http://www.microsoft.com/com/dcom/dcom95/dcom1_3.asp ---------------------------------------------------------------------- Comment By: Michael Bax (mrbax) Date: 2004-08-10 08:59 Message: Logged In: YES user_id=1055057 Internet Explorer 5.5 SP2 is installed, so it does not appear to be a host DLL problem on the system's side. ---------------------------------------------------------------------- Comment By: Michael Bax (mrbax) Date: 2004-08-04 16:20 Message: Logged In: YES user_id=1055057 The path is correct; it does not have a linebreak after the colon. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1003067&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-10-09 05:52:04
|
Bugs item #1017504, was opened at 2004-08-27 20:44 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1017504&group_id=78018 Category: pythonwin Group: None Status: Open Resolution: None >Priority: 4 Submitted By: Martin Gfeller (gfe) Assigned to: Nobody/Anonymous (nobody) Summary: Debugger fills Registry with 100s of ToolbarDefault-Bar-n Initial Comment: On Windows 2000, PythonWin creates many hundreds of ToolbarDefault-Bar-n keys in the registry once the debugger is invoked (either by debug or post-mortem) and the 'go' or 'close' button is clicked. It seems to be specific to Windows 2000, where it occurs each time, and makes the debugger pretty unusable, because the registry slows down Windows to the point of unusability and instability. I could not reproduce it on Windows XP Pro. Environment: PythonWin Build 202 PythonWin 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)] on win32. Windows 2000, SP4, Build 2195 Best regards, Martin ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-10-09 15:52 Message: Logged In: YES user_id=14198 As I said in 944506: I've failed again to solve this. It sounds alot like Q151446, but that is pre MFC6, and doesn't solve the problem. It *nearly* does. I'm closing this and will keep "[ 1017504 ] Debugger fills Registry with 100s of ToolbarDefault-Bar-n" open (only as it has a better name) The next release will have that SaveBarState() call commented out. Dropping priority as this should mean the bug is much less severe. ---------------------------------------------------------------------- Comment By: bob gailer (ramrom) Date: 2004-08-28 23:19 Message: Logged In: YES user_id=587593 *This problem has also been entered under 894191 and 944506. It definitely causes problems, and has not, to my knowledge been addressed. 944506 has never been assigned! Please, someone who knows the details of what should happen help us. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1017504&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-10-09 05:50:59
|
Bugs item #944506, was opened at 2004-04-30 00:27 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=944506&group_id=78018 Category: pythonwin Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: bob gailer (ramrom) Assigned to: Nobody/Anonymous (nobody) Summary: PythonWin Menus don't work Initial Comment: Platform Windows 2000 Advanced Server. New install of Python 2.3.3 and Win23all 201.1. Start PythonWin. The IDE menus drop down, but nothing happens when an item is selected. Toolbar buttons do nothing. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-10-09 15:50 Message: Logged In: YES user_id=14198 I've failed again to solve this. It sounds alot like Q151446, but that is pre MFC6, and doesn't solve the problem. It *nearly* does. I'm closing this and will keep "[ 1017504 ] Debugger fills Registry with 100s of ToolbarDefault-Bar-n" open (only as it has a better name) The next release will have that SaveBarState() call commented out. ---------------------------------------------------------------------- Comment By: bob gailer (ramrom) Date: 2004-05-13 02:14 Message: Logged In: YES user_id=587593 Just checked; 176 Toolbar Default-Bar keys in the registry. Am getting in habit of deleting these keys and changing Toolbar Default-Summary-> bars to 0. I'd like to understand the registry api so I can write a scipt to make the above changes automatically. Please explain the registry api. ---------------------------------------------------------------------- Comment By: bob gailer (ramrom) Date: 2004-05-12 23:43 Message: Logged In: YES user_id=587593 The # of Toolbar Default-Bar keys in the registry is growing again, but at a lot slower rate. They seem to fall into 2 sets based on the key names inside. This suggests that we need to keep just 2 of these around. True? ---------------------------------------------------------------------- Comment By: bob gailer (ramrom) Date: 2004-05-12 05:28 Message: Logged In: YES user_id=587593 I commented out line 467 - tb.dialog.SaveState() and now the registry does not grow. Of course I now don't have any memory of debugger changes. I wonder about line 466 - if tb.dialog is not None: ??? should it be - if tb.dialog is None: ??? ---------------------------------------------------------------------- Comment By: bob gailer (ramrom) Date: 2004-05-12 00:19 Message: Logged In: YES user_id=587593 Appears that commenting 461 in debugger is not the right thing to do, as the registry keys are still accumulating. What debugger code needs fixing to stop the above? ---------------------------------------------------------------------- Comment By: bob gailer (ramrom) Date: 2004-05-04 00:44 Message: Logged In: YES user_id=587593 So now I see line 461 frame.SaveBarState("ToolbarDebugging"). Is there a better fix than just commenting this? ---------------------------------------------------------------------- Comment By: bob gailer (ramrom) Date: 2004-05-04 00:41 Message: Logged In: YES user_id=587593 Nuking the HKEY_CURRENT_USER\Software\Python 2.3\Python for Win32 key solved it! Regarding the idea of commenting line 462 in Pythonwin\pywin\debugger.py. That line reads: # Hide the debuger toolbars (as they wont normally form part of the main toolbar state. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2004-05-03 12:33 Message: Logged In: YES user_id=14198 This sounds like it might be the same as https://sourceforge.net/tracker/index.php?func=detail&aid=849191&group_id=78018&atid=551954 Nuking the HKEY_CURRENT_USER\Software\Python 2.3\Python for Win32 key might solve it. ---------------------------------------------------------------------- Comment By: bob gailer (ramrom) Date: 2004-05-03 05:13 Message: Logged In: YES user_id=587593 I can enter python expressions and statements and they work as expected. Is that what you mean by commands? Other bizarre things happen at the same time: the Task Manager won't start. If I start the Task Manager first, then PythonWin, some of the Task Manager Menus don't work. The Task Manager shows over 5000 USER objects in use by pythonwin.exe; on another machine where things are OK there are 75 USER Objects. Similar problems have surafced in the past on other machines. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2004-05-02 12:08 Message: Logged In: YES user_id=14198 How bizarre! Never heard anything like this before! Does the rest of Pythonwin work? ie, can you enter commands at the interactive window? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=944506&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-10-09 02:58:49
|
Bugs item #955432, was opened at 2004-05-18 06:01 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=955432&group_id=78018 Category: win32 Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jon Willeke (willeke) Assigned to: Nobody/Anonymous (nobody) Summary: odbc module not portable Initial Comment: I'm interested in using the ODBC module with unixODBC and/or iODBC on Linux. I've gotten it to work, after a fashion, with Python 2.3.3 and unixODBC 2.2.8 on SuSE Linux 8.2. I'd like to know how receptive you would be to portability patches. One category of changes conditionally compiles the Windows-specific things: windows.h, __declspec, etc. Another category of changes removes the few C++ things in an otherwise C-compatible module: declarations, comments, map(), etc. This is mostly in odbc.cpp, but there are also a few changes to dbi.h and dbi.cpp. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-10-09 12:58 Message: Logged In: YES user_id=14198 I believe this is all done ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2004-05-19 11:12 Message: Logged In: YES user_id=14198 I'll get to this in a couple of days. The patches are likely to apply OK as these modules aren't really being developed. Without looking at the patch, and assuming using datetime can be b/w compatible, could we just use a "Python" level API to import the module and call the functions? I'm happy to accept it may not be worth it though. ---------------------------------------------------------------------- Comment By: Jon Willeke (willeke) Date: 2004-05-19 07:16 Message: Logged In: YES user_id=185468 The datetime module's C API is not fully baked, so I guess we're stuck with DBI, for a while. I submitted patches #956244 and #956247 to remove Windows and C++ dependencies. BTW, I think I omitted the -u option on some of the patches I submitted. Let me know if you have any problems with them. ---------------------------------------------------------------------- Comment By: Jon Willeke (willeke) Date: 2004-05-19 03:53 Message: Logged In: YES user_id=185468 I've submitted patches #956091, #956093, and #956094. The first patch has an attachment that includes the latter two, because they don't apply cleanly together. The only essential change to dbi.h is CALLCONV. There's also a warning in the initialization of noMethods in dbi.c. I'm not submitting a patch at this time, because I'd like to experiment with a DBI-less ODBC module. I'm not sure how to test ODBC without a DBMS and a DSN, so I don't have any tests, right now. There has been some discussion on the unixODBC list about developing an ODBC test framework. ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2004-05-18 08:00 Message: Logged In: YES user_id=14198 I would be happy to support that - particularly if the changes came with a few tests - we don't have any at the moment, and that alone would be a big improvement. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=955432&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-10-09 02:41:26
|
Bugs item #833280, was opened at 2003-10-31 06:43 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=833280&group_id=78018 Category: pythonwin Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: David Mischo (mischod) Assigned to: Nobody/Anonymous (nobody) Summary: PythonWin.exe crashes after ODBC driver error. Initial Comment: PythonWin.exe crashes after ODBC driver error. Windows Professional XP; Python 2.3.2.1; Win32All-159 for 2.3 Occurs after getting a reported ODBC driver error finding a table name and I then either re-running script or exit Pythonwin. Happens against either Excel and CSV ODBC sources. In the Excel example, the table name error was because the select statement needed to put the table name in quotes because it referenced a multi-tabbed system table with a $. Select * from Payments needed to be Select * from Payments$. import dbi, odbc try: s = odbc.odbc('AdvWorksExcel') cur = s.cursor() cur.execute('select ProductName from Payments') print cur.description for tup in cur.description: print tup[0], print while 1: rec = cur.fetchmany(10) if not rec: break print rec except NameError,e: print 'error ', e, 'undefined' Traceback (most recent call last): File "C:\PROGRA~1\Python\lib\site- packages\Pythonwin\pywin\framework\scriptutils.py", line 310, in RunScript exec codeObject in __main__.__dict__ File "C:\Documents and Settings\DW\Script3.py", line 6, in ? cur.execute('select ProductName from Payments') dbi.program-error: [Microsoft][ODBC Excel Driver] The Microsoft Jet database engine could not find the object 'Payments'. Make sure the object exists and that you spell its name and the path name correctly. in EXEC >>> Exit PythonWin or Re-Run Script again produces: Unhandled exception in Pythonwin.exe (ODBC.PYD): 0xC0000005: Access Violation ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-10-09 12:41 Message: Logged In: YES user_id=14198 We just fixed another odbc related crash - this is probably the same. Please try in the soon to be released build 203. ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2003-10-31 10:30 Message: Logged In: YES user_id=771074 This is fixed in build 160 and greater. Roger ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=833280&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-10-09 02:40:39
|
Bugs item #804178, was opened at 2003-09-11 14:33 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=804178&group_id=78018 Category: pythonwin Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Christopher J. Prinos (cprinos) Assigned to: Nobody/Anonymous (nobody) Summary: pythonwin.exe installed in wrong location? Initial Comment: I recently installed win32all-157 (after a complete upgrade of my python install from 2.2.1 to 2.3) Once installed, I couldn't get the pythonwin editor to 'edit' any *.py files. The symptoms were exactly the same as described in bug #785374. I rolled back to win32all-153, and everything worked ok. What I noticed was that 153 put the pythonwin.exe file in my <python install dir>/Lib/site-packages/Pythonwin directory, whereas 157 put it in the <python install dir>. With 157 installed, I moved pythonwin.exe to the Pythonwin directory (and updated the file association for the edit action for the new path), and everthing seemed to work again. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-10-09 12:40 Message: Logged In: YES user_id=14198 It is quite hard to convince the new installer to place these executables anywhere else. It should all work fine with a clean build 202. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=804178&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-10-09 02:39:16
|
Bugs item #1022681, was opened at 2004-09-06 04:24 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1022681&group_id=78018 Category: win32 Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Nobody/Anonymous (nobody) Summary: SetScrollInfo masks errors from ParseSCROLLINFOTuple Initial Comment: Using Python 2.3.4 and win32all build 202: >>> import win32gui >>> win32gui.SetScrollInfo(0, 0, ()) Traceback (most recent call last): File "<stdin>", line 1, in ? pywintypes.error: (0, 'SetScrollInfo', 'No error message is available') Looking at ParseSCROLLINFOTuple, it looks to me that all of the paths with return FALSE also make sure a python exception is set (which in the above case would be the much more helpful "SCROLLINFO tuple has invalid size"). However, PySetScrollInfo calls PyWin_SetAPIError when ParseSCROLLINFOTuple returns false, thereby replacing the exception with the unhelpful one in the above traceback. So I'd suggest changing PySetScrollinfo's call to ParseSCROLLINFOTuple to: if (ParseSCROLLINFOTuple(obInfo, &info) == 0) return NULL; ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-10-09 12:39 Message: Logged In: YES user_id=14198 I think this is all fixed now, ---------------------------------------------------------------------- Comment By: Greg Chapman (glchapman) Date: 2004-09-06 04:34 Message: Logged In: YES user_id=86307 Looking closer, the tuple size test at the beginning of ParseSCROLLINFOTuple looks wrong (maximum length should be 6), since the function is written to allow a TrackPos parameter at index 5 in the tuple. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1022681&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-10-09 02:37:35
|
Bugs item #868473, was opened at 2004-01-01 02:37 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=868473&group_id=78018 Category: com Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Gustavo Tabares (gustabares) Assigned to: Nobody/Anonymous (nobody) Summary: win32all-163 install problems Initial Comment: I've had several problems installing version 163 of the Windows Extensions. I have seen these problems on 8 seperate machines running either Win2k or WinXP. These machines were all previously running Python 2.3.2 with the 157 version of the Windows extensions. I attempted to upgrade each machine to Python 2.3.3 with version 163. The uninstall of Python 2.3.2 and 157 went smoothly on every machine. The install of Python 2.3.3 also went smoothly on every machine. The problem comes at the end of the 163 install. When the install goes to register the COM Server AXScript Engine, the install either crashes or produces the following error messages: exceptions.AttributeError: 'module' object has no attribute '__import_pywin32_system_module__' exceptions.AttributeError: 'module' object has no attribute 'com_error' exceptions.ImportError: cannot import name DISPATCH_METHOD When the install crashes, I relaunch the install for 163 and it asks if I would like to uninstall, so I click 'Yes' and the uinstall fails, so it continues to install 163 and works fine. However, machines that receive the above error messages I am unable to fix or get working. These machines are up-to-date as far as updates and patches but have NOT installed any kind of COM updates or such. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-10-09 12:37 Message: Logged In: YES user_id=14198 Does this still happen with the 20x series builds? ---------------------------------------------------------------------- Comment By: Todd Whiteman (twhiteman) Date: 2004-01-19 16:09 Message: Logged In: YES user_id=954612 I have noticed the same error. I have a brand new Windows XP machine. I installed Python-2.3.3.exe. I then proceeded to try and install win32all-163.exe. The install crashes (around 100% progress bar) and no cleanup is performed. Any ideas on why this is occuring? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=868473&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-10-09 02:36:25
|
Bugs item #907801, was opened at 2004-03-02 07:10 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=907801&group_id=78018 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: David W. Nichols (dwnichols) Assigned to: Nobody/Anonymous (nobody) Summary: failed shortcuts when changed Start Menu Group Initial Comment: When I installed Python 2.3.3, I changed Start Menu Group setting from its default of "Python 2.3" to "Python233". Here's the results from the final install screen: Creating .PTH file C:\Python23\pywin32.pth Copy pythoncom23.dll to C:\WINDOWS\system32 Copy pywintypes23.dll to C:\WINDOWS\system32 Registered: Python.Interpreter Registered: Python.Dictionary -> Software\Python\PythonCore\2.3\Help[None]=None -> Software\Python\PythonCore\2.3\Help\Pythonwin Reference[None]='C: \Python23\Lib\site-packages\PyWin32.chm' Creating directory C: \Python23\Lib\site-packages\win32com\gen_py Failed to create shortcut 'C:\Documents and Settings\All Users\Start Menu\Programs\Python 2.3\PythonWin.lnk' - error 0x80070003 The pywin32 extensions were successfully installed. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-10-09 12:36 Message: Logged In: YES user_id=14198 Thanks - I have fixed that for the next release. ---------------------------------------------------------------------- Comment By: HAVOK (havok) Date: 2004-05-27 04:08 Message: Logged In: YES user_id=12566 Python seems to store this changed group in: HKLM\SOFTWARE\Python\PythonCore\2.3\InstallPath\InstallGroup Maybe the installation can use above key if it exists, keeping the existing stuff (Python 2.3) as a fallback. ---------------------------------------------------------------------- Comment By: Phillip Ruggera (pruggera) Date: 2004-05-10 14:45 Message: Logged In: YES user_id=16022 This happened to me too. I manually created a shortcut to C:\Python23\Lib\site-packages\pythonwin\Pythonwin.exe and all was well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=907801&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-10-09 02:25:16
|
Bugs item #959449, was opened at 2004-05-24 23:54 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=959449&group_id=78018 Category: com Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Jan Erik Breimo (jebreimo) Assigned to: Nobody/Anonymous (nobody) Summary: Error when using IID in all builds after 159 Initial Comment: The following script: import win32com.client.gencache Excel = win32com.client.gencache.EnsureModule ('{00020813-0000-0000-C000-000000000046}', 0, 1, 4) excel = Excel.Application() and simliar scripts that use other servers always fail as follows in builds 161, 163 and 201: D:\ws\k2is_source.CC-V2\Tools\Python\diverse>python ExcelTest.py Traceback (most recent call last): File "ExcelTest.py", line 3, in ? excel = Excel.Application() File "C:\Python23\Lib\site- packages\win32com\client\__init__.py", line 489, in __init__ if oobj is None: oobj = pythoncom.new(self.CLSID) TypeError: Only strings and iids can be converted to a CLSID. In builds 153, 155 and 159 the scripts run without errors. I'm using Python 2.3.3 on Win2k Professional SP 4 ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-10-09 12:25 Message: Logged In: YES user_id=14198 This is caused by duplicate pythoncom23.dll files - see if you can find the dupe and remove it. Otherwise please reopen this bug. The latest installers try and detect this situation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=959449&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2004-10-09 02:23:41
|
Bugs item #963802, was opened at 2004-06-01 06:35 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=963802&group_id=78018 Category: com Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Nobody/Anonymous (nobody) Summary: Access violation with bad parameter to GetAttributesOf Initial Comment: I've discovered that Pythonwin will rash with an access violation shortly after doing somthing like this: >>> from win32com.shell import shell >>> d = shell.SHGetDesktopFolder() >>> t = d.ParseDisplayName(0, None, r"c:\windows\assembly") >>> d.GetAttributesOf(t[1], -1) In particular, if I try to drag a file onto Pythonwin, I get an access violation. t[1] above is a list of strings. Looking at PyObject_FromPIDLArray (called by PyIShellFolder::GetAttributesOf), I note that it mallocs an array (ppidl), and then passes it to PyObject_FreePIDLArray if PyObject_AsPIDL fails (as it will in this case since the elements of t[1] are strings). Since, *ppidl is not initialized before being passed to PyObject_FreePIDLArray, it appears random pointers may be being passed to PyShell_FreeMem, thus corrupting the shell's heap and causing the AV. Anyway, the malloc in PyObject_FromPIDLArray should probably be a calloc. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2004-10-09 12:23 Message: Logged In: YES user_id=14198 This has since been fixed - thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=963802&group_id=78018 |
2 messages has been excluded from this view by a project administrator.
