#2706 Change to grab on windows breaks application behaviour

[Colin McDonald]

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.

[Don Porter]

Can you confirm this is about the
changes made fixing Bug 1847002 ?

[Colin McDonald]

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.

[Donal K. Fellows]

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...

[Colin McDonald]

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

[Don Porter]

status for 8.5.9 ?

[Colin McDonald]

See Tk bug #3414089 for another problem introduced by the #1847002 windows grab handling changes

[Colin McDonald]

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.