BWidget breaks Tk entry behaviour

Logged In: YES
user_id=68433

Analysis of the problem:

The Tk behaviour for Entry widgets is implemented as a
special case in ::tk::TabToWindow:

# from tk/library/tk.tcl:
#
bind all <Tab> {tk::TabToWindow [tk_focusNext %W]}
# [ ... ]
proc ::tk::TabToWindow {w} {
if {[string equal [winfo class $w] Entry]} {
$w selection range 0 end
$w icursor end
}
focus $w
}

The BWidget library overrides this with a different binding:

# from bwidget/init.tcl:
#
bind all <Key-Tab> {focus [Widget::focusNext %W]}

where [Widget::focusNext] is (according to the comments)
"Same as tk_focusNext, but call Widget::focusOK (instead of
tk::focusOK)", and Widget::focusOK is "Same as tk_focusOK,
but handles -editable option and whole tags list."

Proposed fix:

Change the BWidget (and possibly Tk) <Tab> and <Shift-Tab>
bindings to generate <<TraverseIn>> and <<TraverseOut>>
virtual events.

Then redo the Entry-specific logic in tk::TabToWindow in a
<<TraverseIn>> binding.

This is also related to Tcllib bug #720024 "BWidget ComboBox
claims selection on FocusIn"

Logged In: YES
user_id=68433

The attached patch changes BWidget's <Tab> and <Shift-Tab>
bindings to generate <<TraverseOut>> and <<TraverseIn>>
virtual events.

It also adds a <<TraverseIn>> binding for the Tk [entry]
widget (fixing this bug), and replaces the ComboBox
<FocusIn> binding with a <<TraverseIn>> binding (fixing bug
#720024).

In addition: Currently, when a non-editable, empty ComboBox
widget receives keyboard focus, it changes the widget
background and foreground colors to make it look like
something is selected. This feature has been removed: no
other widget sets seem to do this, and it's hard to
implement correctly with the new framework.

Logged In: YES
user_id=13222

The patch by jenglish fixed the problem for me.

Logged In: YES
user_id=68433

Patch refreshed and committed.