Tk Source Code

View Ticket
Login
Ticket UUID: 2896605
Title: Change to grab on windows breaks application behaviour
Type: Bug Version: obsolete: 8.5.7
Submitter: cjmcdonald Created on: 2009-11-12 13:50:11
Subsystem: 56. [grab] Assigned To: patthoyts
Priority: 9 Immediate Severity:
Status: Open Last Modified: 2011-11-10 19:25:25
Resolution: None Closed By:
    Closed on:
Description:
I have discovered that changes to the grab command on windows in tk 8.5.7 have broken some application behaviour, compared to 8.5.6 and all previous versions.

In my applications I have a home grown "busy" command.  Among other things this sets the wait cursor, and grabs mouse events and directs them to a frame with no mouse bindings.  This may be superceeded at some stage by the tk 8.6 builtin command, but for the moment I use it extensively.

The busy command is used for any long operations.  This includes initialising some complicated child application windows.  So the sequence is something like:

# Make busy
grab set ._busy

# Create new child application window

toplevel .app1
wm withdraw .app1

# Lots of application window initialisation....
# Then show new window & unbusy.

wm deiconify .app1
grab release ._busy

Unfortunately the changes to the grab command on windows in tk 8.5.7 mean that the "wm deiconify" forces a raise of the root window, which contains the grab frame.  So this is raised in front of and obscures the new child window the user has just invoked.

As I said, I use this busy mechanism extensively, including in a command dispatcher system, and I have not been able to think of a practical workaround yet.
User Comments: cjmcdonald added on 2011-11-10 19:25:25:
I also encountered another variation on these problems
recently.  I have a 3d visualisation application, which
includes a print option.  The print action works as follows:

1) The user clicks on the print button to invoke the print
configuration dialog.  It is modal, and takes a grab

2) After completing the dialog the user clicks OK.

3) To print the 3d display window the application has to snap
its contents.  So it raises the main display window to the front.

4) The window contents are snapped (img-window) and sent to
the printer.

5) If all is successful the grab is released and the print
dialog dismissed.  If there is a problem then the print dialog
displays the error and waits for input.

Since the #1847002 changes step 3 fails, because it won't
allow the main window to be raised in front whilst the print dialog
has a grab.  So the snapped output now includes the print
dialog on top of the main window.  It can be worked around by
releasing the print dialog grab before doing the
snap/print/status check.  But it is an example of the type of
code which had been working for many years, and is now broken
on windows.

cjmcdonald added on 2011-11-10 18:47:58:
See Tk bug #3414089 for another problem introduced by the #1847002 windows grab handling changes

dgp added on 2010-08-12 23:10:27:
status for 8.5.9 ?

cjmcdonald added on 2010-01-07 06:15:54:
I'm struggling with the changed behaviour, because it has introduced a linkage between the behaviour of "wm deiconify" and the grab state.  If a grab is set then invoking wm deiconify on one toplevel can raise another. This new behaviour causes my  problem, and:

- it is inconsistent across platforms, the unix implementation doesn't do it
- such a linkage between the commands is non-intuitive

dkf added on 2010-01-07 04:58:32:
That's a fair-sized patch, and it's not at all clear whether this can be fixed while keeping 1847002 fixed. Commenting to promote this in the mind of the only person likely understand what's been changed...

cjmcdonald added on 2009-11-13 00:33:56:
Yes, I can confirm that.

I have downloaded the 8.5.8 candidate sources.  Then in win/tkWinWm.c I have reverted the changes that were made between revision 1.124.2.2 and revision 1.124.2.3 for bug 1847002.  I did this manually, keeping other subsequent changes.  The resulting build does not have this problem.

dgp added on 2009-11-12 22:51:57:
Can you confirm this is about the
changes made fixing Bug 1847002 ?