pywin32-bugs Mailing List for Python for Windows Extensions (Page 73)
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...> - 2006-07-28 13:44:02
|
Feature Requests item #1530394, was opened at 2006-07-28 07:44 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=1530394&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: win32 Group: None Status: Open Resolution: None Priority: 5 Submitted By: Jason R. Coombs (jaraco) Assigned to: Nobody/Anonymous (nobody) Summary: 64-bit platform support Initial Comment: I realize this project is called pywin32. Nevertheless, it seems the appropriate place to suggest a port to 64-bit platforms, particularly the x64 platform, as it is very close to the 32-bit equivalent. I searched around and didn't find any discussion on this topic. I'm willing to assist with the effort. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1530394&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-07-24 07:11:57
|
Feature Requests item #1527583, was opened at 2006-07-24 17:11 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=1527583&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: win32 Group: None Status: Open Resolution: None Priority: 5 Submitted By: david arnold (dja) Assigned to: Nobody/Anonymous (nobody) Summary: Add support for WSAEnumNetworkEvents Initial Comment: WSAEnumNetworkEvents is used to determine the state of a socket after it has signaled an Event to indicate that its state has changed. Its useful for integrating sockets with other objects (handles, events, etc) in a main loop. Currently, WSAEventSelect is supported, as is WSAAsyncSelect (which is used to direct state change notifications to a Window), but not WSAEnumNetworkEvents. It'd be great if this could be added ... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1527583&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-07-15 20:49:29
|
Bugs item #1517894, was opened at 2006-07-05 22:05 Message generated for change (Comment added) made by timtucker You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1517894&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Greg Hazel (ghazel) Assigned to: Nobody/Anonymous (nobody) Summary: 208 python 2.5 import issues Initial Comment: C:\Python25\lib\site-packages\win32 \lib\pywintypes.py:64: RuntimeWarning: Python C API version mismatch for module _win32sysloader: This Python has API version 1013, module _win32sysloader has version 1012. import _win32sysloader C:\Python25\lib\site-packages\win32 \lib\pywintypes.py:98: RuntimeWarning: Python C API version mismatch for module pywintypes: This Python has API version 1013, module pywintypes has version 1012. ('.dll', 'rb', imp.C_EXTENSION)) C:\project\file.py:30: RuntimeWarning: Python C API version mismatch for module win32a pi: This Python has API version 1013, module win32api has version 1012. import win32api C:\project\file.py:31: RuntimeWarning: Python C API version mismatch for module win32f ile: This Python has API version 1013, module win32file has version 1012. import win32file C:\WINDOWS\system32\pywintypes25.dll:98: RuntimeWarning: Python C API version mi smatch for module pythoncom: This Python has API version 1013, module pythoncom has version 1012. ââ¶âïâ¦$à âuâÃöâwâ²Â Ãöâwâ²Ã¯Ldë C:\WINDOWS\system32\pywintypes25.dll:98: RuntimeWarning: Python C API version mi smatch for module pythoncom.__univgw: This Python has API version 1013, module p ythoncom.__univgw has version 1012. ââ¶âïâ¦$à âuâÃöâwâ²Â Ãöâwâ²Ã¯Ldë C:\Python25\lib\site- packages\win32com\__init__.py:89: ImportWarning: Not import ing directory 'C:\Python25\lib\site- packages\win32com\gen_py': missing __init__. py import win32com.gen_py ---------------------------------------------------------------------- Comment By: Timothy Tucker (timtucker) Date: 2006-07-15 15:49 Message: Logged In: YES user_id=966761 Downloaded the 208 source and built it myself -- seems to work fine with 2.5 beta 2. ---------------------------------------------------------------------- Comment By: Timothy Tucker (timtucker) Date: 2006-07-07 10:35 Message: Logged In: YES user_id=966761 Having the same problem here -- was pywin32 built with the previous build of 2.5? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1517894&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-07-12 12:41:59
|
Patches item #1305342, was opened at 2005-09-27 09:57 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1305342&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Michael Dubner (dubnerm) Assigned to: Mark Hammond (mhammond) Summary: LocalService support Initial Comment: With this module you can create out-of-process COM server in NT Service. Usage: class MyCOMObject1: _reg_clsid_ = ... _reg_... class MyCOMService(localservice.LocalCOMService): _svc_com_servers_ = [MyCOMObject1, ...] if __name__=='__main__': localservice.ProcessCommandLine(MyCOMService) ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2006-07-12 22:41 Message: Logged In: YES user_id=14198 Just checking if this is still alive... ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-10-11 11:53 Message: Logged In: YES user_id=14198 Thanks Michael. A few comments: * Could you please change 'Granted for inclusion in pywin32 (https://sourceforge.net/projects/pywin32/).' to something like 'Released under the terms of the pywin32 license' or something - that makes it clear that people who are currently free to redistribute pywin32 components are also free to redistribute this. * Is there any reason we can't leverage the existing service command-line support? It seems a shame to clone so much code. I'd be willing to consider changing win32serviceutil so we can take advantage of customized command-line options etc. The 'optparse' module is a better choice than getopt these days. * Its not clear why 'serve' is needed, and there aren't any comments for it. * Why are InitHook() functions rather than just class members? Thanks, Mark ---------------------------------------------------------------------- Comment By: Michael Dubner (dubnerm) Date: 2005-09-27 18:22 Message: Logged In: YES user_id=39274 Sorry - forgot to click on checkbox ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2005-09-27 11:59 Message: Logged In: YES user_id=14198 Did you mean to include an attachment? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1305342&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-07-12 12:39:52
|
Patches item #1464113, was opened at 2006-04-04 21:13 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1464113&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 1 Submitted By: Dana Robinson (derobins) Assigned to: Nobody/Anonymous (nobody) Summary: Usage changes and directory creation Initial Comment: This patch updates the usage string so that it corresponds to the getopt processing. I also clarified and slightly reformatted the text so that it's easier to read. For example, all lines are less than 80 characters and the arguments are explained in the order that they appear. I also added a few lines of code that will create missing directories in the output file's path. These can easily be removed if such behavior is not desired. D ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2006-07-12 22:39 Message: Logged In: YES user_id=14198 Thanks! Checking in makepy.py; new revision: 1.22; previous revision: 1.21 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1464113&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-07-12 12:35:27
|
Feature Requests item #1481844, was opened at 2006-05-04 23:48 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1481844&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: win32 Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: wrstl prmpft (wrstlprmpft) Assigned to: Nobody/Anonymous (nobody) Summary: multi monitor, dualview, extended desktop support functions Initial Comment: A request for adding functions related to multiple monitors, dualview (extended desktop), to win32api. (see also posts on the mailing list: http://mail.python.org/pipermail/python-win32/2006-May/ 004634.html and http://mail.python.org/pipermail/python-win32/2006-May/ 004637.html) The needed GDI functions (WinXP only I think) are: - ChangeDisplaySettingsEx - EnumDisplaySettingsEx - EnumDisplayDevices - EnumDisplayMonitors (see http://msdn.microsoft.com/library/default.asp? url=/library/en-us/gdi/monitor_4zak.asp ) these would be added to win32apimodule.cpp cheers, stefan ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2006-07-12 22:35 Message: Logged In: YES user_id=14198 Thanks Roger! This should be in the soon-to-be-release pywin32-209. ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2006-05-26 13:36 Message: Logged In: YES user_id=771074 Just checked in the new functions in win32api, with a few changes. They take keyword args now, and the DISPLAY_DEVICE type is exported by win32api itself rather than pywintypes. Roger ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2006-05-13 22:49 Message: Logged In: YES user_id=771074 I've started integrating this. Changes to win32con.py and PyDEVMODE have been committed, but checkin messages are still broken. However, it looks like viewcvs is almost real-time now. The issue with the longs is actually a python bug. The code in structmember.c insists that you give it an int, but at the very least it could give a better error msg. Probably a holdover from the whole int/long unification thing. Mark, would you rather have the new PyDISPLAY_DEVICE just in win32api itself, to avoid the problem where sometimes an older pywintypes is still in use by accident ? Of course, it should be less of a problem now that everything is version-stamped. Roger ---------------------------------------------------------------------- Comment By: wrstl prmpft (wrstlprmpft) Date: 2006-05-11 20:42 Message: Logged In: YES user_id=801589 I scratched my itch. Attached is a diff and a new file: PyDISPLAY_DEVICE.cpp I added EnumDisplayDevices and ChangeDisplaySettingsEx, as well as the DISPLAY_DEVICE structure. It works for me here on WinXP. The msdn docs say that the functions are available in Win98, interestingly for DISPLAY_DEVICE, it says that its Win2000 only. ??? I am WinXP only here. I added missing constants to win32con.py, I don't think this can harm anyone. But the cpp files might need some #if ... somewhere. cheers, stefan PS: I found that the DEVMODE structure gives Position_x and Position_y values as longs, but when setting these values it only accepts ints. Why is this? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1481844&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-07-12 12:31:10
|
Patches item #1495095, was opened at 2006-05-26 04:26 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1495095&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: kxroberto (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: timer.pyd Initial Comment: patch in attachment: I had some rare problems with disapearing handlers and frame-refcount problem (compare bug# 1489690) on self-killing timer handlers. -robert ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2006-07-12 22:31 Message: Logged In: YES user_id=14198 All apart from KillTimer checked into: Checking in timermodule.cpp; new revision: 1.4; previous revision: 1.3 ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2006-07-12 10:42 Message: Logged In: YES user_id=14198 Most of that patch looks good - can you please explain why the KillTimer call was removed? I don't understand your comment about the possible race. Are you seeing KillTimer call back into Python code? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1495095&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-07-12 00:42:44
|
Patches item #1495095, was opened at 2006-05-26 04:26 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1495095&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: kxroberto (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: timer.pyd Initial Comment: patch in attachment: I had some rare problems with disapearing handlers and frame-refcount problem (compare bug# 1489690) on self-killing timer handlers. -robert ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2006-07-12 10:42 Message: Logged In: YES user_id=14198 Most of that patch looks good - can you please explain why the KillTimer call was removed? I don't understand your comment about the possible race. Are you seeing KillTimer call back into Python code? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1495095&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-07-12 00:41:51
|
Bugs item #1414160, was opened at 2006-01-25 11:24 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1414160&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: win32 Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Greg Hazel (ghazel) Assigned to: Nobody/Anonymous (nobody) Summary: DDE sets off DEP (in demos and pythonwin too) Initial Comment: running C:\Python24\Lib\site-packages\win32 \Demos\dde\ddeserver.py causes DEP to go off for python. Similarly, DEP is set off for pythonwin. If you disable the DDE stuff in pythonwin, it does not set off DEP. ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2006-07-12 10:41 Message: Logged In: YES user_id=14198 Should have been fixed in 208 ---------------------------------------------------------------------- Comment By: Greg Hazel (ghazel) Date: 2006-02-03 10:55 Message: Logged In: YES user_id=731668 I found the code that triggers DEP. In pywin32\Pythonwin\stddde.cpp there is a define called _CALLHACK_. If that is commented out DDE does not set off DEP. Judging from the comments surrounding this "hack", I'd guess this is not too much of a surprise. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1414160&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-07-12 00:36:51
|
Bugs item #1489690, was opened at 2006-05-17 02:42 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1489690&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pythonwin Group: None Status: Closed Resolution: Fixed Priority: 7 Submitted By: kxroberto (kxroberto) Assigned to: Mark Hammond (mhammond) Summary: Memory Leak: PyCWnd objects are never freed Initial Comment: Memory leak: PyCWnd objects are never free'd. ( and minor bug: If Window is never CreateWindow'ed + Destroy'Ed, the HookXXX'ed function-objects are also never free'd. Maybe the "Py_INCREF(hookedObject);" in win32cmd.cpp/Line228 (and associated DODECREF) are unnecessary : the Window/Hooklist must hold the hooked method, but not the reverse? ) I post examples in follow up - as sf main post destroys indentation. -robert ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2006-07-12 10:36 Message: Logged In: YES user_id=14198 I also meant to mention: > strange: the refcount of a created Window is always > minimum 2: > >>> sys.getrefcount(w) > 2 This is a feature of getrefcount - the refcount is always 1 more than the real value due to a reference held by the function itself. Eg, try "l=[]; sys.getrefcount(l)" ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2006-07-11 15:19 Message: Logged In: YES user_id=14198 I see how we need to add the extra reference to the method as your patch shows, and I'll check that in. I also worked out that win32ui.CreateWnd() leaked a CWnd object (but *not* the PyObject associated with it). I'll check both changes in and close this bug - if you still think the management of hookedObject is incorrect, please reopen (or open a new one) with more details. Thanks! Checking in win32cmd.cpp; new revision: 1.2; previous revision: 1.1 Checking in win32uimodule.cpp; new revision: 1.32; previous revision: 1.31 Checking in win32virt.cpp; new revision: 1.3; previous revision: 1.2 Checking in win32win.cpp; new revision: 1.10; previous revision: 1.9 ---------------------------------------------------------------------- Comment By: kxroberto (kxroberto) Date: 2006-05-17 06:34 Message: Logged In: YES user_id=972995 The minor bug exposed another really serious bug ( the cause of e.g. http://groups.google.de/group/comp.lang.python/browse_frm/thread/3aaece8b5f4359cb ), which is probably best fixed at the most central spot in Python_do_callback: For example when in Python_check_message Python_callback(method, msg) is done, there is currently no extra INCREF to 'method' done - and currently also nowhere else down that call until it goes into Python code. The Python message handler can now DECREF 'method' (e.g. by another HookMessage or by DestroyWindow or ...) and if no one else holds a ref to method => the executing function looses its own ground!, its frame/closure/cell's => 'SystemError: C:\\\\sf\\\\python\\\\dist23\\\\src\\\\Objects\\\\cellobject.c:22: bad argument to internal function\\n\' The following example shows, that there is only one ref from the current frame to the function, when the installed and running function (itself) is stored in _ : ---- import win32ui,win32con, gc def WmTimerExec(wnd,f): def ON_WM_TIMER(msg): wnd.KillTimer(123) _ = wnd.HookMessage(None,win32con.WM_TIMER) print gc.get_referrers(_) f() wnd.HookMessage(ON_WM_TIMER,win32con.WM_TIMER) wnd.SetTimer(123, 50) def f(): print "f()" WmTimerExec(win32ui.GetMainFrame(), f) ---- => if the storage in _ is not done, the closure and cells are recycled while the function is still executing! Maybe the following patch is necessary - also in attchment ( or alternatively many such INCREF's whenever a 'method' is used from a xxx_hook_list) : --- win32uimodule.cpp.orig 2006-01-10 14:38:00.000000000 +0100 +++ win32uimodule.cpp 2006-05-16 22:22:24.000000000 +0200 @@ -773,8 +773,11 @@ PyObject *newarglst = Py_BuildValue("(OO)",themeth,thearglst); result = gui_call_object( pCallbackCaller, newarglst ); DODECREF(newarglst); - } else + } else { + Py_XINCREF(themeth); result = gui_call_object( themeth, thearglst ); + Py_XDECREF(themeth); + } DODECREF(thearglst); if (result==NULL) { TRACE("Python_do_callback: callback failed with exception\n"); ============= ( this doesn't solve the other leak problem; therfore most probably the Py_INCREF(hookedObject) / DODECREF.. has to be removed ) ---------------------------------------------------------------------- Comment By: kxroberto (kxroberto) Date: 2006-05-17 02:46 Message: Logged In: YES user_id=972995 The bug manifests in long running win32ui apps and can be made visible: The memory consumption goes infinitely up doing this (both - with and without .CreateWindow/.DestroyWindow called : >>> for i in range(10000): ... w=win32ui.CreateWnd() ... #w.CreateWindow(None,"wef",wc.WS_OVERLAPPEDWINDOW,(0,0,100,100),win32ui.GetMainFrame(),1111) ... #w.DestroyWindow() ... strange: the refcount of a created Window is always minimum 2: >>> sys.getrefcount(w) 2 >>> -robert ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1489690&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-07-11 05:20:28
|
Bugs item #1512715, was opened at 2006-06-26 23:24 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1512715&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pythonwin Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: kxroberto (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: CVirtualHelper::call / do_call double DODECREF Bug ? Initial Comment: (last seen in 207/208) For example BOOL CVirtualHelper::call(const MSG *msg) does BOOL ret = do_call(arglst); DODECREF(arglst); // my reference. but BOOL CVirtualHelper::do_call(PyObject *args) also does PyObject *result = gui_call_object(handler,args); DODECREF(args); Seems this explains a couple of OS-level crashes and sudden disappearance of objects here (mainly on dual cores), where the virtual PyCWnd.PreTranslateMessage is used. But attention! Most of the CVirtualHelper::call's on the other side rely on the DODECREF(args) in do_call - e.g.: the "wrong" ones doing an extra DODECREF seem to be only BOOL CVirtualHelper::call(const MSG *msg) and BOOL CVirtualHelper::call(UINT nID, int nCode, void* pExtra, AFX_CMDHANDLERINFO*pHandlerInfo) ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2006-07-11 15:20 Message: Logged In: YES user_id=14198 Yeah - I can see how that is happening - thanks! I've checked it in as part of bug 1489690 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1512715&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-07-11 05:19:26
|
Bugs item #1489690, was opened at 2006-05-17 02:42 Message generated for change (Comment added) made by mhammond You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1489690&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pythonwin Group: None >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: kxroberto (kxroberto) >Assigned to: Mark Hammond (mhammond) Summary: Memory Leak: PyCWnd objects are never freed Initial Comment: Memory leak: PyCWnd objects are never free'd. ( and minor bug: If Window is never CreateWindow'ed + Destroy'Ed, the HookXXX'ed function-objects are also never free'd. Maybe the "Py_INCREF(hookedObject);" in win32cmd.cpp/Line228 (and associated DODECREF) are unnecessary : the Window/Hooklist must hold the hooked method, but not the reverse? ) I post examples in follow up - as sf main post destroys indentation. -robert ---------------------------------------------------------------------- >Comment By: Mark Hammond (mhammond) Date: 2006-07-11 15:19 Message: Logged In: YES user_id=14198 I see how we need to add the extra reference to the method as your patch shows, and I'll check that in. I also worked out that win32ui.CreateWnd() leaked a CWnd object (but *not* the PyObject associated with it). I'll check both changes in and close this bug - if you still think the management of hookedObject is incorrect, please reopen (or open a new one) with more details. Thanks! Checking in win32cmd.cpp; new revision: 1.2; previous revision: 1.1 Checking in win32uimodule.cpp; new revision: 1.32; previous revision: 1.31 Checking in win32virt.cpp; new revision: 1.3; previous revision: 1.2 Checking in win32win.cpp; new revision: 1.10; previous revision: 1.9 ---------------------------------------------------------------------- Comment By: kxroberto (kxroberto) Date: 2006-05-17 06:34 Message: Logged In: YES user_id=972995 The minor bug exposed another really serious bug ( the cause of e.g. http://groups.google.de/group/comp.lang.python/browse_frm/thread/3aaece8b5f4359cb ), which is probably best fixed at the most central spot in Python_do_callback: For example when in Python_check_message Python_callback(method, msg) is done, there is currently no extra INCREF to 'method' done - and currently also nowhere else down that call until it goes into Python code. The Python message handler can now DECREF 'method' (e.g. by another HookMessage or by DestroyWindow or ...) and if no one else holds a ref to method => the executing function looses its own ground!, its frame/closure/cell's => 'SystemError: C:\\\\sf\\\\python\\\\dist23\\\\src\\\\Objects\\\\cellobject.c:22: bad argument to internal function\\n\' The following example shows, that there is only one ref from the current frame to the function, when the installed and running function (itself) is stored in _ : ---- import win32ui,win32con, gc def WmTimerExec(wnd,f): def ON_WM_TIMER(msg): wnd.KillTimer(123) _ = wnd.HookMessage(None,win32con.WM_TIMER) print gc.get_referrers(_) f() wnd.HookMessage(ON_WM_TIMER,win32con.WM_TIMER) wnd.SetTimer(123, 50) def f(): print "f()" WmTimerExec(win32ui.GetMainFrame(), f) ---- => if the storage in _ is not done, the closure and cells are recycled while the function is still executing! Maybe the following patch is necessary - also in attchment ( or alternatively many such INCREF's whenever a 'method' is used from a xxx_hook_list) : --- win32uimodule.cpp.orig 2006-01-10 14:38:00.000000000 +0100 +++ win32uimodule.cpp 2006-05-16 22:22:24.000000000 +0200 @@ -773,8 +773,11 @@ PyObject *newarglst = Py_BuildValue("(OO)",themeth,thearglst); result = gui_call_object( pCallbackCaller, newarglst ); DODECREF(newarglst); - } else + } else { + Py_XINCREF(themeth); result = gui_call_object( themeth, thearglst ); + Py_XDECREF(themeth); + } DODECREF(thearglst); if (result==NULL) { TRACE("Python_do_callback: callback failed with exception\n"); ============= ( this doesn't solve the other leak problem; therfore most probably the Py_INCREF(hookedObject) / DODECREF.. has to be removed ) ---------------------------------------------------------------------- Comment By: kxroberto (kxroberto) Date: 2006-05-17 02:46 Message: Logged In: YES user_id=972995 The bug manifests in long running win32ui apps and can be made visible: The memory consumption goes infinitely up doing this (both - with and without .CreateWindow/.DestroyWindow called : >>> for i in range(10000): ... w=win32ui.CreateWnd() ... #w.CreateWindow(None,"wef",wc.WS_OVERLAPPEDWINDOW,(0,0,100,100),win32ui.GetMainFrame(),1111) ... #w.DestroyWindow() ... strange: the refcount of a created Window is always minimum 2: >>> sys.getrefcount(w) 2 >>> -robert ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1489690&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-07-10 16:29:15
|
Bugs item #1520060, was opened at 2006-07-10 16:21 Message generated for change (Comment added) made by markenglish You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1520060&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pythonwin Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mark E (markenglish) Assigned to: Nobody/Anonymous (nobody) Summary: .py file "IndentationError" corrupts appearance Initial Comment: Opening a .py file like the one attached causes a long stack trace to appear in the Interactive Window (appended at base of this description), and a number of strange characters to appear in the script window (particularly breakpoint characters on every line). The file must have triple quotes at the top, some kind of code construct like a class or a file with a triple- quoted doc string who's second line is indented. For example: ---Start--- """ """ def foo(): """This line is fine This line makes PythonWin unhappy. """ pass ---End--- Removing the triple quotes from the top of the file makes the problem vanish. Removing the second line from the function doc-string also makes the problem vanish. Tried on Windows 2000 installation built from source, and Windows XP SP2 installation installed from ActiveState. ---Error Log--- >>> Traceback (most recent call last): File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\framework\editor\color\colored itor.py", line 51, in OnInitialUpdate SyntEditViewParent.OnInitialUpdate(self) File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\scintilla\view.py", line 210, in OnInitialUpdate self.OnWinIniChange(None) File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\scintilla\view.py", line 223, in OnWinIniChange self.DoConfigChange() File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\framework\editor\color\colored itor.py", line 162, in DoConfigChange ext.set_indentation_params(1) File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\idle\AutoIndent.py", line 140, in set_indentation_params i = self.guess_indent() File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\idle\AutoIndent.py", line 473, in guess_indent opener, indented = IndentSearcher(self.text, self.tabwidth).run() File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\idle\AutoIndent.py", line 546, in run _tokenize.tokenize(self.readline, self.tokeneater) File "C:\Program Files\Python242\Lib\tokenize.py", line 153, in tokenize tokenize_loop(readline, tokeneater) File "C:\Program Files\Python242\Lib\tokenize.py", line 159, in tokenize_loop for token_info in generate_tokens(readline): File "C:\Program Files\Python242\Lib\tokenize.py", line 229, in generate_tokens raise IndentationError( IndentationError: unindent does not match any outer indentation level for line: """ win32ui: OnInitialUpdate() virtual handler (<bound method SyntEditView.OnInitialUpdate of <pywin.framework.editor.color.coloreditor.SyntEditView instance at 0x010F4DA0>>) raised an exception Traceback (most recent call last): File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\framework\editor\color\colored itor.py", line 51, in OnInitialUpdate SyntEditViewParent.OnInitialUpdate(self) File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\scintilla\view.py", line 210, in OnInitialUpdate self.OnWinIniChange(None) File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\scintilla\view.py", line 223, in OnWinIniChange self.DoConfigChange() File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\framework\editor\color\colored itor.py", line 162, in DoConfigChange ext.set_indentation_params(1) File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\idle\AutoIndent.py", line 140, in set_indentation_params i = self.guess_indent() File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\idle\AutoIndent.py", line 473, in guess_indent opener, indented = IndentSearcher(self.text, self.tabwidth).run() File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\idle\AutoIndent.py", line 546, in run _tokenize.tokenize(self.readline, self.tokeneater) File "C:\Program Files\Python242\Lib\tokenize.py", line 153, in tokenize tokenize_loop(readline, tokeneater) File "C:\Program Files\Python242\Lib\tokenize.py", line 159, in tokenize_loop for token_info in generate_tokens(readline): File "C:\Program Files\Python242\Lib\tokenize.py", line 229, in generate_tokens raise IndentationError( IndentationError: unindent does not match any outer indentation level for line: """ win32ui: OnInitialUpdate() virtual handler (<bound method SyntEditView.OnInitialUpdate of <pywin.framework.editor.color.coloreditor.SyntEditView instance at 0x010F4EB8>>) raised an exception ---------------------------------------------------------------------- >Comment By: Mark E (markenglish) Date: 2006-07-10 16:29 Message: Logged In: YES user_id=1174185 To see the problem save a file with the code, then re-open it. ---------------------------------------------------------------------- Comment By: Mark E (markenglish) Date: 2006-07-10 16:28 Message: Logged In: YES user_id=1174185 To see the problem save a file with the code, then re-open it. ---------------------------------------------------------------------- Comment By: Mark E (markenglish) Date: 2006-07-10 16:27 Message: Logged In: YES user_id=1174185 Apparently follow-up posts get to keep indentation, so here's hoping: ---Start--- """ """ def foo(): """This line is fine This line makes PythonWin unhappy. """ pass ---End--- ---------------------------------------------------------------------- Comment By: Mark E (markenglish) Date: 2006-07-10 16:23 Message: Logged In: YES user_id=1174185 Unfortunately the code loses indentation inline in the report, so use the attached indnterr.py file to see the problem ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1520060&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-07-10 16:28:37
|
Bugs item #1520060, was opened at 2006-07-10 16:21 Message generated for change (Comment added) made by markenglish You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1520060&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pythonwin Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mark E (markenglish) Assigned to: Nobody/Anonymous (nobody) Summary: .py file "IndentationError" corrupts appearance Initial Comment: Opening a .py file like the one attached causes a long stack trace to appear in the Interactive Window (appended at base of this description), and a number of strange characters to appear in the script window (particularly breakpoint characters on every line). The file must have triple quotes at the top, some kind of code construct like a class or a file with a triple- quoted doc string who's second line is indented. For example: ---Start--- """ """ def foo(): """This line is fine This line makes PythonWin unhappy. """ pass ---End--- Removing the triple quotes from the top of the file makes the problem vanish. Removing the second line from the function doc-string also makes the problem vanish. Tried on Windows 2000 installation built from source, and Windows XP SP2 installation installed from ActiveState. ---Error Log--- >>> Traceback (most recent call last): File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\framework\editor\color\colored itor.py", line 51, in OnInitialUpdate SyntEditViewParent.OnInitialUpdate(self) File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\scintilla\view.py", line 210, in OnInitialUpdate self.OnWinIniChange(None) File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\scintilla\view.py", line 223, in OnWinIniChange self.DoConfigChange() File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\framework\editor\color\colored itor.py", line 162, in DoConfigChange ext.set_indentation_params(1) File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\idle\AutoIndent.py", line 140, in set_indentation_params i = self.guess_indent() File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\idle\AutoIndent.py", line 473, in guess_indent opener, indented = IndentSearcher(self.text, self.tabwidth).run() File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\idle\AutoIndent.py", line 546, in run _tokenize.tokenize(self.readline, self.tokeneater) File "C:\Program Files\Python242\Lib\tokenize.py", line 153, in tokenize tokenize_loop(readline, tokeneater) File "C:\Program Files\Python242\Lib\tokenize.py", line 159, in tokenize_loop for token_info in generate_tokens(readline): File "C:\Program Files\Python242\Lib\tokenize.py", line 229, in generate_tokens raise IndentationError( IndentationError: unindent does not match any outer indentation level for line: """ win32ui: OnInitialUpdate() virtual handler (<bound method SyntEditView.OnInitialUpdate of <pywin.framework.editor.color.coloreditor.SyntEditView instance at 0x010F4DA0>>) raised an exception Traceback (most recent call last): File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\framework\editor\color\colored itor.py", line 51, in OnInitialUpdate SyntEditViewParent.OnInitialUpdate(self) File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\scintilla\view.py", line 210, in OnInitialUpdate self.OnWinIniChange(None) File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\scintilla\view.py", line 223, in OnWinIniChange self.DoConfigChange() File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\framework\editor\color\colored itor.py", line 162, in DoConfigChange ext.set_indentation_params(1) File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\idle\AutoIndent.py", line 140, in set_indentation_params i = self.guess_indent() File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\idle\AutoIndent.py", line 473, in guess_indent opener, indented = IndentSearcher(self.text, self.tabwidth).run() File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\idle\AutoIndent.py", line 546, in run _tokenize.tokenize(self.readline, self.tokeneater) File "C:\Program Files\Python242\Lib\tokenize.py", line 153, in tokenize tokenize_loop(readline, tokeneater) File "C:\Program Files\Python242\Lib\tokenize.py", line 159, in tokenize_loop for token_info in generate_tokens(readline): File "C:\Program Files\Python242\Lib\tokenize.py", line 229, in generate_tokens raise IndentationError( IndentationError: unindent does not match any outer indentation level for line: """ win32ui: OnInitialUpdate() virtual handler (<bound method SyntEditView.OnInitialUpdate of <pywin.framework.editor.color.coloreditor.SyntEditView instance at 0x010F4EB8>>) raised an exception ---------------------------------------------------------------------- >Comment By: Mark E (markenglish) Date: 2006-07-10 16:28 Message: Logged In: YES user_id=1174185 To see the problem save a file with the code, then re-open it. ---------------------------------------------------------------------- Comment By: Mark E (markenglish) Date: 2006-07-10 16:27 Message: Logged In: YES user_id=1174185 Apparently follow-up posts get to keep indentation, so here's hoping: ---Start--- """ """ def foo(): """This line is fine This line makes PythonWin unhappy. """ pass ---End--- ---------------------------------------------------------------------- Comment By: Mark E (markenglish) Date: 2006-07-10 16:23 Message: Logged In: YES user_id=1174185 Unfortunately the code loses indentation inline in the report, so use the attached indnterr.py file to see the problem ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1520060&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-07-10 16:27:31
|
Bugs item #1520060, was opened at 2006-07-10 16:21 Message generated for change (Comment added) made by markenglish You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1520060&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pythonwin Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mark E (markenglish) Assigned to: Nobody/Anonymous (nobody) Summary: .py file "IndentationError" corrupts appearance Initial Comment: Opening a .py file like the one attached causes a long stack trace to appear in the Interactive Window (appended at base of this description), and a number of strange characters to appear in the script window (particularly breakpoint characters on every line). The file must have triple quotes at the top, some kind of code construct like a class or a file with a triple- quoted doc string who's second line is indented. For example: ---Start--- """ """ def foo(): """This line is fine This line makes PythonWin unhappy. """ pass ---End--- Removing the triple quotes from the top of the file makes the problem vanish. Removing the second line from the function doc-string also makes the problem vanish. Tried on Windows 2000 installation built from source, and Windows XP SP2 installation installed from ActiveState. ---Error Log--- >>> Traceback (most recent call last): File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\framework\editor\color\colored itor.py", line 51, in OnInitialUpdate SyntEditViewParent.OnInitialUpdate(self) File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\scintilla\view.py", line 210, in OnInitialUpdate self.OnWinIniChange(None) File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\scintilla\view.py", line 223, in OnWinIniChange self.DoConfigChange() File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\framework\editor\color\colored itor.py", line 162, in DoConfigChange ext.set_indentation_params(1) File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\idle\AutoIndent.py", line 140, in set_indentation_params i = self.guess_indent() File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\idle\AutoIndent.py", line 473, in guess_indent opener, indented = IndentSearcher(self.text, self.tabwidth).run() File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\idle\AutoIndent.py", line 546, in run _tokenize.tokenize(self.readline, self.tokeneater) File "C:\Program Files\Python242\Lib\tokenize.py", line 153, in tokenize tokenize_loop(readline, tokeneater) File "C:\Program Files\Python242\Lib\tokenize.py", line 159, in tokenize_loop for token_info in generate_tokens(readline): File "C:\Program Files\Python242\Lib\tokenize.py", line 229, in generate_tokens raise IndentationError( IndentationError: unindent does not match any outer indentation level for line: """ win32ui: OnInitialUpdate() virtual handler (<bound method SyntEditView.OnInitialUpdate of <pywin.framework.editor.color.coloreditor.SyntEditView instance at 0x010F4DA0>>) raised an exception Traceback (most recent call last): File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\framework\editor\color\colored itor.py", line 51, in OnInitialUpdate SyntEditViewParent.OnInitialUpdate(self) File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\scintilla\view.py", line 210, in OnInitialUpdate self.OnWinIniChange(None) File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\scintilla\view.py", line 223, in OnWinIniChange self.DoConfigChange() File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\framework\editor\color\colored itor.py", line 162, in DoConfigChange ext.set_indentation_params(1) File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\idle\AutoIndent.py", line 140, in set_indentation_params i = self.guess_indent() File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\idle\AutoIndent.py", line 473, in guess_indent opener, indented = IndentSearcher(self.text, self.tabwidth).run() File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\idle\AutoIndent.py", line 546, in run _tokenize.tokenize(self.readline, self.tokeneater) File "C:\Program Files\Python242\Lib\tokenize.py", line 153, in tokenize tokenize_loop(readline, tokeneater) File "C:\Program Files\Python242\Lib\tokenize.py", line 159, in tokenize_loop for token_info in generate_tokens(readline): File "C:\Program Files\Python242\Lib\tokenize.py", line 229, in generate_tokens raise IndentationError( IndentationError: unindent does not match any outer indentation level for line: """ win32ui: OnInitialUpdate() virtual handler (<bound method SyntEditView.OnInitialUpdate of <pywin.framework.editor.color.coloreditor.SyntEditView instance at 0x010F4EB8>>) raised an exception ---------------------------------------------------------------------- >Comment By: Mark E (markenglish) Date: 2006-07-10 16:27 Message: Logged In: YES user_id=1174185 Apparently follow-up posts get to keep indentation, so here's hoping: ---Start--- """ """ def foo(): """This line is fine This line makes PythonWin unhappy. """ pass ---End--- ---------------------------------------------------------------------- Comment By: Mark E (markenglish) Date: 2006-07-10 16:23 Message: Logged In: YES user_id=1174185 Unfortunately the code loses indentation inline in the report, so use the attached indnterr.py file to see the problem ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1520060&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-07-10 16:23:54
|
Bugs item #1520060, was opened at 2006-07-10 16:21 Message generated for change (Comment added) made by markenglish You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1520060&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pythonwin Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mark E (markenglish) Assigned to: Nobody/Anonymous (nobody) Summary: .py file "IndentationError" corrupts appearance Initial Comment: Opening a .py file like the one attached causes a long stack trace to appear in the Interactive Window (appended at base of this description), and a number of strange characters to appear in the script window (particularly breakpoint characters on every line). The file must have triple quotes at the top, some kind of code construct like a class or a file with a triple- quoted doc string who's second line is indented. For example: ---Start--- """ """ def foo(): """This line is fine This line makes PythonWin unhappy. """ pass ---End--- Removing the triple quotes from the top of the file makes the problem vanish. Removing the second line from the function doc-string also makes the problem vanish. Tried on Windows 2000 installation built from source, and Windows XP SP2 installation installed from ActiveState. ---Error Log--- >>> Traceback (most recent call last): File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\framework\editor\color\colored itor.py", line 51, in OnInitialUpdate SyntEditViewParent.OnInitialUpdate(self) File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\scintilla\view.py", line 210, in OnInitialUpdate self.OnWinIniChange(None) File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\scintilla\view.py", line 223, in OnWinIniChange self.DoConfigChange() File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\framework\editor\color\colored itor.py", line 162, in DoConfigChange ext.set_indentation_params(1) File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\idle\AutoIndent.py", line 140, in set_indentation_params i = self.guess_indent() File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\idle\AutoIndent.py", line 473, in guess_indent opener, indented = IndentSearcher(self.text, self.tabwidth).run() File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\idle\AutoIndent.py", line 546, in run _tokenize.tokenize(self.readline, self.tokeneater) File "C:\Program Files\Python242\Lib\tokenize.py", line 153, in tokenize tokenize_loop(readline, tokeneater) File "C:\Program Files\Python242\Lib\tokenize.py", line 159, in tokenize_loop for token_info in generate_tokens(readline): File "C:\Program Files\Python242\Lib\tokenize.py", line 229, in generate_tokens raise IndentationError( IndentationError: unindent does not match any outer indentation level for line: """ win32ui: OnInitialUpdate() virtual handler (<bound method SyntEditView.OnInitialUpdate of <pywin.framework.editor.color.coloreditor.SyntEditView instance at 0x010F4DA0>>) raised an exception Traceback (most recent call last): File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\framework\editor\color\colored itor.py", line 51, in OnInitialUpdate SyntEditViewParent.OnInitialUpdate(self) File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\scintilla\view.py", line 210, in OnInitialUpdate self.OnWinIniChange(None) File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\scintilla\view.py", line 223, in OnWinIniChange self.DoConfigChange() File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\framework\editor\color\colored itor.py", line 162, in DoConfigChange ext.set_indentation_params(1) File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\idle\AutoIndent.py", line 140, in set_indentation_params i = self.guess_indent() File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\idle\AutoIndent.py", line 473, in guess_indent opener, indented = IndentSearcher(self.text, self.tabwidth).run() File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\idle\AutoIndent.py", line 546, in run _tokenize.tokenize(self.readline, self.tokeneater) File "C:\Program Files\Python242\Lib\tokenize.py", line 153, in tokenize tokenize_loop(readline, tokeneater) File "C:\Program Files\Python242\Lib\tokenize.py", line 159, in tokenize_loop for token_info in generate_tokens(readline): File "C:\Program Files\Python242\Lib\tokenize.py", line 229, in generate_tokens raise IndentationError( IndentationError: unindent does not match any outer indentation level for line: """ win32ui: OnInitialUpdate() virtual handler (<bound method SyntEditView.OnInitialUpdate of <pywin.framework.editor.color.coloreditor.SyntEditView instance at 0x010F4EB8>>) raised an exception ---------------------------------------------------------------------- >Comment By: Mark E (markenglish) Date: 2006-07-10 16:23 Message: Logged In: YES user_id=1174185 Unfortunately the code loses indentation inline in the report, so use the attached indnterr.py file to see the problem ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1520060&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-07-10 16:21:12
|
Bugs item #1520060, was opened at 2006-07-10 16:21 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=1520060&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pythonwin Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mark E (markenglish) Assigned to: Nobody/Anonymous (nobody) Summary: .py file "IndentationError" corrupts appearance Initial Comment: Opening a .py file like the one attached causes a long stack trace to appear in the Interactive Window (appended at base of this description), and a number of strange characters to appear in the script window (particularly breakpoint characters on every line). The file must have triple quotes at the top, some kind of code construct like a class or a file with a triple- quoted doc string who's second line is indented. For example: ---Start--- """ """ def foo(): """This line is fine This line makes PythonWin unhappy. """ pass ---End--- Removing the triple quotes from the top of the file makes the problem vanish. Removing the second line from the function doc-string also makes the problem vanish. Tried on Windows 2000 installation built from source, and Windows XP SP2 installation installed from ActiveState. ---Error Log--- >>> Traceback (most recent call last): File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\framework\editor\color\colored itor.py", line 51, in OnInitialUpdate SyntEditViewParent.OnInitialUpdate(self) File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\scintilla\view.py", line 210, in OnInitialUpdate self.OnWinIniChange(None) File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\scintilla\view.py", line 223, in OnWinIniChange self.DoConfigChange() File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\framework\editor\color\colored itor.py", line 162, in DoConfigChange ext.set_indentation_params(1) File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\idle\AutoIndent.py", line 140, in set_indentation_params i = self.guess_indent() File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\idle\AutoIndent.py", line 473, in guess_indent opener, indented = IndentSearcher(self.text, self.tabwidth).run() File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\idle\AutoIndent.py", line 546, in run _tokenize.tokenize(self.readline, self.tokeneater) File "C:\Program Files\Python242\Lib\tokenize.py", line 153, in tokenize tokenize_loop(readline, tokeneater) File "C:\Program Files\Python242\Lib\tokenize.py", line 159, in tokenize_loop for token_info in generate_tokens(readline): File "C:\Program Files\Python242\Lib\tokenize.py", line 229, in generate_tokens raise IndentationError( IndentationError: unindent does not match any outer indentation level for line: """ win32ui: OnInitialUpdate() virtual handler (<bound method SyntEditView.OnInitialUpdate of <pywin.framework.editor.color.coloreditor.SyntEditView instance at 0x010F4DA0>>) raised an exception Traceback (most recent call last): File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\framework\editor\color\colored itor.py", line 51, in OnInitialUpdate SyntEditViewParent.OnInitialUpdate(self) File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\scintilla\view.py", line 210, in OnInitialUpdate self.OnWinIniChange(None) File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\scintilla\view.py", line 223, in OnWinIniChange self.DoConfigChange() File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\framework\editor\color\colored itor.py", line 162, in DoConfigChange ext.set_indentation_params(1) File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\idle\AutoIndent.py", line 140, in set_indentation_params i = self.guess_indent() File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\idle\AutoIndent.py", line 473, in guess_indent opener, indented = IndentSearcher(self.text, self.tabwidth).run() File "C:\Program Files\Python24\Lib\site- packages\pythonwin\pywin\idle\AutoIndent.py", line 546, in run _tokenize.tokenize(self.readline, self.tokeneater) File "C:\Program Files\Python242\Lib\tokenize.py", line 153, in tokenize tokenize_loop(readline, tokeneater) File "C:\Program Files\Python242\Lib\tokenize.py", line 159, in tokenize_loop for token_info in generate_tokens(readline): File "C:\Program Files\Python242\Lib\tokenize.py", line 229, in generate_tokens raise IndentationError( IndentationError: unindent does not match any outer indentation level for line: """ win32ui: OnInitialUpdate() virtual handler (<bound method SyntEditView.OnInitialUpdate of <pywin.framework.editor.color.coloreditor.SyntEditView instance at 0x010F4EB8>>) raised an exception ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1520060&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-07-07 15:35:30
|
Bugs item #1517894, was opened at 2006-07-05 22:05 Message generated for change (Comment added) made by timtucker You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1517894&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Greg Hazel (ghazel) Assigned to: Nobody/Anonymous (nobody) Summary: 208 python 2.5 import issues Initial Comment: C:\Python25\lib\site-packages\win32 \lib\pywintypes.py:64: RuntimeWarning: Python C API version mismatch for module _win32sysloader: This Python has API version 1013, module _win32sysloader has version 1012. import _win32sysloader C:\Python25\lib\site-packages\win32 \lib\pywintypes.py:98: RuntimeWarning: Python C API version mismatch for module pywintypes: This Python has API version 1013, module pywintypes has version 1012. ('.dll', 'rb', imp.C_EXTENSION)) C:\project\file.py:30: RuntimeWarning: Python C API version mismatch for module win32a pi: This Python has API version 1013, module win32api has version 1012. import win32api C:\project\file.py:31: RuntimeWarning: Python C API version mismatch for module win32f ile: This Python has API version 1013, module win32file has version 1012. import win32file C:\WINDOWS\system32\pywintypes25.dll:98: RuntimeWarning: Python C API version mi smatch for module pythoncom: This Python has API version 1013, module pythoncom has version 1012. ââ¶âïâ¦$à âuâÃöâwâ²Â Ãöâwâ²Ã¯Ldë C:\WINDOWS\system32\pywintypes25.dll:98: RuntimeWarning: Python C API version mi smatch for module pythoncom.__univgw: This Python has API version 1013, module p ythoncom.__univgw has version 1012. ââ¶âïâ¦$à âuâÃöâwâ²Â Ãöâwâ²Ã¯Ldë C:\Python25\lib\site- packages\win32com\__init__.py:89: ImportWarning: Not import ing directory 'C:\Python25\lib\site- packages\win32com\gen_py': missing __init__. py import win32com.gen_py ---------------------------------------------------------------------- Comment By: Timothy Tucker (timtucker) Date: 2006-07-07 10:35 Message: Logged In: YES user_id=966761 Having the same problem here -- was pywin32 built with the previous build of 2.5? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1517894&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-07-07 13:52:37
|
Bugs item #1517601, was opened at 2006-07-05 11:52 Message generated for change (Comment added) made by rberrett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1517601&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pythonwin Group: None Status: Open Resolution: None Priority: 5 Submitted By: rberrett (rberrett) Assigned to: Nobody/Anonymous (nobody) Summary: WNetGetUser fails if connection is specified Initial Comment: When trying to run WNetGetUser with connection (drive letter) supplied, raise a "Couldn't get the buffer size!" runtime errror Example: username = win32wnet.WNetGetUser( "z:" ) NOTE: This appears to be a caused by an inconstancy in they windows WNetGetUser call. The win32wnet wrapper calls WNetGetUser with NULL in the username argument to get the buffer size. But unless the connections (lpName) is also NULL the length is does not appear to be set Following sets the length correctly: WNetGetUser(NULL, NULL, &length ); Following fails to set the length: WNetGetUser("v:", NULL, &length ); ---------------------------------------------------------------------- >Comment By: rberrett (rberrett) Date: 2006-07-07 09:52 Message: Logged In: YES user_id=1121829 I tried this against a few systems, both Windows XP and Unix based, with the same results ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2006-07-07 04:20 Message: Logged In: YES user_id=771074 What type of systems provide the shares that the local drives are mapped to ? I also added WNetGetLastError to win32wnet, in case extended error info is available from them. ---------------------------------------------------------------------- Comment By: rberrett (rberrett) Date: 2006-07-06 10:34 Message: Logged In: YES user_id=1121829 Versions: python 2.4.2 win32 2.4.205.0 OS: Windows XP ServicePack 2 NetUseGetInfo is giving good information, but GetUser still seems to be failing. I have tried this one a couple of our test machines. I have attached a small test program I used to to examine the problem I was having. Here is a sample of the output: X: Microsoft Windows Network \\b3server3\storage_1 NetUseGetInfo: {'remote': u'\\\\b3server3\\storage_1', 'local': u'X:'} WNetGetUser: Couldn't get the buffer size! W: Microsoft Windows Network \\nssgsvr\test NetUseGetInfo: {'remote': u'\\\\nssgsvr\\test', 'local': u'W:'} WNetGetUser: Couldn't get the buffer size! ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2006-07-06 02:38 Message: Logged In: YES user_id=14198 My experience is exactly the same as Roger's - it works fine for an existing connection. I tried XP and (thanks to vmware!) Win98. ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2006-07-06 01:23 Message: Logged In: YES user_id=771074 I can't reproduce this with an existing connection on Win2k or WinXP. What OS and python/pywin32 versions do you have ? Also, could you verify that the mapped drive exists under the current user by adding this line before WNetGetUser: print win32net.NetUseGetInfo(None,'v:') (or z:, or whichever drive letter you're passing to WNetGetUser) Roger Roger ---------------------------------------------------------------------- Comment By: rberrett (rberrett) Date: 2006-07-05 15:48 Message: Logged In: YES user_id=1121829 I see this with any existing mapped drive letters. The only time I do not get this message is if I do not specify the connection. username = win32wnet.WNetGetUser() ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2006-07-05 15:01 Message: Logged In: YES user_id=771074 I see this too, but only if a nonexistent connection is passed to it. Do you get this error if you pass a drive letter that's actually mapped ? The first call for the buffer size isn't checking the returned error code. I'll check in a fix shortly. Roger ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1517601&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-07-07 08:20:50
|
Bugs item #1517601, was opened at 2006-07-05 10:52 Message generated for change (Comment added) made by rupole You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1517601&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pythonwin Group: None Status: Open Resolution: None Priority: 5 Submitted By: rberrett (rberrett) Assigned to: Nobody/Anonymous (nobody) Summary: WNetGetUser fails if connection is specified Initial Comment: When trying to run WNetGetUser with connection (drive letter) supplied, raise a "Couldn't get the buffer size!" runtime errror Example: username = win32wnet.WNetGetUser( "z:" ) NOTE: This appears to be a caused by an inconstancy in they windows WNetGetUser call. The win32wnet wrapper calls WNetGetUser with NULL in the username argument to get the buffer size. But unless the connections (lpName) is also NULL the length is does not appear to be set Following sets the length correctly: WNetGetUser(NULL, NULL, &length ); Following fails to set the length: WNetGetUser("v:", NULL, &length ); ---------------------------------------------------------------------- >Comment By: Roger Upole (rupole) Date: 2006-07-07 03:20 Message: Logged In: YES user_id=771074 What type of systems provide the shares that the local drives are mapped to ? I also added WNetGetLastError to win32wnet, in case extended error info is available from them. ---------------------------------------------------------------------- Comment By: rberrett (rberrett) Date: 2006-07-06 09:34 Message: Logged In: YES user_id=1121829 Versions: python 2.4.2 win32 2.4.205.0 OS: Windows XP ServicePack 2 NetUseGetInfo is giving good information, but GetUser still seems to be failing. I have tried this one a couple of our test machines. I have attached a small test program I used to to examine the problem I was having. Here is a sample of the output: X: Microsoft Windows Network \\b3server3\storage_1 NetUseGetInfo: {'remote': u'\\\\b3server3\\storage_1', 'local': u'X:'} WNetGetUser: Couldn't get the buffer size! W: Microsoft Windows Network \\nssgsvr\test NetUseGetInfo: {'remote': u'\\\\nssgsvr\\test', 'local': u'W:'} WNetGetUser: Couldn't get the buffer size! ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2006-07-06 01:38 Message: Logged In: YES user_id=14198 My experience is exactly the same as Roger's - it works fine for an existing connection. I tried XP and (thanks to vmware!) Win98. ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2006-07-06 00:23 Message: Logged In: YES user_id=771074 I can't reproduce this with an existing connection on Win2k or WinXP. What OS and python/pywin32 versions do you have ? Also, could you verify that the mapped drive exists under the current user by adding this line before WNetGetUser: print win32net.NetUseGetInfo(None,'v:') (or z:, or whichever drive letter you're passing to WNetGetUser) Roger Roger ---------------------------------------------------------------------- Comment By: rberrett (rberrett) Date: 2006-07-05 14:48 Message: Logged In: YES user_id=1121829 I see this with any existing mapped drive letters. The only time I do not get this message is if I do not specify the connection. username = win32wnet.WNetGetUser() ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2006-07-05 14:01 Message: Logged In: YES user_id=771074 I see this too, but only if a nonexistent connection is passed to it. Do you get this error if you pass a drive letter that's actually mapped ? The first call for the buffer size isn't checking the returned error code. I'll check in a fix shortly. Roger ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1517601&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-07-06 14:34:42
|
Bugs item #1517601, was opened at 2006-07-05 11:52 Message generated for change (Comment added) made by rberrett You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1517601&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pythonwin Group: None Status: Open Resolution: None Priority: 5 Submitted By: rberrett (rberrett) Assigned to: Nobody/Anonymous (nobody) Summary: WNetGetUser fails if connection is specified Initial Comment: When trying to run WNetGetUser with connection (drive letter) supplied, raise a "Couldn't get the buffer size!" runtime errror Example: username = win32wnet.WNetGetUser( "z:" ) NOTE: This appears to be a caused by an inconstancy in they windows WNetGetUser call. The win32wnet wrapper calls WNetGetUser with NULL in the username argument to get the buffer size. But unless the connections (lpName) is also NULL the length is does not appear to be set Following sets the length correctly: WNetGetUser(NULL, NULL, &length ); Following fails to set the length: WNetGetUser("v:", NULL, &length ); ---------------------------------------------------------------------- >Comment By: rberrett (rberrett) Date: 2006-07-06 10:34 Message: Logged In: YES user_id=1121829 Versions: python 2.4.2 win32 2.4.205.0 OS: Windows XP ServicePack 2 NetUseGetInfo is giving good information, but GetUser still seems to be failing. I have tried this one a couple of our test machines. I have attached a small test program I used to to examine the problem I was having. Here is a sample of the output: X: Microsoft Windows Network \\b3server3\storage_1 NetUseGetInfo: {'remote': u'\\\\b3server3\\storage_1', 'local': u'X:'} WNetGetUser: Couldn't get the buffer size! W: Microsoft Windows Network \\nssgsvr\test NetUseGetInfo: {'remote': u'\\\\nssgsvr\\test', 'local': u'W:'} WNetGetUser: Couldn't get the buffer size! ---------------------------------------------------------------------- Comment By: Mark Hammond (mhammond) Date: 2006-07-06 02:38 Message: Logged In: YES user_id=14198 My experience is exactly the same as Roger's - it works fine for an existing connection. I tried XP and (thanks to vmware!) Win98. ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2006-07-06 01:23 Message: Logged In: YES user_id=771074 I can't reproduce this with an existing connection on Win2k or WinXP. What OS and python/pywin32 versions do you have ? Also, could you verify that the mapped drive exists under the current user by adding this line before WNetGetUser: print win32net.NetUseGetInfo(None,'v:') (or z:, or whichever drive letter you're passing to WNetGetUser) Roger Roger ---------------------------------------------------------------------- Comment By: rberrett (rberrett) Date: 2006-07-05 15:48 Message: Logged In: YES user_id=1121829 I see this with any existing mapped drive letters. The only time I do not get this message is if I do not specify the connection. username = win32wnet.WNetGetUser() ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2006-07-05 15:01 Message: Logged In: YES user_id=771074 I see this too, but only if a nonexistent connection is passed to it. Do you get this error if you pass a drive letter that's actually mapped ? The first call for the buffer size isn't checking the returned error code. I'll check in a fix shortly. Roger ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1517601&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-07-06 05:23:42
|
Bugs item #1517601, was opened at 2006-07-05 10:52 Message generated for change (Comment added) made by rupole You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1517601&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pythonwin Group: None Status: Open Resolution: None Priority: 5 Submitted By: rberrett (rberrett) Assigned to: Nobody/Anonymous (nobody) Summary: WNetGetUser fails if connection is specified Initial Comment: When trying to run WNetGetUser with connection (drive letter) supplied, raise a "Couldn't get the buffer size!" runtime errror Example: username = win32wnet.WNetGetUser( "z:" ) NOTE: This appears to be a caused by an inconstancy in they windows WNetGetUser call. The win32wnet wrapper calls WNetGetUser with NULL in the username argument to get the buffer size. But unless the connections (lpName) is also NULL the length is does not appear to be set Following sets the length correctly: WNetGetUser(NULL, NULL, &length ); Following fails to set the length: WNetGetUser("v:", NULL, &length ); ---------------------------------------------------------------------- >Comment By: Roger Upole (rupole) Date: 2006-07-06 00:23 Message: Logged In: YES user_id=771074 I can't reproduce this with an existing connection on Win2k or WinXP. What OS and python/pywin32 versions do you have ? Also, could you verify that the mapped drive exists under the current user by adding this line before WNetGetUser: print win32net.NetUseGetInfo(None,'v:') (or z:, or whichever drive letter you're passing to WNetGetUser) Roger Roger ---------------------------------------------------------------------- Comment By: rberrett (rberrett) Date: 2006-07-05 14:48 Message: Logged In: YES user_id=1121829 I see this with any existing mapped drive letters. The only time I do not get this message is if I do not specify the connection. username = win32wnet.WNetGetUser() ---------------------------------------------------------------------- Comment By: Roger Upole (rupole) Date: 2006-07-05 14:01 Message: Logged In: YES user_id=771074 I see this too, but only if a nonexistent connection is passed to it. Do you get this error if you pass a drive letter that's actually mapped ? The first call for the buffer size isn't checking the returned error code. I'll check in a fix shortly. Roger ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1517601&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-06-26 13:24:38
|
Bugs item #1512715, was opened at 2006-06-26 15:24 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=1512715&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pythonwin Group: None Status: Open Resolution: None Priority: 5 Submitted By: kxroberto (kxroberto) Assigned to: Nobody/Anonymous (nobody) Summary: CVirtualHelper::call / do_call double DODECREF Bug ? Initial Comment: (last seen in 207/208) For example BOOL CVirtualHelper::call(const MSG *msg) does BOOL ret = do_call(arglst); DODECREF(arglst); // my reference. but BOOL CVirtualHelper::do_call(PyObject *args) also does PyObject *result = gui_call_object(handler,args); DODECREF(args); Seems this explains a couple of OS-level crashes and sudden disappearance of objects here (mainly on dual cores), where the virtual PyCWnd.PreTranslateMessage is used. But attention! Most of the CVirtualHelper::call's on the other side rely on the DODECREF(args) in do_call - e.g.: the "wrong" ones doing an extra DODECREF seem to be only BOOL CVirtualHelper::call(const MSG *msg) and BOOL CVirtualHelper::call(UINT nID, int nCode, void* pExtra, AFX_CMDHANDLERINFO*pHandlerInfo) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1512715&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-06-23 07:51:49
|
Feature Requests item #1510601, was opened at 2006-06-22 14:38 Message generated for change (Settings changed) made by wrstlprmpft You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1510601&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: win32 Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: wrstl prmpft (wrstlprmpft) >Assigned to: Mark Hammond (mhammond) Summary: Add CreateRemoteThread to win32process Initial Comment: summary says it all. helpful for a SafeTerminateProcess function as in http://www.ddj.com/ showArticle.jhtml?documentID=wdj9907c&pgno=9 ---------------------------------------------------------------------- >Comment By: wrstl prmpft (wrstlprmpft) Date: 2006-06-23 09:51 Message: Logged In: YES user_id=801589 done by mhammond as of revision 1.18 of win32process.i thanks ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1510601&group_id=78018 |
|
From: SourceForge.net <no...@so...> - 2006-06-22 12:56:24
|
Feature Requests item #1510601, was opened at 2006-06-22 14:38 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=1510601&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: win32 Group: None Status: Open Resolution: None Priority: 5 Submitted By: wrstl prmpft (wrstlprmpft) Assigned to: Nobody/Anonymous (nobody) Summary: Add CreateRemoteThread to win32process Initial Comment: summary says it all. helpful for a SafeTerminateProcess function as in http://www.ddj.com/ showArticle.jhtml?documentID=wdj9907c&pgno=9 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1510601&group_id=78018 |
2 messages has been excluded from this view by a project administrator.
