pywin32-bugs Mailing List for Python for Windows Extensions (Page 119)
OLD project page for the Python extensions for Windows
Brought to you by:
mhammond
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-04-22 19:17:28
|
Patches item #725797, was opened at 2003-04-22 21:17 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=725797&group_id=78018 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thomas Heller (theller) Assigned to: Nobody/Anonymous (nobody) Summary: _exe_name_ for services does not (always) work Initial Comment: Under certain conditions, win32api.SearchPath() is called on a service's _exe_name_. This returns a tuple, not a string. Patch attached. And a feature request for _exe_args_! Can supply a patch if needed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=725797&group_id=78018 |
From: SourceForge.net <no...@so...> - 2003-04-22 11:58:15
|
Patches item #725608, was opened at 2003-04-22 11:58 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=725608&group_id=78018 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Marc ENGEL (marcengel) Assigned to: Nobody/Anonymous (nobody) Summary: Modification made to have enum working under .NET Initial Comment: In order to get enum working with .NET wrapped enum, I had to modify the code of __getitem__ from class CDispatch in dynamic.py. Indeed the "for" loop tries to access all index until it gets an IndexError but when trying to access an non-existent index under .NET, I got this error from mscorlib: (-2147352567, "Une exception s'est produite.", (0, 'mscorlib', "L'index \xe9tait hors limites. Il ne doit pas \xeatre n\xe9gatif et doit \xeatre inf\xe9rieur \xe0 la taille de la collection.\r\nNom du param\xe8tre\xa0: index", None, 0, -2146233086), None) The error message translated is: "index out of bounds. It must not be negative or less than the collection size. Parameter name: index" In order to get the for loop working, I modified the code to raise an IndexError and it works. Hope it will help ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=725608&group_id=78018 |
From: SourceForge.net <no...@so...> - 2003-04-22 02:13:27
|
Bugs item #725375, was opened at 2003-04-22 10:31 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=725375&group_id=78018 Category: win32 Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Gary Herron (herron) Assigned to: Nobody/Anonymous (nobody) Summary: Installing a service gets interactive mode wrong. Initial Comment: The procedure "InstallService" in "win32serviceutil.py" has a parameter "bRunInteractive" meant to allow an installed service the ability to interact with the screen. This parameter is not handled correctly, and moreover, there is no commandline access to the parameter. At the very least, a true value for the parameter should cause SERVICE_INTERACTIVE_PROCES to be or'ed into the *service* type not the *startup* type (as the current code does). This can be found in MS's documentation of CreateService. I've included a patch (on the version of win32serviceutil.py in Python2.2) which does the above as well as adds a simular parameter to ChangeServiceConfig. Moreover it introcudes a new command line arg --interactive which allows a command line option to set the flag on both service installation and update. I hope you find it useful. Gary Herron ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2003-04-22 12:13 Message: Logged In: YES user_id=14198 Checked in - thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=725375&group_id=78018 |
From: SourceForge.net <no...@so...> - 2003-04-22 00:31:45
|
Bugs item #725375, was opened at 2003-04-22 00:31 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=725375&group_id=78018 Category: win32 Group: None Status: Open Resolution: None Priority: 5 Submitted By: Gary Herron (herron) Assigned to: Nobody/Anonymous (nobody) Summary: Installing a service gets interactive mode wrong. Initial Comment: The procedure "InstallService" in "win32serviceutil.py" has a parameter "bRunInteractive" meant to allow an installed service the ability to interact with the screen. This parameter is not handled correctly, and moreover, there is no commandline access to the parameter. At the very least, a true value for the parameter should cause SERVICE_INTERACTIVE_PROCES to be or'ed into the *service* type not the *startup* type (as the current code does). This can be found in MS's documentation of CreateService. I've included a patch (on the version of win32serviceutil.py in Python2.2) which does the above as well as adds a simular parameter to ChangeServiceConfig. Moreover it introcudes a new command line arg --interactive which allows a command line option to set the flag on both service installation and update. I hope you find it useful. Gary Herron ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=725375&group_id=78018 |
From: SourceForge.net <no...@so...> - 2003-04-21 10:35:52
|
Bugs item #723887, was opened at 2003-04-19 06:51 Message generated for change (Settings changed) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=723887&group_id=78018 Category: com Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: bob gailer (ramrom) Assigned to: Nobody/Anonymous (nobody) Summary: makepy crash on protected typelib registry key Initial Comment: If a typelib registry key is protected from the logged on user, makepy aborts: File "E:\Python22\lib\site-packages\win32com\client\selecttlb.py", line 68, in EnumTlbs key2 = win32api.RegOpenKey(win32con.HKEY_CLASSES_ROOT, "Typelib\%s" % (iid)) error: (5, 'RegOpenKeyEx', 'Access is denied.') This happened on Win NT 4 logged on as administrator. A simple modification to the code to ignore such keys will allow the user to get a list of permitted keys instead of aborting. See attachment. I added lines 75 (try) and 118 (except) to ignore protected keys ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2003-04-21 20:35 Message: Logged In: YES user_id=14198 Thanks - I checked the fix in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=723887&group_id=78018 |
From: SourceForge.net <no...@so...> - 2003-04-21 10:35:35
|
Bugs item #723887, was opened at 2003-04-19 06:51 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=723887&group_id=78018 Category: com Group: None Status: Open Resolution: None Priority: 5 Submitted By: bob gailer (ramrom) Assigned to: Nobody/Anonymous (nobody) Summary: makepy crash on protected typelib registry key Initial Comment: If a typelib registry key is protected from the logged on user, makepy aborts: File "E:\Python22\lib\site-packages\win32com\client\selecttlb.py", line 68, in EnumTlbs key2 = win32api.RegOpenKey(win32con.HKEY_CLASSES_ROOT, "Typelib\%s" % (iid)) error: (5, 'RegOpenKeyEx', 'Access is denied.') This happened on Win NT 4 logged on as administrator. A simple modification to the code to ignore such keys will allow the user to get a list of permitted keys instead of aborting. See attachment. I added lines 75 (try) and 118 (except) to ignore protected keys ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2003-04-21 20:35 Message: Logged In: YES user_id=14198 Thanks - I checked the fix in. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=723887&group_id=78018 |
From: SourceForge.net <no...@so...> - 2003-04-20 04:01:40
|
Bugs item #723837, was opened at 2003-04-19 05:03 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=723837&group_id=78018 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Orendorff (jorend) Assigned to: Mark Hammond (mhammond) Summary: PyHANDLE destructor triggers a SystemError Initial Comment: This code is in PyHANDLE.cpp: /*static*/ void PyHANDLE::deallocFunc(PyObject *ob) { // Call virtual method Close ((PyHANDLE *)ob)->Close(); PyErr_Clear(); // can not leave pending exceptions in destructors. delete (PyHANDLE *)ob; } If this is called because an unrelated exception occurred, it incorrectly clears the exception. For example, suppose I have Python code that calls a Python function f1(). This function successfully creates a PyHANDLE, stores it in a local varaible, and then raises an unrelated exception. The caller, f2(), catches the exception. At this point, the PyHANDLE still exists because the traceback object has a reference to it (indirectly). Now suppose f2() throws an exception. The previous traceback object is now released (replaced by the new traceback). The PyHANDLE object is decref'd and freed. PyHANDLE::deallocFunc() is called. The exception that f2() threw is now cleared. This results in a SystemError. The attached test case reproduces it. I think it should be if (!((PyHANDLE *)ob)->Close()) PyErr_Clear(); but I'm not sure. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2003-04-20 14:01 Message: Logged In: YES user_id=14198 This is a little nasty. I think the PyErr_Clear call is a hack, but Python prints a warning in some cases. The semantics for exceptions during object destruction are hard, and I will need to look into things a little more - but in the meantime, please see the new win32\tests\handles.py - your test case with some additions. These additions exercise some of these other cases, which will hopefully allow you to see my dilemma. I've been meaning to move to unittest, and this gave me the push I needed - thanks! I will probably move some of the other "demos" code into tests where it belongs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=723837&group_id=78018 |
From: SourceForge.net <no...@so...> - 2003-04-18 20:54:11
|
Bugs item #723888, was opened at 2003-04-18 14:54 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=723888&group_id=78018 Category: pythonwin Group: None Status: Open Resolution: None Priority: 5 Submitted By: bob gailer (ramrom) Assigned to: Nobody/Anonymous (nobody) Summary: Keep Tabs not working Initial Comment: View -> Options -> Tabs & Whitespace. Click Keep Tabs. Type a tab or click enter to start an indented line - editor puts spaces in instead of tabs. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=723888&group_id=78018 |
From: SourceForge.net <no...@so...> - 2003-04-18 20:51:57
|
Bugs item #723887, was opened at 2003-04-18 14:51 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=723887&group_id=78018 Category: com Group: None Status: Open Resolution: None Priority: 5 Submitted By: bob gailer (ramrom) Assigned to: Nobody/Anonymous (nobody) Summary: makepy crash on protected typelib registry key Initial Comment: If a typelib registry key is protected from the logged on user, makepy aborts: File "E:\Python22\lib\site-packages\win32com\client\selecttlb.py", line 68, in EnumTlbs key2 = win32api.RegOpenKey(win32con.HKEY_CLASSES_ROOT, "Typelib\%s" % (iid)) error: (5, 'RegOpenKeyEx', 'Access is denied.') This happened on Win NT 4 logged on as administrator. A simple modification to the code to ignore such keys will allow the user to get a list of permitted keys instead of aborting. See attachment. I added lines 75 (try) and 118 (except) to ignore protected keys ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=723887&group_id=78018 |
From: SourceForge.net <no...@so...> - 2003-04-18 19:03:59
|
Bugs item #723837, was opened at 2003-04-18 19:03 Message generated for change (Settings changed) made by jorend You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=723837&group_id=78018 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Orendorff (jorend) >Assigned to: Mark Hammond (mhammond) Summary: PyHANDLE destructor triggers a SystemError Initial Comment: This code is in PyHANDLE.cpp: /*static*/ void PyHANDLE::deallocFunc(PyObject *ob) { // Call virtual method Close ((PyHANDLE *)ob)->Close(); PyErr_Clear(); // can not leave pending exceptions in destructors. delete (PyHANDLE *)ob; } If this is called because an unrelated exception occurred, it incorrectly clears the exception. For example, suppose I have Python code that calls a Python function f1(). This function successfully creates a PyHANDLE, stores it in a local varaible, and then raises an unrelated exception. The caller, f2(), catches the exception. At this point, the PyHANDLE still exists because the traceback object has a reference to it (indirectly). Now suppose f2() throws an exception. The previous traceback object is now released (replaced by the new traceback). The PyHANDLE object is decref'd and freed. PyHANDLE::deallocFunc() is called. The exception that f2() threw is now cleared. This results in a SystemError. The attached test case reproduces it. I think it should be if (!((PyHANDLE *)ob)->Close()) PyErr_Clear(); but I'm not sure. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=723837&group_id=78018 |
From: SourceForge.net <no...@so...> - 2003-04-18 19:03:14
|
Bugs item #723837, was opened at 2003-04-18 19:03 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=723837&group_id=78018 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason Orendorff (jorend) Assigned to: Nobody/Anonymous (nobody) Summary: PyHANDLE destructor triggers a SystemError Initial Comment: This code is in PyHANDLE.cpp: /*static*/ void PyHANDLE::deallocFunc(PyObject *ob) { // Call virtual method Close ((PyHANDLE *)ob)->Close(); PyErr_Clear(); // can not leave pending exceptions in destructors. delete (PyHANDLE *)ob; } If this is called because an unrelated exception occurred, it incorrectly clears the exception. For example, suppose I have Python code that calls a Python function f1(). This function successfully creates a PyHANDLE, stores it in a local varaible, and then raises an unrelated exception. The caller, f2(), catches the exception. At this point, the PyHANDLE still exists because the traceback object has a reference to it (indirectly). Now suppose f2() throws an exception. The previous traceback object is now released (replaced by the new traceback). The PyHANDLE object is decref'd and freed. PyHANDLE::deallocFunc() is called. The exception that f2() threw is now cleared. This results in a SystemError. The attached test case reproduces it. I think it should be if (!((PyHANDLE *)ob)->Close()) PyErr_Clear(); but I'm not sure. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=723837&group_id=78018 |
From: SourceForge.net <no...@so...> - 2003-04-17 00:05:04
|
Feature Requests item #722847, was opened at 2003-04-17 00:05 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=722847&group_id=78018 Category: pythonwin Group: None Status: Open Priority: 5 Submitted By: Raphael Alla (khadrin) Assigned to: Nobody/Anonymous (nobody) Summary: installation without administrator rights Initial Comment: On windows XP, the installation fails if the user installing the package is not administrator. This is because the installation tries to modify some keys in the registry which cannot be modified by a normal user. It would be good if the installation could be updated to allow a normal user to install the package (the python package allows this) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=722847&group_id=78018 |
From: SourceForge.net <no...@so...> - 2003-04-16 10:41:49
|
Feature Requests item #722416, was opened at 2003-04-16 20:58 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=722416&group_id=78018 Category: win32 Group: None Status: Open Priority: 5 Submitted By: Mark Hammond (mhammond) Assigned to: Nobody/Anonymous (nobody) Summary: GetUserNameEx Initial Comment: GetUserNameEx() would make life easier in an ADSI environment. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=722416&group_id=78018 |
From: SourceForge.net <no...@so...> - 2003-04-16 10:40:21
|
Bugs item #722414, was opened at 2003-04-16 20:57 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=722414&group_id=78018 Category: win32 Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mark Hammond (mhammond) Assigned to: Mark Hammond (mhammond) Summary: win32api etc should alias code moved to the core Initial Comment: win32pipe.popen and win32api.Reg* should be removed from the source-tree, and dynamically load the versions in Python itself. This way bugs fixed in the core are reflected here magically. Eg, see https://sourceforge.net/tracker/index.php?func=detail&aid=722413&group_id=5470&atid=105470 I would rather spend the effort aliasing _winreg than duplicating the fix in win32api. However, this will almost certainly mean win32api.error should subclass os.WindowsError. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=722414&group_id=78018 |
From: SourceForge.net <no...@so...> - 2003-04-16 10:34:51
|
Bugs item #722412, was opened at 2003-04-16 20:51 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=722412&group_id=78018 Category: com Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mark Hammond (mhammond) Assigned to: Nobody/Anonymous (nobody) Summary: ASP Response.End is flakey Initial Comment: From email: Anyone else seeing this? PythonWin 2.1.1 / win32all 1.5.1 / Win 2k Server *** Script 1 *** <%@LANGUAGE="Python"%> Before End <% Response.End() %> After End *** Output *** Before End After End *** Script 2 *** <%@LANGUAGE="Python"%> Before End <% Response.end() %> After End *** Output *** Before End *** Script 3 *** <%@LANGUAGE="Python"%> <% Response.end() %> After End *** Output *** HTTP/1.1 500 Server Error -- Yes, I too have found it to be the case in the past (haven't checked recently) that Response.End() does not in fact end the response in python under asp. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=722412&group_id=78018 |
From: SourceForge.net <no...@so...> - 2003-04-15 20:04:39
|
Bugs item #722082, was opened at 2003-04-15 12:22 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=722082&group_id=78018 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Nobody/Anonymous (nobody) Summary: Potential crash in win32clipboard.SetClipboardData Initial Comment: Consider the following: Python 2.2.2 (#37, Oct 14 2002, 17:02:34) [MSC 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> class crasher(object): pass ... >>> obj = crasher() >>> import win32clipboard >>> win32clipboard.OpenClipboard() >>> win32clipboard.EmptyClipboard() >>> win32clipboard.SetClipboardData(0, obj) (Python Crashes -- same thing happens under 2.3a2). The problem appears to be the assumption (in py_set_clipboard_data) that a non-NULL tp_as_buffer implies a valid bf_getreadbuffer. This is not true; in particular, tp_as_buffer is always non-NULL for new-style classes. I'd suggest using PyObject_AsReadBuffer instead of directly manipulating tp_as_buffer. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=722082&group_id=78018 |
From: SourceForge.net <no...@so...> - 2003-04-15 09:28:16
|
Bugs item #721695, was opened at 2003-04-15 19:45 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=721695&group_id=78018 Category: pythonwin Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mark Hammond (mhammond) Assigned to: Mark Hammond (mhammond) Summary: pythonwin may restore to off screen Initial Comment: In some strange cases (including dual monitor setups), Pythonwin may restore a position that is wholly or partially off the screen. It should handle this better. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=721695&group_id=78018 |
From: SourceForge.net <no...@so...> - 2003-04-15 06:53:52
|
Bugs item #721636, was opened at 2003-04-15 00:10 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=721636&group_id=78018 Category: pythonwin Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matt R Hall (mhcomputing) Assigned to: Nobody/Anonymous (nobody) Summary: Naming Convention Inconsistent for Installation Log File Initial Comment: Summary: A minor typographical / naming convention error removal of the Win32 extensions. Problem: The installer mistakenly copies the installation log into Python23\Lib\site-packages\W32INST.LOG instead of INSTALL.LOG which causes it to fail when attempting to uninstall the Win32 extensions. Potential Fix: Either the location of the install log or the call to the uninstaller placed in the registry should be modified to correct this, or potentially both. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=721636&group_id=78018 |
From: SourceForge.net <no...@so...> - 2003-04-15 06:50:30
|
Bugs item #721634, was opened at 2003-04-15 00:07 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=721634&group_id=78018 Category: pythonwin Group: None Status: Open Resolution: None Priority: 5 Submitted By: Matt R Hall (mhcomputing) Assigned to: Nobody/Anonymous (nobody) Summary: Defective LFN Handling in Version 1.53 Installer Initial Comment: Summary: Using the win32all-153.exe installer on Windows XP SP1 to install the extensions when the base version of Python resides in a directory path containing spaces results in an Access Violation. Testing Methodology / Error Reproduction: The installer crashed while attempting to register some of the COM components it installs when I attempted to use the installer to add the Win32 components when Python was installed into "C:\Program Files\python23" but functioned perfectly when Python was installed in "C:\python23". Possible Cause: I have observed that various Windows installer utilites perform improper conversion between LFN and non-LFN versions of file and path names used during installation. Perhaps a defective filename string causes the COM component registration procedures to fail. I would first attempt installing patches and updates for the installer generation utility to see if the errors in its LFN handling improve. It can with a high surety be stated that said upgrade would likely result in a resolution of the issue. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=721634&group_id=78018 |