#1059 Infinite loop of focus events

[Christopher Nelson]

In what I believe is a fairly typical structure for handling mega-widgets, I get an infinite loop of
focus events which, in my particular case, constantly selects the only character in an entry so
that you can't type more. The attached script demonstrates.

I'm running on UNIX with 8.4a3 (well, a late snapshot of a4, I'm about to get the Real Thing).
Bruce Hartweg <brhartweg@bigfoot.com> says this works OK for him "under 98SE with version
8.3.3 (from ActiveTcl 8.3.3.2)".

[Christopher Nelson]

Script to show battling focus bindings

[Christopher Nelson]

Logged In: YES
user_id=107514

When I said "a late snapshot of a4", I meant "a3". Sorry.

[Christopher Nelson]

Logged In: YES
user_id=107514

OK. It seems to work for me, too, on NT w/ 8.4a3. 'Guess it's a UNIX-only issue; Specifically, I'm running
on Solaris where `uname -a` returns

SunOS urchin 5.8 Generic_108528-05 sun4u sparc SUNW,UltraSPARC-IIi-Engine

[Jeffrey Hobbs]

Logged In: YES
user_id=72656

Nothing mysterious here. On Unix, the message box is coded
such that it returns focus to the last element. That
is .f2. The test is rigged to want to give focus to .f1.
Each of those has a FocusIn that sets and 'after idle' to
set focus to their interior bits. Both focuses get called,
the idle events hit - and whammo, a loop. I'm not sure
what the best solution is, but this is a clearly coded loop
condition.

[Christopher Nelson]

Logged In: YES
user_id=107514

Perhaps the behavior is not mysterious but neither is it desireable. The test is not "rigged;" it represents a
boiled-down validation routine which visits each widget, validates it, and sets focus to the first bad
widget. The scenario described and coded is for a user entering the first value, then the second, then
clicking "OK" to begin the validation. If the first widget's contents were invalid, we want to set focus there
to give the user one less thing to do before fixing the bad value.

I think it's wonderful that the message box tries to be a good citizen and put focus and grab back where it
was BUT, when tk_messageBox returns, that should all be done; there should be no outstanding events for
my code to conflict with.

I found that by putting an [update] after the [tk_messageBox] in my [oops] proc, I could get
correct/desired behavior. ([update idletasks] was _not_ sufficient!) BUT, it doesn't seem reasonable
that every call to [tk_messageBox] should have to be followed by [update] if you might be using
megawidgets.

So, does ::tk::RestoreFocusGrab need an [update] in it? Is there something wrong with [focus] that
[update idletasks] is not sufficient to update the focus? Is there something that I do with -takefocus for
the frame or the entry in the megawidget to make this behave correctly?