pywin32-bugs Mailing List for Python for Windows Extensions (Page 113)
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...> - 2003-10-06 17:43:11
|
Bugs item #794193, was opened at 2003-08-24 11:56 Message generated for change (Comment added) made by cprinos You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=794193&group_id=78018 Category: pythonwin Group: None Status: Open Resolution: None Priority: 5 Submitted By: Malte Forkel (mforkel) Assigned to: Nobody/Anonymous (nobody) Summary: Pythonwin module browser has problem with top level function Initial Comment: After upgrading from Python 2.2 to Python 2.3, I noticed that in the module browser all top level functions are simply shown as instances of pyclbr.Function. These list entries can't be used to locate the function definition in the source code. I tried win32all builds 155 and 157 with Python 2.3.0.0 on a Windows 2000 machine. I managed to fix the problem by adding the following __init__ function to HierListCLBRFunction in ModuleBrowser.py: def __init__(self, clbrclass, suffix = ""): try: name = clbrclass.name file = clbrclass.file lineno = clbrclass.lineno except AttributeError: name = clbrclass file = lineno = None self.super = [] self.methods = {} HierListCLBRItem.__init__(self, name, file, lineno, suffix) This code is a variation on the HierListCLBRClass.__init__ function. I guess the problem is caused by instances of pyclbr.Function not having the attributes 'super' and 'name' that are accessed in HierListCLBRClass.__init__. The AttributeError error handling code will then set locals 'name', 'file', and 'lineno' to None. I attach an edited version of ModuleBrowser.py, based on win32all build 155. ---------------------------------------------------------------------- Comment By: Christopher J. Prinos (cprinos) Date: 2003-10-06 12:42 Message: Logged In: YES user_id=571862 this patch works, although it might be better (6 of one, half dozen of another)to have HierListCLBRFunction inherit from HierListCLBRItem instead of HierLiestCLBRClass (then you don't need to assign 'super' and 'method' attributes at all in the __init__) BTW, this was broken by a change from Python 2.2->2.3 when some of the pyclbr.py code was rewritten (and Function info no longer inherit from Classe info) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=794193&group_id=78018 |
|
From: <vik...@t-...> - 2003-10-03 19:13:47
|
Hi,
I'd like to report an installation-problem with version 157.
My environment is Python-2.3.2 on a WinXP-Pro Laptop. - I'm
attaching the portion of my installation-log:
### Start ###
20:13 03.10.2003
o Install Python-2.3.2.exe into D:\Python23\
- Select "Yes, make backups"
- Select all possible components
- Select menu group "Python 2.3"
20:28 03.10.2003
o Install win32all-157
- Do not install Pythonwin as the default editor for
python source.
- Installation did not finish successfully. - No automatic
problem report sent.
- Pythonwin is at least partially visible in menu group
"Python 2.3"
20:53 03.10.2003
o Try to de-install win32al-157.
- Does not work. Wise Uninstall: Could not open INSTALL.LOG file.
### End ###
Is there anything else possible on my side to provide you with more
problem-related info ?
Any sugestions from your side on how to get rid of the "partial"
installation in the most effective way ?
Thanks in advance for your feedback.
Regards,
Viktor Ransmayr
|
|
From: SourceForge.net <no...@so...> - 2003-10-03 10:41:42
|
Feature Requests item #817051, was opened at 2003-10-03 12:41 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=817051&group_id=78018 Category: com Group: None Status: Open Priority: 5 Submitted By: Gael Fraiteur (gfraiteur) Assigned to: Nobody/Anonymous (nobody) Summary: Documentation: writing extensions Initial Comment: I am missing a point in the documentation. I would like to write an extension function in C for Python on Windows. This function will hold a *IDispatch pointer and would like to return it to Python. That is, it has to create a Dispatch object with it (dynamic or static). I do not see how. Practically, my intent is to embed Python into an application. Embedded scripts should be able to access the database through ADO. I would like to pass the ADO connection object to Python. Please consider to make this point clearer in the documentation and/or to provide an easy method to create a wrapper given a *IDispatch. Thanks a lot. Gael Fraiteur ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=817051&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2003-10-03 09:46:12
|
Bugs item #817035, was opened at 2003-10-03 09:46 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=817035&group_id=78018 Category: pythonwin Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dominique de Waleffe (ddewaleffe) Assigned to: Nobody/Anonymous (nobody) Summary: Exception in browsing libraries (Tools->Browse PythonPath) Initial Comment: Using the 2.3 distribution and the latest 159 release of pythonwin. I get the following traceback when I click on the + in the library browser for xml.dom.minidom. The problem also appears for other libraries displayed in the tree view, but not for all... PythonWin 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 32 bit (Intel)] on win32. Portions Copyright 1994-2001 Mark Hammond (mha...@sk...) - see 'Help/About PythonWin' for further copyright information. >>> Traceback (most recent call last): File "C:\softs\python\lib\site-packages\Pythonwin\pywin\tools\hierlist.py", line 123, in OnTreeItemExpanding self.AddSubList(itemHandle, self.GetSubList(item)) File "C:\softs\python\lib\site-packages\Pythonwin\pywin\tools\hierlist.py", line 137, in AddSubList self.AddItem(parentHandle, item) File "C:\softs\python\lib\site-packages\Pythonwin\pywin\tools\hierlist.py", line 140, in AddItem text = self.GetText(item) File "C:\softs\python\lib\site-packages\Pythonwin\pywin\tools\hierlist.py", line 266, in GetText return self.DelegateCall( item.GetText ) File "C:\softs\python\lib\site-packages\Pythonwin\pywin\tools\hierlist.py", line 255, in DelegateCall return fn() File "C:\softs\python\lib\site-packages\Pythonwin\pywin\tools\browseProjects.py", line 26, in GetText return self.name + self.suffix TypeError: unsupported operand type(s) for +: 'instance' and 'str' win32ui: Exception in OnNotify() handler ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=817035&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2003-09-30 03:35:35
|
Feature Requests item #766328, was opened at 2003-07-05 06:16 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=766328&group_id=78018 Category: win32 Group: None Status: Open Priority: 5 Submitted By: Ruben Marquez (rrm1) Assigned to: Nobody/Anonymous (nobody) Summary: Explorer Shell Extensions Initial Comment: Hope this is not a silly request. I wonder if a way of implementing Explorer Shell Extensions could be provided so that they could be built with Python without having to resort to C/C++. For background on this request, you can look at the first hit on a search on comp.lang.python for "shell extension". Your work and help is much apreciated. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2003-09-29 20:35 Message: Logged In: NO As a last resort you can try to do in on pythonscript (.wsc)... ---------------------------------------------------------------------- Comment By: Ruben Marquez (rrm1) Date: 2003-07-21 06:21 Message: Logged In: YES user_id=307646 There have been a few threads at C.L.P. about this issue in the past. One particularly interesting included M.H. and A. Martelli. It looked as if they were onto something, but I don't think it was followed through. This is the link: http://groups.google.com/groups?hl=en&lr=&ie=UTF- 8&oe=UTF-8&th=20a5f8176ef4ddcd&rnum=2 It looks like what needs to be implemented is IDropTarget, IDataObject, and/or IPersistFile. These interfaces would be added to the existing "win32com.shell" module. -Ruben ---------------------------------------------------------------------- Comment By: Michael Dubner (dubnerm) Date: 2003-07-19 18:09 Message: Logged In: YES user_id=39274 Not sure but, isn't creating an explorer extention just a matter of implementing object supporting some pre-defined interfaces (i.e. for extention toolbar)? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=766328&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2003-09-29 23:51:06
|
Feature Requests item #743527, was opened at 2003-05-26 12:11 Message generated for change (Comment added) made by dubnerm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=743527&group_id=78018 Category: None Group: None Status: Open Priority: 5 Submitted By: Michael Dubner (dubnerm) Assigned to: Nobody/Anonymous (nobody) Summary: support for cygwin Initial Comment: Not sure that it will be easy, but there are w32api package... ---------------------------------------------------------------------- >Comment By: Michael Dubner (dubnerm) Date: 2003-09-30 03:51 Message: Logged In: YES user_id=39274 Not sure. At last w32api cygwin package is compatible by signatures with MS library (as it uses same dlls!). Also I've just created oversimplified wrapper (with only functions used by anygui.backends.mswgui) with PyRex. Something like: --- win32api.pyx: cdef extern from "windows.h": ctypedef unsigned int UINT int w32_Beep "Beep" (UINT dwFreq, UINT dwDuration) def Beep(UINT freq, UINT dur): return w32_Beep(freq, dur) --- setup.py ... Extension("win32api", ["win32api.pyx"]), ... --- and what startled me it works under both VC and cygwin. ---------------------------------------------------------------------- Comment By: Tony Meyer (anadelonbrin) Date: 2003-09-18 03:15 Message: Logged In: YES user_id=552329 Could you not, then, port those extensions? Or use both the cygwin python and the windows one, running as separate processes and working together? Seems a lot simpler than porting all the win32all stuff over to cygwin... ---------------------------------------------------------------------- Comment By: Michael Dubner (dubnerm) Date: 2003-09-18 03:12 Message: Logged In: YES user_id=39274 There are couple of extentions that exists only as cygwin versions ---------------------------------------------------------------------- Comment By: Tony Meyer (anadelonbrin) Date: 2003-09-03 05:57 Message: Logged In: YES user_id=552329 I realise that, but my point was that you're on windows, so you can use a windows version of Python if you want to do windows things. If you want to do *nix'y sort of things, then use the cygwin version. You can still run the windows python in cygwin. ---------------------------------------------------------------------- Comment By: Michael Dubner (dubnerm) Date: 2003-09-03 05:52 Message: Logged In: YES user_id=39274 Standard extentions can't work with cygwin version of python and visa-versa cygwin extentions can't work with windows version of python. ---------------------------------------------------------------------- Comment By: Tony Meyer (anadelonbrin) Date: 2003-05-26 12:15 Message: Logged In: YES user_id=552329 Why would you need support for cygwin? If you're running cygwin, then you have Windows, so you can use the standard extensions, can't you? (seems to work for me). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=743527&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2003-09-28 00:49:45
|
Bugs item #799063, was opened at 2003-09-02 22:40 Message generated for change (Comment added) made by sjrackham You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=799063&group_id=78018 Category: com Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthias Kirst (mattkirst) Assigned to: Nobody/Anonymous (nobody) Summary: Registering Python COM Server component category crashes Initial Comment: When registering the Python COM Server component category, Python crashes with Dr.Watson. The crash happens when executing the last line in the function: def RegisterPyComCategory(): """ Register the Python COM Server component category. """ regCat = _cat_registrar() regCat.RegisterCategories( [ (CATID_PythonCOMServer, 0x0409, "Python COM Server") ] ) ---------------------------------------------------------------------- Comment By: Stuart Rackham (sjrackham) Date: 2003-09-28 12:49 Message: Logged In: YES user_id=655059 Observed on Win98/XP/2000/NT4. A workaround is to have your installer write the following registry entry *before* registering the server: [HKEY_CLASSES_ROOT\Component Categories\{B3EF80D0-68E2-11D0-A689-00C04FD658FF}] "409"="Python COM Server" ---------------------------------------------------------------------- Comment By: Matthias Kirst (mattkirst) Date: 2003-09-05 18:55 Message: Logged In: YES user_id=397984 Bingo! The installation crashed as well with 154 (NT/XP). Since I experienced my crash with a customized Python/PythonCOM version I did not register the scripting engine -> the crash occured when I registered my first COM component. Since win32all does not unregister the Python COM Server component category when uninstalling you succeed when preinstalling an older version of win32all. ---------------------------------------------------------------------- Comment By: John J Smith (johnjsmith) Date: 2003-09-05 06:47 Message: Logged In: YES user_id=830565 Is this related to bug #784962 (Installation crash in recent win32all's)? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=799063&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2003-09-25 03:26:25
|
Patches item #812181, was opened at 2003-09-24 22:26 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=812181&group_id=78018 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Roger Upole (rupole) Assigned to: Nobody/Anonymous (nobody) Summary: EnumResourceTypes, EnumResourceLanguages Initial Comment: Unicode versions ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=812181&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2003-09-18 10:21:33
|
Patches item #808465, was opened at 2003-09-18 12:21 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=808465&group_id=78018 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Fraser (davidfraser) Assigned to: Nobody/Anonymous (nobody) Summary: Fix PyTime.Format Initial Comment: currently PyTime.Format does not return proper values for day of week and day of year. This is because these are not set in the tm struct that is given to _tcsftime This patch fixes that by calling mktime to convert to a time_t representation, and localtime to convert it back. This is done because although day of week is available in SYSTEMTIME as st.wDayOfWeek, day of year is not available and it would be fairly complex to calculate (I don't know another system function that will do this). In addition, I increased the buffer size for the Format for 256 (I was getting blank strings returned when testing long format strings - see patch 808464 which contains a test for PyTime.Format). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=808465&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2003-09-18 10:20:24
|
Patches item #808464, was opened at 2003-09-18 12:20 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=808464&group_id=78018 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Fraser (davidfraser) Assigned to: Nobody/Anonymous (nobody) Summary: add test for PyTime.Format Initial Comment: I encountered a bug in PyTime.Format which I will submit a patch for. In the process I added a test for PyTime.Format. Since this did not seem to fit into any of the existing test categories, I added a file test_pywintypes.py (although at the moment it only contains this test, presumably others could be added if required). The diff is against /dev/null ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=808464&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2003-09-17 23:15:02
|
Feature Requests item #743527, was opened at 2003-05-26 20:11 Message generated for change (Comment added) made by anadelonbrin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=743527&group_id=78018 Category: None Group: None Status: Open Priority: 5 Submitted By: Michael Dubner (dubnerm) Assigned to: Nobody/Anonymous (nobody) Summary: support for cygwin Initial Comment: Not sure that it will be easy, but there are w32api package... ---------------------------------------------------------------------- Comment By: Tony Meyer (anadelonbrin) Date: 2003-09-18 11:15 Message: Logged In: YES user_id=552329 Could you not, then, port those extensions? Or use both the cygwin python and the windows one, running as separate processes and working together? Seems a lot simpler than porting all the win32all stuff over to cygwin... ---------------------------------------------------------------------- Comment By: Michael Dubner (dubnerm) Date: 2003-09-18 11:12 Message: Logged In: YES user_id=39274 There are couple of extentions that exists only as cygwin versions ---------------------------------------------------------------------- Comment By: Tony Meyer (anadelonbrin) Date: 2003-09-03 13:57 Message: Logged In: YES user_id=552329 I realise that, but my point was that you're on windows, so you can use a windows version of Python if you want to do windows things. If you want to do *nix'y sort of things, then use the cygwin version. You can still run the windows python in cygwin. ---------------------------------------------------------------------- Comment By: Michael Dubner (dubnerm) Date: 2003-09-03 13:52 Message: Logged In: YES user_id=39274 Standard extentions can't work with cygwin version of python and visa-versa cygwin extentions can't work with windows version of python. ---------------------------------------------------------------------- Comment By: Tony Meyer (anadelonbrin) Date: 2003-05-26 20:15 Message: Logged In: YES user_id=552329 Why would you need support for cygwin? If you're running cygwin, then you have Windows, so you can use the standard extensions, can't you? (seems to work for me). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=743527&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2003-09-17 23:12:17
|
Feature Requests item #743527, was opened at 2003-05-26 12:11 Message generated for change (Comment added) made by dubnerm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=743527&group_id=78018 Category: None Group: None Status: Open Priority: 5 Submitted By: Michael Dubner (dubnerm) Assigned to: Nobody/Anonymous (nobody) Summary: support for cygwin Initial Comment: Not sure that it will be easy, but there are w32api package... ---------------------------------------------------------------------- >Comment By: Michael Dubner (dubnerm) Date: 2003-09-18 03:12 Message: Logged In: YES user_id=39274 There are couple of extentions that exists only as cygwin versions ---------------------------------------------------------------------- Comment By: Tony Meyer (anadelonbrin) Date: 2003-09-03 05:57 Message: Logged In: YES user_id=552329 I realise that, but my point was that you're on windows, so you can use a windows version of Python if you want to do windows things. If you want to do *nix'y sort of things, then use the cygwin version. You can still run the windows python in cygwin. ---------------------------------------------------------------------- Comment By: Michael Dubner (dubnerm) Date: 2003-09-03 05:52 Message: Logged In: YES user_id=39274 Standard extentions can't work with cygwin version of python and visa-versa cygwin extentions can't work with windows version of python. ---------------------------------------------------------------------- Comment By: Tony Meyer (anadelonbrin) Date: 2003-05-26 12:15 Message: Logged In: YES user_id=552329 Why would you need support for cygwin? If you're running cygwin, then you have Windows, so you can use the standard extensions, can't you? (seems to work for me). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=743527&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2003-09-14 06:59:35
|
Patches item #805880, was opened at 2003-09-14 01:59 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=805880&group_id=78018 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Roger Upole (rupole) Assigned to: Nobody/Anonymous (nobody) Summary: GetFileVersionInfo Initial Comment: Calls to VerQueryValue are done internally instead of returning a buffer and requiring separate function calls. This is a performance hit since GetFileVersionInfo has to be called for each item, but simplifies the calling code. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=805880&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2003-09-14 02:18:14
|
Feature Requests item #805837, was opened at 2003-09-14 04:18 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=805837&group_id=78018 Category: None Group: None Status: Open Priority: 5 Submitted By: Jaros³aw Zabie³³o (zbiru) Assigned to: Nobody/Anonymous (nobody) Summary: More of functionality of Spe editor... Initial Comment: I found a few easy but excelent features of Spe editor. I wish them to be added to Pythonwin. Try to install Spe from http://spe.pycs.net and download it's example.py file. Spe can create automatic todo list, highlighting the most important ones, sticky notes and much more. Very handy for programers. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=805837&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2003-09-13 20:02:34
|
Bugs item #784962, was opened at 2003-08-07 19:13 Message generated for change (Comment added) made by johnjsmith You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=784962&group_id=78018 Category: None Group: None Status: Open Resolution: Works For Me Priority: 5 Submitted By: John J Smith (johnjsmith) Assigned to: Nobody/Anonymous (nobody) Summary: Installation crash in recent win32all's. Initial Comment: The win32all installer has been crashing on me for the last few win32all releases. This has happened for Python 2.2.3 with win32all-156 and Python 2.3 with win32all-157. It has also happened for some previous win32all releases (such as 153 and 155 with Python 2.3). The error occurs during the `Completing Installation' stage, when the message box says `Registering COM Server AXScript Engine'. The error message is the usual `This program has performed an illegal operation and will be shut down' message. Pressing the `Details' button gives: WIN32ALL-156 caused an invalid page fault in module MSVCRT.DLL at 016f:7800b936. Registers: EAX=006b61a0 CS=016f EIP=7800b936 EFLGS=00010202 EBX=00000000 SS=0177 ESP=0063cad4 EBP=0063caf0 ECX=00000120 DS=0177 ESI=01ddab0c FS=3fb7 EDX=00000000 ES=0177 EDI=00000013 GS=0000 Bytes at CS:EIP: 89 5a 04 8b 55 0c 89 4d fc 8b 5a 04 8b 52 08 89 Stack dump: 00760840 01ddab10 00000001 006b8930 00000000 000004d0 00000120 0063cb34 7800b30c 0075005c 01ddac2c 00760840 00000000 00000001 bff813f8 81d52568 (This is with Python 2.2.3 and win32all-156.) This has happened on both WinXP and Win98SE. Once this happens, the win32all uninstaller doesn't work (says `can't find install.log'). If Python is installed with the `Non-Admin' option, then win32all installs fine (presumably because it never reaches the `Registering COM Server AXScript Engine' stage). I haven't seen anyone else report this, so looks like I'm the only one. Any help is greatly appreciated. ---------------------------------------------------------------------- >Comment By: John J Smith (johnjsmith) Date: 2003-09-13 20:02 Message: Logged In: YES user_id=830565 This seems to be related to bug #799063 (Registering Python COM Server component category crashes). ---------------------------------------------------------------------- Comment By: Michael Geary (geary) Date: 2003-08-11 07:24 Message: Logged In: YES user_id=114596 I see a very similar crash when installing win32all-154 on a Python 2.2.2 installation. This is on a clean Windows XP virtual machine with nothing but VS.NET 2003 installed. If I install Python 2.2.2 on this VM and then install win32all-154, it crashes. If I then run the pyscript.py, that succeeds. After reverting the VM, if I install Python 2.2.2 and then install win32all-152, it succeeds. If I then install win32all-154 (letting it uninstall 152), this also succeeds. So the crash happens only when installing 154 without having previously installed 152. The crash is an access violation writing to location 0. Here is the stack trace (with apologies for its length): ntdll.dll!77f57e4f() ntdll.dll!77f93a50() ntdll.dll!77f93a50() ntdll.dll!77f57cf7() ntdll.dll!77f588f5() ntdll.dll!77f93a73() ntdll.dll!77f5be44() kernel32.dll!77e78bf1() kernel32.dll!77e78c14() kernel32.dll!77e78c14() msvcrt.dll!77c2ac14() msvcrt.dll!77c2ac2a() msvcrt.dll!77c2ac55() python22.dll!1e04f836() python22.dll!1e052b2d() python22.dll!1e052963() python22.dll!1e05306b() python22.dll!1e052ef3() python22.dll!1e05e84b() python22.dll!1e05e886() python22.dll!1e040f66() python22.dll!1e040d92() ntdll.dll!77f58ec1() msvcrt.dll!77c2ab2e() msvcrt.dll!77c2ab33() msvcrt.dll!77c2ab33() python22.dll!1e040ab3() python22.dll!1e04025b() ntdll.dll!77f588f5() python22.dll!1e03afdb() ntdll.dll!77f58ec1() msvcrt.dll!77c2ab2e() msvcrt.dll!77c2ab33() python22.dll!1e02f9ab() msvcrt.dll!77c2ab33() python22.dll!1e04f9eb() python22.dll!1e03fe16() python22.dll!1e03fe4c() python22.dll!1e03fac6() ntdll.dll!77f93a73() ntdll.dll!77f58a7e() ntdll.dll!77f58ec1() python22.dll!1e016137() python22.dll!1e015e89() python22.dll!1e03a90f() python22.dll!1e03f98f() python22.dll!1e00d2f8() python22.dll!1e04d469() python22.dll!1e006ccc() python22.dll!1e014977() python22.dll!1e012879() python22.dll!1e01376f() python22.dll!1e013e2f() python22.dll!1e0109f2() python22.dll!1e03f701() python22.dll!1e040ddc() python22.dll!1e02fc88() python22.dll!1e02fc88() python22.dll!1e051151() python22.dll!1e050dcb() python22.dll!1e040ab3() python22.dll!1e04025b() python22.dll!1e03afdb() python22.dll!1e03ac39() ntdll.dll!77f8d98c() msvcrt.dll!77c2af77() ntdll.dll!77f83367() python22.dll!1e03fe16() python22.dll!1e03fb04() user32.dll!77d48fb4() ntdll.dll!77f93a73() ntdll.dll!77f58a7e() ntdll.dll!77f58ec1() python22.dll!1e04d469() python22.dll!1e072ae1() python22.dll!1e072b09() python22.dll!1e072d2b() python22.dll!1e01349d() python22.dll!1e072ac9() python22.dll!1e072b09() python22.dll!1e072d2b() python22.dll!1e03f98f() python22.dll!1e00d2f8() python22.dll!1e04d469() python22.dll!1e012c54() python22.dll!1e01376f() python22.dll!1e013e2f() python22.dll!1e039390() python22.dll!1e006ccc() python22.dll!1e014977() python22.dll!1e00d427() python22.dll!1e04d469() python22.dll!1e012c54() python22.dll!1e01376f() python22.dll!1e013e2f() python22.dll!1e039390() python22.dll!1e006ccc() python22.dll!1e014977() python22.dll!1e00d427() python22.dll!1e04d469() python22.dll!1e012c54() python22.dll!1e01376f() python22.dll!1e013e2f() python22.dll!1e014c14() python22.dll!1e012d1a() python22.dll!1e01376f() python22.dll!1e013e2f() python22.dll!1e039390() python22.dll!1e006ccc() python22.dll!1e014977() python22.dll!1e006ca1() PyWise22.dll!00a91bd8() -Mike ---------------------------------------------------------------------- Comment By: John J Smith (johnjsmith) Date: 2003-08-08 10:12 Message: Logged In: YES user_id=830565 Okay, here is some more info. This sequence on a newly installed Win98SE works: Install Python 2.2.3 Install win32all-152 This sequence on a newly installed Win98SE crashes: Install Python 2.2.3 Install win32all-154 This sequence on a newly installed Win98SE *works*: Install Python 2.2.3 Install win32all-152 Uninstall win32all-152 Install win32all-154 And, finally, this also works on a fresh Win98SE: Install Python 2.2.3 Install win32all-152 Uninstall win32all-152 Install win32all-154 Uninstall win32all-154 Uninstall Python 2.2.3 Install Python 2.3 Install win32all-157 The installer crash has happened for me on at least 5 PCs with very different configurations (spanning Win98SE, Win2K, WinXP, Athlon, P3, P4, and different peripherals and drivers). In each case, Python and win32all were being installed for the first time on the PC. My guess is that most people are upgrading from cleanly installed versions of win32all, and are therefore not seeing the problem. ---------------------------------------------------------------------- Comment By: John J Smith (johnjsmith) Date: 2003-08-08 08:47 Message: Logged In: YES user_id=830565 I assume you mean run it after the failed installation. I tried it on Python 2.3, win32all-157, Win98SE, and it worked: Registered: Python Registration of Python ActiveX Scripting Engine complete. And yes, an admin install even after crashing does work, and I've been using it. However it would be nice to have a clean install (especially for eventual un-installation and upgradation). ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2003-08-08 04:07 Message: Logged In: YES user_id=14198 Can you please see if running "win32comext\axscript\client\pyscript.py" also crashes for you? An admin install should still actually work fine - just can't be uninstalled, and a couple of demo COM objects won't be installed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=784962&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2003-09-11 20:35:34
|
Bugs item #785374, was opened at 2003-08-08 13:13 Message generated for change (Comment added) made by rrm1 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=785374&group_id=78018 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ruben Marquez (rrm1) Assigned to: Nobody/Anonymous (nobody) Summary: Pythonwin startup error. Initial Comment: On an XP Profesional Machine, I upgraded from Python23rc1 to Python23 final. I uninstalled the old packages and installed the new ones (Python23, and win32all-155) in a different location, "D:\Programs\Python23". It all seemed to install correctly, but when trying to start the Pythonwin application the following error appeared in window: <Error getting traceback - cant import traceback>exceptions.ImportError: No module named pywin.framework.startup I then decided to start from scratch. I removed again all my python related packages. I deleted any remnants of the installation folder. I went to the registry and deleted the Python23 key. I rebooted the machine. I installed Python into D:\Programs\Python23, and it installed correctly. I then installed win32all-155.exe. It all seemed to go well, the Start Menu shortcuts were created, no errors. But when I tried to start the Pythonwin application it failed again with the same error message: <Error getting traceback - cant import traceback>exceptions.ImportError: No module named pywin.framework.startup Interestingly, when I launch the following, the app starts fine: D:\Programs\Python23\Lib\site- packages\Pythonwin\start_pythonwin.pyw But, if I launch the following, I get the error: D:\Programs\Python23\pythonwin.exe -Ruben ---------------------------------------------------------------------- >Comment By: Ruben Marquez (rrm1) Date: 2003-09-11 20:35 Message: Logged In: YES user_id=307646 Christopher, You are correct. Your workaround is indeed a workaround. Thanks. -Ruben ---------------------------------------------------------------------- Comment By: Christopher J. Prinos (cprinos) Date: 2003-09-11 18:11 Message: Logged In: YES user_id=571862 Ruben, see bug #804178 for a workaround (I don't know if it's really a fix or not until Mark H. comments) ---------------------------------------------------------------------- Comment By: Ruben Marquez (rrm1) Date: 2003-08-14 12:31 Message: Logged In: YES user_id=307646 Problem persists after uninstalling win32all-155 and installing win32all-157. The worst part is that I can not open python files from Explorer. I also notice that some settings are not saved, such as the one for showing empty spaces and the indentation guidelines. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=785374&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2003-09-11 18:11:53
|
Bugs item #785374, was opened at 2003-08-08 08:13 Message generated for change (Comment added) made by cprinos You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=785374&group_id=78018 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Ruben Marquez (rrm1) Assigned to: Nobody/Anonymous (nobody) Summary: Pythonwin startup error. Initial Comment: On an XP Profesional Machine, I upgraded from Python23rc1 to Python23 final. I uninstalled the old packages and installed the new ones (Python23, and win32all-155) in a different location, "D:\Programs\Python23". It all seemed to install correctly, but when trying to start the Pythonwin application the following error appeared in window: <Error getting traceback - cant import traceback>exceptions.ImportError: No module named pywin.framework.startup I then decided to start from scratch. I removed again all my python related packages. I deleted any remnants of the installation folder. I went to the registry and deleted the Python23 key. I rebooted the machine. I installed Python into D:\Programs\Python23, and it installed correctly. I then installed win32all-155.exe. It all seemed to go well, the Start Menu shortcuts were created, no errors. But when I tried to start the Pythonwin application it failed again with the same error message: <Error getting traceback - cant import traceback>exceptions.ImportError: No module named pywin.framework.startup Interestingly, when I launch the following, the app starts fine: D:\Programs\Python23\Lib\site- packages\Pythonwin\start_pythonwin.pyw But, if I launch the following, I get the error: D:\Programs\Python23\pythonwin.exe -Ruben ---------------------------------------------------------------------- Comment By: Christopher J. Prinos (cprinos) Date: 2003-09-11 13:11 Message: Logged In: YES user_id=571862 Ruben, see bug #804178 for a workaround (I don't know if it's really a fix or not until Mark H. comments) ---------------------------------------------------------------------- Comment By: Ruben Marquez (rrm1) Date: 2003-08-14 07:31 Message: Logged In: YES user_id=307646 Problem persists after uninstalling win32all-155 and installing win32all-157. The worst part is that I can not open python files from Explorer. I also notice that some settings are not saved, such as the one for showing empty spaces and the indentation guidelines. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=785374&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2003-09-11 04:33:11
|
Bugs item #804178, was opened at 2003-09-10 23:33 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=804178&group_id=78018 Category: pythonwin Group: None Status: Open Resolution: None 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=804178&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2003-09-07 02:59:16
|
Patches item #801864, was opened at 2003-09-06 21:59 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=801864&group_id=78018 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Roger Upole (rupole) Assigned to: Nobody/Anonymous (nobody) Summary: fix for sf bug # 754796 Initial Comment: The error section for cursor.execute decrefs the description, and the cursor's destructor also decrefs the description if it's not null. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=801864&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2003-09-06 18:19:34
|
Patches item #801727, was opened at 2003-09-06 13:19 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=801727&group_id=78018 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Roger Upole (rupole) Assigned to: Nobody/Anonymous (nobody) Summary: win32net.NetServerDiskEnum only returns every other drive Initial Comment: An empty string was returned for 2nd, 4th etc drives. Also, the buffer from the api call was leaking. I didn't worry about backward compatibility for input parms since it wasn't working anyway. It only takes server name and level now. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=801727&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2003-09-05 06:55:40
|
Bugs item #799063, was opened at 2003-09-02 10:40 Message generated for change (Comment added) made by mattkirst You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=799063&group_id=78018 Category: com Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthias Kirst (mattkirst) Assigned to: Nobody/Anonymous (nobody) Summary: Registering Python COM Server component category crashes Initial Comment: When registering the Python COM Server component category, Python crashes with Dr.Watson. The crash happens when executing the last line in the function: def RegisterPyComCategory(): """ Register the Python COM Server component category. """ regCat = _cat_registrar() regCat.RegisterCategories( [ (CATID_PythonCOMServer, 0x0409, "Python COM Server") ] ) ---------------------------------------------------------------------- >Comment By: Matthias Kirst (mattkirst) Date: 2003-09-05 06:55 Message: Logged In: YES user_id=397984 Bingo! The installation crashed as well with 154 (NT/XP). Since I experienced my crash with a customized Python/PythonCOM version I did not register the scripting engine -> the crash occured when I registered my first COM component. Since win32all does not unregister the Python COM Server component category when uninstalling you succeed when preinstalling an older version of win32all. ---------------------------------------------------------------------- Comment By: John J Smith (johnjsmith) Date: 2003-09-04 18:47 Message: Logged In: YES user_id=830565 Is this related to bug #784962 (Installation crash in recent win32all's)? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=799063&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2003-09-04 18:48:45
|
Bugs item #799063, was opened at 2003-09-02 10:40 Message generated for change (Comment added) made by johnjsmith You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=799063&group_id=78018 Category: com Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matthias Kirst (mattkirst) Assigned to: Nobody/Anonymous (nobody) Summary: Registering Python COM Server component category crashes Initial Comment: When registering the Python COM Server component category, Python crashes with Dr.Watson. The crash happens when executing the last line in the function: def RegisterPyComCategory(): """ Register the Python COM Server component category. """ regCat = _cat_registrar() regCat.RegisterCategories( [ (CATID_PythonCOMServer, 0x0409, "Python COM Server") ] ) ---------------------------------------------------------------------- Comment By: John J Smith (johnjsmith) Date: 2003-09-04 18:47 Message: Logged In: YES user_id=830565 Is this related to bug #784962 (Installation crash in recent win32all's)? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=799063&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2003-09-04 05:08:39
|
Bugs item #753033, was opened at 2003-06-12 06:36 Message generated for change (Comment added) made by dubnerm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=753033&group_id=78018 Category: win32 Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Dubner (dubnerm) Assigned to: Mark Hammond (mhammond) Summary: Help misses functions Initial Comment: Help for win32all-152 misses entries for AppendMenu, InsertMenu, InsertMenuItem possibly for other items too... somebody should check ---------------------------------------------------------------------- >Comment By: Michael Dubner (dubnerm) Date: 2003-09-04 09:08 Message: Logged In: YES user_id=39274 Just a reminder: for version 155 problem is still here. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=753033&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2003-09-04 05:04:17
|
Bugs item #753033, was opened at 2003-06-12 06:36 Message generated for change (Settings changed) made by dubnerm You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=753033&group_id=78018 Category: win32 Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Dubner (dubnerm) >Assigned to: Mark Hammond (mhammond) Summary: Help misses functions Initial Comment: Help for win32all-152 misses entries for AppendMenu, InsertMenu, InsertMenuItem possibly for other items too... somebody should check ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=753033&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2003-09-04 04:12:53
|
Patches item #800206, was opened at 2003-09-03 23:12 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=800206&group_id=78018 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Roger Upole (rupole) Assigned to: Nobody/Anonymous (nobody) Summary: fix for crash in PyIProperyStorage:Stat() Initial Comment: It was trying to treat a format id as a long. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=800206&group_id=78018 |
2 messages has been excluded from this view by a project administrator.
