#818 [grab] doesn't prevent interaction with ungrabbed entries

[Brent B. Welch]

OriginalBugID: 1510 Bug
Version: 8.1b1
SubmitDate: '1999-03-16'
LastModified: '1999-10-22'
Severity: MED
Status: Assigned
Submitter: pat
ChangedBy: hobbs
RelatedBugIDs: 1268 1158
OS: Windows 98
Machine: X86

Name:
Toni M. Rath

ReproducibleScript:
set test "This entry can be activated and altered by pressing <TAB>"
frame .f1
frame .f2
entry .f1.e -textvariable test
button .f2.b -text "exit" -command "destroy .f1"
pack .f1 -fill x
pack .f2
pack .f1.e -fill x
pack .f2.b
grab .f2
tkwait window .f1
puts $test
exit

Description: see below

ObservedBehavior:
There is a grab on the frame of the Exit-Button. It should not be
possible to alter the entry. It is in fact not possible to activate the
entry by clicking on it, but if you press TAB, the entry becomes
activated.

I have a script, that starts a procedure, when you press <RETURN> in an
entry. This should not happen, since I am trying to finish another
activity (I have
a grab on the necessary widgets), that should not be influenced by the
other
procedure (started by pressing <RETURN>).

DesiredBehavior:
If there is a grab on a part of a window, it should not be possible to
interact
with other parts of the window!

The error the user reported is a litle mis guided, however it does reval a problem with grab on Windows. Running the provided script on Unix and Windows will show the diufference. Related bu ID 1268. 03/25/1999 15:49 - surles -
----
Related bug IDs 1268 1158

[Donal K. Fellows]

Grabs don't affect keyboard focus (well, not really) and this is due to the way that Tk manages focus (the easiest alternative is *much* worse, as users of the Athena widget set can attest.) Hence you have to take care of making sure that the focus is correctly managed yourself.

[Jeffrey Hobbs]

Logged In: YES
user_id=72656

Regardless, there should be no keyboard interaction possible
in the entry.

[Donal K. Fellows]

Logged In: YES
user_id=79902

No, it has been the policy of Tk for a long time (since at
least 4.0; I've not got personal experience enough to say
before that) that KeyPress/KeyRelease events are not subject
to grabs. I'm extremely unwilling to change this, especially
as I think the policy is correct.

Note that if the grab is set on a toplevel, you can't focus
into another toplevel and work there. And fixing the focus
in the sort of situation discussed here can be done by
binding Tab intelligently on the toplevel.