[Tcl-bugs] [ tktoolkit-Bugs-2896605 ] Change to grab on windows breaks application behaviour

[SourceForge.net <no...@so...>]

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: obsolete: 8.5.7
Status: Open
Resolution: None
Priority: 9
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: 2010-01-06 23:15

Message:
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


----------------------------------------------------------------------

Comment By: Donal K. Fellows (dkf)
Date: 2010-01-06 21:58

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

----------------------------------------------------------------------

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