Tk Library Source Code

package require BWidget

entry .w1
ComboBox .w2
entry .w3

pack .w1 .w2 .w3
focus .w1

While 'tabbing forward' over the entries (with the Tab
key), only one tab is needed, to leave the ComboBox
(.w2) and to have the focus on .w3. While 'tabbing
backward' (with Shift-Tab), there are two Shilft-Tab
events necessary, to go from .w2 to w1. 

Expected behaviour: For backward tabbing, only one
Shilft-Tab is needed, to go to the next (previous) widget.

Logged In: YES 
user_id=72656

This is fixed in the head - leaving it open based on
alternate idea from Joe.

Logged In: YES 
user_id=72656

I've added a hack that checks that we don't step into the
immediate parent if it is a proc (like a BWidget megawidget
would be).

Joe's idea that -takefocus should optionally allow a widget
name that you should redirect to sounds very good as a
better future solution, but would require more careful
rewriting of -takefocus handling.

File Added - 56887: bwidget-backtab.patch

Logged In: YES 
user_id=68433

Attached patch changes Widget::focusPrev to skip over
non-leaf widgets.  This makes shift-tab work correctly for
ComboBoxes and other megawidgets.
This needs to be reviewed very carefully: I'm not convinced
that the patched version always terminates (I don't *think*
an infinite loop is possible, but can't prove it).

Logged In: YES 
user_id=68433

Hm.  In what way does it not work?

Anyway, taking a closer look, this isn't the right solution
after all.  Widget::focusNext / Widget::focusPrev would work
correctly if the outer frame had '-takefocus 0' and the
inner entry widget had '-takefocus 1', but due to some
BWidget voodoo that I don't quite understand the -takefocus
option on both widgets are tied together.  Plus -- as Rolf
mentioned -- from the user's point of view it's preferable
to set -takefocus on the ComboBox itself, not on one of its
components.  (BTW, I think [ComboBox .cb -takefocus 0] will
do the right thing, as will [ComboBox .cb -takefocus ""],
but [ComboBox .cb -takefocus 1] causes a problem with
Widget::focusPrev).

Next possible solution: modify Widget::focusPrev to never
transfer focus from a descendant to an ancestor.  I think
this would be the right thing in almost all circumstances 
-- typically only "leaf" widgets take keyboard focus,
container widgets do not -- is there a counterexample?

And an observation: the focus traversal code is deeply
confusing :-(

Logged In: YES 
user_id=13222

No. First it does not work for me. And second, if I use
   $myCombobox configure -takefocus 0
I would expect, that the widget doesn't take the focus any
more during keyboard traversal.

Logged In: YES 
user_id=68433

If you set
.w2 configure -takefocus ""
(instead of the default '-takefocus 1'), then Tk / BWidget's
standard traversal algorithm does the right thing:
[tk_focusNext .w1] is .w2.e (instead of .w2), and
[tk_focusPrev .w2.e] is .w1 (instead of .w2).

Perhaps the right fix is to make '-takefocus ""' the default
on the frame widget.  Does that sound reasonable?

Logged In: YES 
user_id=72656

see also 756334

Logged In: YES 
user_id=72656

This has to do with Widget::focusPrev moving the focus from 
the .w2.e true entry to .w2 frame, which has -takefocus 
acceptable on it since it is a megawidget.  That must be 
improved to check that we aren't just moving from a bwidget 
child to its megawidget parent container.