Bugs item #1598678, was opened at 2006-11-17 19:20
Message generated for change (Comment added) made by rupole
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1598678&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
Private: No
Submitted By: Ross Ridge (ross_ridge)
Assigned to: Roger Upole (rupole)
Summary: PyConsoleScreenBuffer doesn't keep reference to handle
Initial Comment:
PyConsoleScreenBufferType doesn't keep a reference
to the PyHANDLE passed in when constructing an object.
If you run the following test case:
import win32con
import win32file
import win32console
h = win32file.CreateFile("CONIN$",
win32con.GENERIC_READ
| win32con.GENERIC_WRITE,
win32con.FILE_SHARE_READ
| win32con.FILE_SHARE_WRITE,
None, win32con.OPEN_EXISTING,
0, None)
c = win32console.PyConsoleScreenBufferType(h)
c.GetConsoleMode() # call 1
h = None
c.GetConsoleMode() # call 2
You get the following output:
Traceback (most recent call last):
File "test2.py", line 12, in ?
c.GetConsoleMode() # call 2
pywintypes.error: (6, 'GetConsoleMode', 'The handle is invalid.')
The handle is invalid because it was closed after the
previous line ("h = None") was executed despite the
fact that "c" should still be maintaining a
reference to the PyHANDLE object it's using.
----------------------------------------------------------------------
>Comment By: Roger Upole (rupole)
Date: 2006-12-11 07:31
Message:
Logged In: YES
user_id=771074
Originator: NO
This is fixed in win32consolemodule.cpp rev 1.9.
----------------------------------------------------------------------
Comment By: Roger Upole (rupole)
Date: 2006-11-21 21:06
Message:
Logged In: YES
user_id=771074
Originator: NO
It might be more consistent for the object to call
DuplicateHandle internally. That way both types of
handles could still be treated exactly the same.
Plus, the caller would still be responsible for the
original handle, so there would be no change from the
existing semantics. Does this sound reasonable to you ?
----------------------------------------------------------------------
Comment By: Ross Ridge (ross_ridge)
Date: 2006-11-19 14:51
Message:
Logged In: YES
user_id=1218032
Originator: YES
I don't expect PyConsoleScreenBuffer to manage the lifetime of the handle,
I expect PyHANDLE to do so. Since I'm passing a PyHANDLE object, not an
actual Win32 HANDLE value, to PyConsoleScreenBuffer, I expect the
PyConsoleScreenBuffer object to keep a reference to the PyHANDLE object so
that the PyHANDLE object can do it's job.
----------------------------------------------------------------------
Comment By: Roger Upole (rupole)
Date: 2006-11-18 11:52
Message:
Logged In: YES
user_id=771074
Originator: NO
The PyConsoleScreenBuffer object doesn't make any attempt to
manage the lifetime of the handle when it's created from an
existing handle. You can use h.Detach() to ensure that the
handle isn't closed prematurely, or win32api.DuplicateHandle
to make a copy of the handle.
Roger
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=551954&aid=1598678&group_id=78018
|