Menu
▾
▴
#2003 [event generate <FocusIn>] should work
FocusIn and FocusOut events generated by [event
generate] are now filtered out in TkFocusFilterEvent
unless their send_event field is assigned some magic
value.
Fortunately numeric send_event is allowed, but it would
be great if the appropriate magic value were inserted
as a default for send_event field by
TkBind.c:HandleEventGenerate().
I recognise that TkFocusFilterEvent does the important
work of not letting the weird Xwindow notion of focus
influence Tk's behavior. However, if an application
writer wants to generate FocusIn or FocusOut (perhaps
to make some widget think it has focus), he _should_ be
allowed to do so without exploring TkFocus.c to find
some GENERATED_EVENT_MAGIC there. It would save me a
few hours today if it just worked.
Discussion
Logged In: YES
user_id=72656
Is this perhaps something better fixed by improved doc notes?
Logged In: YES
user_id=241496
Maybe, but I don't think so. What reputation will Tk earn
for such a thing? "Use -sendevent 0x547321ac if you want
FocusIn/Out event to be REALLY generated".
I think it would be better to add this magic into
HandleEventGenerate(), so external focus events would be
filtered out as they are now (it's a right thing), but
[event generated] events would not be.
Of course, a doc note is still better than nothing.
Logged In: YES
user_id=72656
Interesting ... I assume that the intention is to have users
use the 'focus $widget', which should also trigger the
<FocusIn> event. Is there a reason not to use that instead
of trying the event generate? The GENERATED_EVENT_MAGIC
actually exists twice in the core, also in tkGrab.c, but
there with a different value.
Logged In: YES
user_id=241496
The filtering exists not to encourage the use of [focus]
(imagine the same logic applied to other events: "we may
really click a widget, that will generate ButtonPress"). The
reason for filtering is that Xwindow system sends FocusIn
and FocusOut itself; but Tk, like most toolkits, uses its
own focus model (more reasonable). Filtering thus prevents
us from receiving "system" X11 focus events, so FocusIn and
FocusOut we see are always generated by TkFocus.c itself. I
propose to let [event generate] generate this events as
well, which is now possible with -sendevent 0x547321ac only.
My reason to use [event generate .. <FocusIn>] was to make a
widget look like it has focus, when it wasn't really the
case. Such a generated event doesn't affect the keyboard
input direction: all internal focus machinery (TkFocus.c) is
not governed by FocusIn/FocusOut. TkFocus.c generates those
events, but doesn't depend on them itself.
You may find that my _goal_ in this example is "dangerous"
and "bad design". Such a position is described at the "good
girls don't" Wiki page. But I can argue that the purpose of
[event generate] is exactly this: make some widget think
that something has happened when it has not. Good girls
don't generate events at all, so [event generate] should be
removed from Tk if such a position is accepted :-)
I see no reason to deny generation of focus events via event generate. If this _is_ to be excluded then it should raise an error and not just pretend to work as happens now.
Fix comitted to enable event generate <FocusIn> and <FocusOut> in 8.6.
backport for 8.5.6 ?