From: SourceForge.net <no...@so...> - 2009-11-12 17:33:57
|
Bugs item #2896605, was opened at 2009-11-12 13:50 Message generated for change (Comment added) made by cjmcdonald You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112997&aid=2896605&group_id=12997 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: 56. [grab] Group: current: 8.5.7 Status: Open Resolution: None Priority: 7 Private: No Submitted By: Colin McDonald (cjmcdonald) Assigned to: Pat Thoyts (patthoyts) Summary: Change to grab on windows breaks application behaviour Initial Comment: 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. ---------------------------------------------------------------------- >Comment By: Colin McDonald (cjmcdonald) Date: 2009-11-12 17:33 Message: 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. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2009-11-12 15:51 Message: Can you confirm this is about the changes made fixing Bug 1847002 ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112997&aid=2896605&group_id=12997 |