pywin32-bugs — Automated tracker notifications (not for bug reports!)

[pywin32-bugs] [ pywin32-Bugs-1508459 ] AcceptEx needs to return an error code

[SourceForge.net <no...@so...>]

Bugs item #1508459, was opened at 2006-06-19 01:12
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=1508459&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: Pavel Pergamenshchik (ppergame)
Assigned to: Nobody/Anonymous (nobody)
Summary: AcceptEx needs to return an error code

Initial Comment:
Right now, AcceptEx does not indicate whether the
operation completed immediately or was queued. Since
the information is available anyway, it would be nice
if the function returned the code.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1508459&group_id=78018

[pywin32-bugs] [ pywin32-Feature Requests-1507080 ] Add ConnectEx

[SourceForge.net <no...@so...>]

Feature Requests item #1507080, was opened at 2006-06-15 22:37
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=1507080&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: Pavel Pergamenshchik (ppergame)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add ConnectEx

Initial Comment:
It would be nice to have the binding for ConnectEx. It
is available only on WinXP and higher. The function
pointer must be retrieved at runtime with WSAIoctl.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1507080&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-1475467 ] win32ui: Internal error-existing object is not of same type?

[SourceForge.net <no...@so...>]

Bugs item #1475467, was opened at 2006-04-24 13:47
Message generated for change (Comment added) made by kxroberto
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1475467&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: 6
Submitted By: kxroberto (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: win32ui: Internal error-existing object is not of same type?

Initial Comment:
I get rare reports with this error:

"win32ui: Internal error - existing object is not of
same type as requested new object"

(the last was on a Win XP Prof; build 208 or build205 -
not sure)

it traces to a bare:

tt=win32ui.CreateToolTipCtrl();tt.CreateWindow(parent,0)
   

I don't even find the above error string in the pywin32
sources. Only "Internal error - existing object has
type..." in win32assoc.cpp

What error is this "existing object is not of same type
as requested new object"?

Most probably it has to do with (win32tooltip.cpp):

return ui_assoc_object::make( PyCToolTipCtrl::type, pTTC );


Many of such ::make's in the win32ui sources have a
"->GetGoodRet()" on the line. Some have not. What is
the criteria? 

Is such ->GetGoodRet() maybe necessary in that
win32tooltip.cpp location? 

Can a misbehaviour on such ::make's also cause crashes?
(I have occasional mem. access crash reports also;
mainly on dual core's)

-robert


----------------------------------------------------------------------

>Comment By: kxroberto (kxroberto)
Date: 2006-06-07 13:52

Message:
Logged In: YES 
user_id=972995

as explained in #1483482 this would also most probably be
forced correct with ui_assoc_object::make(..., skipLookup=TRUE).

The source of the error can be ANY stale temp/wrong/lost
assoc in the map: any possible flaw in 1000's of assoc
creations in the win32ui code - probably from PyCWinThread's
(not cleaned up with ExitInstance). 

Yet the real problem are not some few (lost/bug) assoc's,
but the fact that ANY lost assoc can make everthing instable
and case OS-crashes.

Meanwhile I'd say not even ui_assoc_object::makenew is the
best solution for this (requires 1000's code locations to be
changed), but maybe ui_assoc_object::make should by default
NOT look up, but force-create/replace the assoc. There are
only quite few locations in win32ui where maybe a
ui_assoc_object::lookupmake has to be done (and if some are
forgotten its not serious - only a new python object will be
created at some cost - a DEBUG warning could tell that with
time)

So the change would be comparably simple:

* set skipLookup=TRUE by default

* put a mere DEBUG warning if a replaced assoc changes the
type (==> indicates illegal use of temporary/lost C-assocs)

* search those very very few locations in win32ui code where
ui_assoc_object::make is used upon GetXXXX-functions which
are really by guarantee not createing new C-objects, but
(re-)provide permanent C-Objects. ( in most GetXXX-functions
already PyCWnd::make is used correctly and not
ui_assoc_object::make !)

Think that would greatly improve the stability of win32ui
regarding internal errors and random crashes.

-robert


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1475467&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-1483482 ] Occasionally strange object mixup with GetDlgItem()

[SourceForge.net <no...@so...>]

Bugs item #1483482, was opened at 2006-05-07 21:31
Message generated for change (Comment added) made by kxroberto
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1483482&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: 8
Submitted By: kxroberto (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: Occasionally strange object mixup with GetDlgItem()

Initial Comment:
build 208
PythonWin 2.3.5 (#62, Feb  8 2005, 16:23:02) [MSC
v.1200 32 bit (Intel)] on win32.

Get occasionally a trace in the Pythonwin interactive
pane - like this one recently when pressing Ctrl-F
(find tool):


Traceback (most recent call last):
  File
"C:\PYTHON23\Lib\site-packages\pythonwin\pywin\scintilla\find.py",
line 169, in OnInitDialog
    self.butKeepDialogOpen = self.GetDlgItem(115)
win32ui: Internal error - existing object has type
'PyCWinThread', but 'PyCButton' was requested.
win32ui: OnInitDialog() virtual handler (<bound method
FindDialog.OnInitDialog of
<pywin.scintilla.find.FindDialog instance at
0x0157FA30>>) raised an exception


I'm noticing this ["win32ui: Internal error - existing
object has type 'PyCWinThread', but 'PyC...' was
requested."] occasionally in very random situations.
Also in other standalone win32ui apps.

This problem may relate to #1475467 (win32ui: Internal
error-existing object is not of same type?). a
"->GetGoodRet()" issue or similar problem?



----------------------------------------------------------------------

>Comment By: kxroberto (kxroberto)
Date: 2006-06-06 19:10

Message:
Logged In: YES 
user_id=972995

Think, I found some of the sources for theses kind of bugs.

I got many other such bugs reported. e.g.:

File "app.pyo", line 2033, in WmSize\\n\', "win32ui: Internal
error - existing object has type \'PyCWnd\', but
\'PyCTabCtrl\' was requested.\\n"]

I have these strong guesses for bugs:

* CPythonWinThread::ExitInstance
the MFC destroys the this pointer, but the assoc is not
deleted! ==> junk items are pickup ==> bug in OP (see
skipLookup problem below)

* ui_propsheet_get_tab_ctrl:
permanent ui_assoc_object::make is called on temporary pTab
= pPS->GetTabControl()  !!
(MFC uses FromHandle !)
PyCWnd::make should be used or something similar to make it
permanent as required for a Python-Object

* (for example!): PyCWinThread::create, PyCFormView::create,
PyCEditView::create, ... (and in most ::create functions)
ui_assoc_object::make( PyCWinThread::type, pThread ) is
called with default skipLookup=FALSE
even if the C object was created brandnew (with 'new' -
which is in done in 95% of cases) !
==> Those map lookups are very likely to pick up undeleted
junk objects in the map !
==> when Objects are created new, skipLookup=TRUE should be
used - or FALSE the default and TRUE only for GetXXX things
- or best a new ui_assoc_object::makenew should be used.
Think this is very important and I attribute many other
strange win32ui - Internal errors to this risky map management.

* ui_assoc_object::GetGoodRet
DODECREF better to be done after DOINCREF !?

-robert


----------------------------------------------------------------------

Comment By: kxroberto (kxroberto)
Date: 2006-05-07 21:32

Message:
Logged In: YES 
user_id=972995

trace again (as initial posting removes whitespace):


Traceback (most recent call last):
  File
"C:\PYTHON23\Lib\site-packages\pythonwin\pywin\scintilla\find.py",
line 169, in OnInitDialog
    self.butKeepDialogOpen = self.GetDlgItem(115)
win32ui: Internal error - existing object has type
'PyCWinThread', but 'PyCButton' was requested.
win32ui: OnInitDialog() virtual handler (<bound method
FindDialog.OnInitDialog of <pywin.scintilla.find.FindDialog
instance at 0x0157FA30>>) raised an exception

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1483482&group_id=78018

[pywin32-bugs] [ pywin32-Feature Requests-1501429 ] would like to have ReadProcessMemory

[SourceForge.net <no...@so...>]

Feature Requests item #1501429, was opened at 2006-06-06 16:03
Message generated for change (Comment added) made by jpcurrey
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1501429&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 Currey (jpcurrey)
Assigned to: Nobody/Anonymous (nobody)
Summary: would like to have ReadProcessMemory

Initial Comment:
would like to see ReadProcessMemory added to the api.


----------------------------------------------------------------------

>Comment By: Jason Currey (jpcurrey)
Date: 2006-06-06 16:21

Message:
Logged In: YES 
user_id=543879

I guess also WriteProcessMemory would also be helpful. 
I notice these functions are in the perl equivalent.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1501429&group_id=78018

[pywin32-bugs] [ pywin32-Feature Requests-1501429 ] would like to have ReadProcessMemory

[SourceForge.net <no...@so...>]

Feature Requests item #1501429, was opened at 2006-06-06 16:03
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=1501429&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 Currey (jpcurrey)
Assigned to: Nobody/Anonymous (nobody)
Summary: would like to have ReadProcessMemory

Initial Comment:
would like to see ReadProcessMemory added to the api.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1501429&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-1492124 ] No help for topics or keywords

[SourceForge.net <no...@so...>]

Bugs item #1492124, was opened at 2006-05-21 02:09
Message generated for change (Comment added) made by mhammond
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1492124&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: Invalid
Priority: 5
Submitted By: BartlebyScrivener (bscrivener)
Assigned to: Nobody/Anonymous (nobody)
Summary: No help for topics or keywords

Initial Comment:

Initial Comment:
Using ActivePython 2.4.3 on Windows XP

While in the Pythonwin IDE, if I seek keyword help by
issuing the following command:

>>>help ('while') or
>>>help ('functions')

I get:

Sorry, topic and keyword documentation is not available
because the Python HTML documentation files could not
be found.  If you have installed them, please set the
environment variable PYTHONDOCS to
indicate their location.

My PYTHONDOCS variable is set to:

c:\python24\Doc\Python-Docs-2.4.2\ref

which appears to be correct (ie the help html files are
installed there).

Searching this group, I found someone else complaining
about the same behavior with no clear resolution.

http://tinyurl.com/pblev

See also

http://tinyurl.com/mbokp


----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2006-06-01 09:19

Message:
Logged In: YES 
user_id=14198

This isn't related to Pythonwin.  If you try the same thing
from python.exe, you will get the same result.  Pythonwin
does nothing special to support help() - that is built into
Python itself.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1492124&group_id=78018

[pywin32-bugs] [ pywin32-Feature Requests-1481844 ] multi monitor, dualview, extended desktop support functions

[SourceForge.net <no...@so...>]

Feature Requests item #1481844, was opened at 2006-05-04 08:48
Message generated for change (Comment added) made by rupole
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: Open
Resolution: None
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: Roger Upole (rupole)
Date: 2006-05-25 22: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 07: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 05: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

[pywin32-bugs] [ pywin32-Patches-1495095 ] timer.pyd

[SourceForge.net <no...@so...>]

Patches item #1495095, was opened at 2006-05-25 20:26
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=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



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551956&aid=1495095&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-1492124 ] No help for topics or keywords

[SourceForge.net <no...@so...>]

Bugs item #1492124, was opened at 2006-05-20 16:09
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=1492124&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: BartlebyScrivener (bscrivener)
Assigned to: Nobody/Anonymous (nobody)
Summary: No help for topics or keywords

Initial Comment:

Initial Comment:
Using ActivePython 2.4.3 on Windows XP

While in the Pythonwin IDE, if I seek keyword help by
issuing the following command:

>>>help ('while') or
>>>help ('functions')

I get:

Sorry, topic and keyword documentation is not available
because the Python HTML documentation files could not
be found.  If you have installed them, please set the
environment variable PYTHONDOCS to
indicate their location.

My PYTHONDOCS variable is set to:

c:\python24\Doc\Python-Docs-2.4.2\ref

which appears to be correct (ie the help html files are
installed there).

Searching this group, I found someone else complaining
about the same behavior with no clear resolution.

http://tinyurl.com/pblev

See also

http://tinyurl.com/mbokp


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1492124&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-1489690 ] Memory Leak: PyCWnd objects are never freed

[SourceForge.net <no...@so...>]

Bugs item #1489690, was opened at 2006-05-16 18:42
Message generated for change (Comment added) made by kxroberto
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: Open
Resolution: None
>Priority: 7
Submitted By: kxroberto (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
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: kxroberto (kxroberto)
Date: 2006-05-16 22: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-16 18: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

[pywin32-bugs] [ pywin32-Bugs-1489690 ] Memory Leak: PyCWnd objects are never freed

[SourceForge.net <no...@so...>]

Bugs item #1489690, was opened at 2006-05-16 18:42
Message generated for change (Comment added) made by kxroberto
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: Open
Resolution: None
>Priority: 6
Submitted By: kxroberto (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
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: kxroberto (kxroberto)
Date: 2006-05-16 18: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

[pywin32-bugs] [ pywin32-Bugs-1489690 ] Memory Leak: PyCWnd objects are never freed

[SourceForge.net <no...@so...>]

Bugs item #1489690, was opened at 2006-05-16 18:42
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=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: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: kxroberto (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
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


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1489690&group_id=78018

[pywin32-bugs] [ pywin32-Feature Requests-1481844 ] multi monitor, dualview, extended desktop support functions

[SourceForge.net <no...@so...>]

Feature Requests item #1481844, was opened at 2006-05-04 08:48
Message generated for change (Comment added) made by rupole
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: Open
Resolution: None
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: Roger Upole (rupole)
Date: 2006-05-13 07: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 05: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

[pywin32-bugs] [ pywin32-Feature Requests-1481844 ] multi monitor, dualview, extended desktop support functions

[SourceForge.net <no...@so...>]

Feature Requests item #1481844, was opened at 2006-05-04 15:48
Message generated for change (Comment added) made by wrstlprmpft
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: Open
Resolution: None
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: wrstl prmpft (wrstlprmpft)
Date: 2006-05-11 12: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

[pywin32-bugs] [ pywin32-Bugs-1483482 ] Occasionally strange object mixup with GetDlgItem()

[SourceForge.net <no...@so...>]

Bugs item #1483482, was opened at 2006-05-07 21:31
Message generated for change (Comment added) made by kxroberto
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1483482&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: Occasionally strange object mixup with GetDlgItem()

Initial Comment:
build 208
PythonWin 2.3.5 (#62, Feb  8 2005, 16:23:02) [MSC
v.1200 32 bit (Intel)] on win32.

Get occasionally a trace in the Pythonwin interactive
pane - like this one recently when pressing Ctrl-F
(find tool):


Traceback (most recent call last):
  File
"C:\PYTHON23\Lib\site-packages\pythonwin\pywin\scintilla\find.py",
line 169, in OnInitDialog
    self.butKeepDialogOpen = self.GetDlgItem(115)
win32ui: Internal error - existing object has type
'PyCWinThread', but 'PyCButton' was requested.
win32ui: OnInitDialog() virtual handler (<bound method
FindDialog.OnInitDialog of
<pywin.scintilla.find.FindDialog instance at
0x0157FA30>>) raised an exception


I'm noticing this ["win32ui: Internal error - existing
object has type 'PyCWinThread', but 'PyC...' was
requested."] occasionally in very random situations.
Also in other standalone win32ui apps.

This problem may relate to #1475467 (win32ui: Internal
error-existing object is not of same type?). a
"->GetGoodRet()" issue or similar problem?



----------------------------------------------------------------------

>Comment By: kxroberto (kxroberto)
Date: 2006-05-07 21:32

Message:
Logged In: YES 
user_id=972995

trace again (as initial posting removes whitespace):


Traceback (most recent call last):
  File
"C:\PYTHON23\Lib\site-packages\pythonwin\pywin\scintilla\find.py",
line 169, in OnInitDialog
    self.butKeepDialogOpen = self.GetDlgItem(115)
win32ui: Internal error - existing object has type
'PyCWinThread', but 'PyCButton' was requested.
win32ui: OnInitDialog() virtual handler (<bound method
FindDialog.OnInitDialog of <pywin.scintilla.find.FindDialog
instance at 0x0157FA30>>) raised an exception

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1483482&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-1483482 ] Occasionally strange object mixup with GetDlgItem()

[SourceForge.net <no...@so...>]

Bugs item #1483482, was opened at 2006-05-07 21: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=1483482&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: Occasionally strange object mixup with GetDlgItem()

Initial Comment:
build 208
PythonWin 2.3.5 (#62, Feb  8 2005, 16:23:02) [MSC
v.1200 32 bit (Intel)] on win32.

Get occasionally a trace in the Pythonwin interactive
pane - like this one recently when pressing Ctrl-F
(find tool):


Traceback (most recent call last):
  File
"C:\PYTHON23\Lib\site-packages\pythonwin\pywin\scintilla\find.py",
line 169, in OnInitDialog
    self.butKeepDialogOpen = self.GetDlgItem(115)
win32ui: Internal error - existing object has type
'PyCWinThread', but 'PyCButton' was requested.
win32ui: OnInitDialog() virtual handler (<bound method
FindDialog.OnInitDialog of
<pywin.scintilla.find.FindDialog instance at
0x0157FA30>>) raised an exception


I'm noticing this ["win32ui: Internal error - existing
object has type 'PyCWinThread', but 'PyC...' was
requested."] occasionally in very random situations.
Also in other standalone win32ui apps.

This problem may relate to #1475467 (win32ui: Internal
error-existing object is not of same type?). a
"->GetGoodRet()" issue or similar problem?



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1483482&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-1481242 ] win32print.WritePrinter() changes CR/LF to LF

[SourceForge.net <no...@so...>]

Bugs item #1481242, was opened at 2006-05-03 11:54
Message generated for change (Settings changed) made by rupole
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1481242&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: Invalid
Priority: 5
Submitted By: DaveNation (dnation)
Assigned to: Nobody/Anonymous (nobody)
Summary: win32print.WritePrinter() changes CR/LF to LF

Initial Comment:
I am trying to send files containing raw PCL5 data
directly to a Laserjet printer.

I am using the following win32print calls :
  h = OpenPrinter('Laserjet')
  StartDocPrinter(h,1,('bosdoc',None,'RAW'))
  WritePrinter(h,buff)
  EndDocPrinter(h)

When directing the data directly to the printer, only
the first line is printed. 

When requesting StartDocPrinter() to spool to a file,
the output file is identical to the input file except
all CR/LF pairs have been changed to single LF characters.

(In PCL5, sending CR resets the x co-ord.)

When making the same calls through VB6, the spooled
file still contains the CR/LF pair, which makes me
think it is the Python interface code that is removing
the CR character.

----------------------------------------------------------------------

Comment By: DaveNation (dnation)
Date: 2006-05-04 11:02

Message:
Logged In: YES 
user_id=1515886

Roger

Many thanks for your response. It was just as you had
summized, the buffer was being loaded from a file not opened
in binary mode.

I used the file read() method, incorrectly assuming that
CR/LF -> LF translation was only done by readline() or
readlines().

Once again, thanks for the help it's much appreciated.

Dave



----------------------------------------------------------------------

Comment By: Roger Upole (rupole)
Date: 2006-05-04 04:34

Message:
Logged In: YES 
user_id=771074

WritePrinter doesn't do any manipulation on the data passed 
to it.  You don't specify where buff comes from, but if 
you're reading it from a file, make sure it's opened in 
binary mode.  Otherwise, it's treated as text and CR/LF
is automatically translated to LF.

        Roger


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1481242&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-1481242 ] win32print.WritePrinter() changes CR/LF to LF

[SourceForge.net <no...@so...>]

Bugs item #1481242, was opened at 2006-05-03 16:54
Message generated for change (Comment added) made by dnation
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1481242&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: DaveNation (dnation)
Assigned to: Nobody/Anonymous (nobody)
Summary: win32print.WritePrinter() changes CR/LF to LF

Initial Comment:
I am trying to send files containing raw PCL5 data
directly to a Laserjet printer.

I am using the following win32print calls :
  h = OpenPrinter('Laserjet')
  StartDocPrinter(h,1,('bosdoc',None,'RAW'))
  WritePrinter(h,buff)
  EndDocPrinter(h)

When directing the data directly to the printer, only
the first line is printed. 

When requesting StartDocPrinter() to spool to a file,
the output file is identical to the input file except
all CR/LF pairs have been changed to single LF characters.

(In PCL5, sending CR resets the x co-ord.)

When making the same calls through VB6, the spooled
file still contains the CR/LF pair, which makes me
think it is the Python interface code that is removing
the CR character.

----------------------------------------------------------------------

>Comment By: DaveNation (dnation)
Date: 2006-05-04 16:02

Message:
Logged In: YES 
user_id=1515886

Roger

Many thanks for your response. It was just as you had
summized, the buffer was being loaded from a file not opened
in binary mode.

I used the file read() method, incorrectly assuming that
CR/LF -> LF translation was only done by readline() or
readlines().

Once again, thanks for the help it's much appreciated.

Dave



----------------------------------------------------------------------

Comment By: Roger Upole (rupole)
Date: 2006-05-04 09:34

Message:
Logged In: YES 
user_id=771074

WritePrinter doesn't do any manipulation on the data passed 
to it.  You don't specify where buff comes from, but if 
you're reading it from a file, make sure it's opened in 
binary mode.  Otherwise, it's treated as text and CR/LF
is automatically translated to LF.

        Roger


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1481242&group_id=78018

[pywin32-bugs] [ pywin32-Feature Requests-1481844 ] multi monitor, dualview, extended desktop support functions

[SourceForge.net <no...@so...>]

Feature Requests item #1481844, was opened at 2006-05-04 15:48
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=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: Open
Resolution: None
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

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551957&aid=1481844&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-1481242 ] win32print.WritePrinter() changes CR/LF to LF

[SourceForge.net <no...@so...>]

Bugs item #1481242, was opened at 2006-05-03 11:54
Message generated for change (Comment added) made by rupole
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1481242&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: DaveNation (dnation)
Assigned to: Nobody/Anonymous (nobody)
Summary: win32print.WritePrinter() changes CR/LF to LF

Initial Comment:
I am trying to send files containing raw PCL5 data
directly to a Laserjet printer.

I am using the following win32print calls :
  h = OpenPrinter('Laserjet')
  StartDocPrinter(h,1,('bosdoc',None,'RAW'))
  WritePrinter(h,buff)
  EndDocPrinter(h)

When directing the data directly to the printer, only
the first line is printed. 

When requesting StartDocPrinter() to spool to a file,
the output file is identical to the input file except
all CR/LF pairs have been changed to single LF characters.

(In PCL5, sending CR resets the x co-ord.)

When making the same calls through VB6, the spooled
file still contains the CR/LF pair, which makes me
think it is the Python interface code that is removing
the CR character.

----------------------------------------------------------------------

>Comment By: Roger Upole (rupole)
Date: 2006-05-04 04:34

Message:
Logged In: YES 
user_id=771074

WritePrinter doesn't do any manipulation on the data passed 
to it.  You don't specify where buff comes from, but if 
you're reading it from a file, make sure it's opened in 
binary mode.  Otherwise, it's treated as text and CR/LF
is automatically translated to LF.

        Roger


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1481242&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-1481242 ] win32print.WritePrinter() changes CR/LF to LF

[SourceForge.net <no...@so...>]

Bugs item #1481242, was opened at 2006-05-03 16: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=1481242&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: DaveNation (dnation)
Assigned to: Nobody/Anonymous (nobody)
Summary: win32print.WritePrinter() changes CR/LF to LF

Initial Comment:
I am trying to send files containing raw PCL5 data
directly to a Laserjet printer.

I am using the following win32print calls :
  h = OpenPrinter('Laserjet')
  StartDocPrinter(h,1,('bosdoc',None,'RAW'))
  WritePrinter(h,buff)
  EndDocPrinter(h)

When directing the data directly to the printer, only
the first line is printed. 

When requesting StartDocPrinter() to spool to a file,
the output file is identical to the input file except
all CR/LF pairs have been changed to single LF characters.

(In PCL5, sending CR resets the x co-ord.)

When making the same calls through VB6, the spooled
file still contains the CR/LF pair, which makes me
think it is the Python interface code that is removing
the CR character.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1481242&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-1465566 ] Build 208 - binary installer doesn't work with Python 2.5a1

[SourceForge.net <no...@so...>]

Bugs item #1465566, was opened at 2006-04-06 09:26
Message generated for change (Comment added) made by pmoore
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1465566&group_id=78018

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: installation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Paul Moore (pmoore)
Assigned to: Mark Hammond (mhammond)
Summary: Build 208 - binary installer doesn't work with Python 2.5a1

Initial Comment:
The installer for build 208 -
pywin32-208.win32-py2.5.exe - doesn't work with the
newly released Python 2.5a1 binaries. (Windows XP Pro,
SP2).

The installer fails immediately with "Running the
pre-installation script failed".

I've checked this on 2 machines. There are no other
Python packages installed, beyond the base Python 2.5a1.

----------------------------------------------------------------------

>Comment By: Paul Moore (pmoore)
Date: 2006-04-27 17:44

Message:
Logged In: YES 
user_id=113328

This is fixed in Python 2.5a2 - it wasn't a pywin32 bug.

----------------------------------------------------------------------

Comment By: Paul Moore (pmoore)
Date: 2006-04-06 17:41

Message:
Logged In: YES 
user_id=113328

Looks like preinstall script support might be broken in
bdist_wininst. I've tried a simple example, and the
resulting installer fails in the same way.

I've raised a bug for Python (http://www.python.org/sf/1465834).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1465566&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-1476208 ] 208/py2.3: Registry ToolbarDebugging-Bar964

[SourceForge.net <no...@so...>]

Bugs item #1476208, was opened at 2006-04-25 17:58
Message generated for change (Settings changed) made by kxroberto
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1476208&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: 208/py2.3: Registry ToolbarDebugging-Bar964

Initial Comment:
After some debugging sessions (pywin.debuger.pm()...
some irregular "not pumping" states as it happens
sometime ..) there are about 1000 of
ToolbarDebugging-BarXXX folders filed up in the registry:

some 20 in "Pythonwin Debugger"

and some 900+ in "Python for Win32"

Starting and exiting Pythonwin very slow (thus always
saves all?)

robert


---
PythonWin 2.3.5 (#62, Feb  8 2005, 16:23:02) [MSC
v.1200 32 bit (Intel)] on win32.
Portions Copyright 1994-2004 Mark Hammond
(mha...@sk...) - see 'Help/About
PythonWin' for further copyright information.
>>> 

----------------------------------------------------------------------

Comment By: kxroberto (kxroberto)
Date: 2006-04-26 10:39

Message:
Logged In: YES 
user_id=972995

that massive accumulation happened definitely during using
208 yesterday - within one or some sessions within hours.
The debugger was a few times in strange states. See below.

Maybe the difference is also, that they accumulate in
"Python for Win32" and not in "Pythonwin Debugger"?

Yet, I used the debugger (also) with
pywin.debugger.pm()/.run() from the Interactive pane.

Yes, I may have tried to reenter the debugger while
debugging. There are usually "alread pumping" warings and
not allowed and so - as no sub-debugging is possible like in
pdb. The debugger also enters sometime into states, where it
freezes somehow on all attempts to run or step something and
just says "not pumping" - also while the debugger is
obviously not anymore active and I want to just run things.
Then I have to restart Pythonwin. 

Thus there may be a mode confusion problem behind that bug
or Pywin doesn't know correctly if its debugging or not ...

As the debugger is a complex thing, especially when
windowing apps are debugged, the debugger freeze / confusion
is acceptable. 
Yet the protection against that massive accumulation of
registry should maybe work on a lower level.

Reopened it - though the bug obviously happens only upon
intense use of the debugger. 
It took long to find out why Pywin startup _and_ exits _and_
enters/leaves the debugger very slow. 


----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2006-04-26 01:58

Message:
Logged In: YES 
user_id=14198

This should have been fixed a few builds ago (but sadly the
fix did not include deleting the bad entries).  Please try
deleting those keys (or just delete the parent key) and try
again - you should find only 20 or so are created (which is
normal).  Please reopen this bug if that is not the case.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1476208&group_id=78018

[pywin32-bugs] [ pywin32-Bugs-1476208 ] 208/py2.3: Registry ToolbarDebugging-Bar964

[SourceForge.net <no...@so...>]

Bugs item #1476208, was opened at 2006-04-25 17:58
Message generated for change (Comment added) made by kxroberto
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1476208&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: None
Priority: 5
Submitted By: kxroberto (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: 208/py2.3: Registry ToolbarDebugging-Bar964

Initial Comment:
After some debugging sessions (pywin.debuger.pm()...
some irregular "not pumping" states as it happens
sometime ..) there are about 1000 of
ToolbarDebugging-BarXXX folders filed up in the registry:

some 20 in "Pythonwin Debugger"

and some 900+ in "Python for Win32"

Starting and exiting Pythonwin very slow (thus always
saves all?)

robert


---
PythonWin 2.3.5 (#62, Feb  8 2005, 16:23:02) [MSC
v.1200 32 bit (Intel)] on win32.
Portions Copyright 1994-2004 Mark Hammond
(mha...@sk...) - see 'Help/About
PythonWin' for further copyright information.
>>> 

----------------------------------------------------------------------

>Comment By: kxroberto (kxroberto)
Date: 2006-04-26 10:39

Message:
Logged In: YES 
user_id=972995

that massive accumulation happened definitely during using
208 yesterday - within one or some sessions within hours.
The debugger was a few times in strange states. See below.

Maybe the difference is also, that they accumulate in
"Python for Win32" and not in "Pythonwin Debugger"?

Yet, I used the debugger (also) with
pywin.debugger.pm()/.run() from the Interactive pane.

Yes, I may have tried to reenter the debugger while
debugging. There are usually "alread pumping" warings and
not allowed and so - as no sub-debugging is possible like in
pdb. The debugger also enters sometime into states, where it
freezes somehow on all attempts to run or step something and
just says "not pumping" - also while the debugger is
obviously not anymore active and I want to just run things.
Then I have to restart Pythonwin. 

Thus there may be a mode confusion problem behind that bug
or Pywin doesn't know correctly if its debugging or not ...

As the debugger is a complex thing, especially when
windowing apps are debugged, the debugger freeze / confusion
is acceptable. 
Yet the protection against that massive accumulation of
registry should maybe work on a lower level.

Reopened it - though the bug obviously happens only upon
intense use of the debugger. 
It took long to find out why Pywin startup _and_ exits _and_
enters/leaves the debugger very slow. 


----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2006-04-26 01:58

Message:
Logged In: YES 
user_id=14198

This should have been fixed a few builds ago (but sadly the
fix did not include deleting the bad entries).  Please try
deleting those keys (or just delete the parent key) and try
again - you should find only 20 or so are created (which is
normal).  Please reopen this bug if that is not the case.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1476208&group_id=78018