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