Re: [lmi] wx-2.9.5 tab navigation [Was: wx-2.9.5-rc1 regression: proposed patch(es)]

[Vadim Zeitlin]

On Tue, 23 Jul 2013 10:00:34 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2013-07-23 00:46Z, Vadim Zeitlin wrote:
GC> > 
GC> >  I've fixed this now in http://trac.wxwidgets.org/changeset/74583
GC> 
GC> I haven't tested that yet, but let me mention another issue and ask
GC> whether this changeset will fix it. (I suspect that the radiobox
GC> changes won't affect it, but perhaps the change in "containr.h" will.)

 Unfortunately no, this was a different bug or rather two other different
ones. But they should be both fixed now, by

        http://trac.wxwidgets.org/changeset/74585

and

        http://trac.wxwidgets.org/changeset/74586


 The first bug manifested itself only in presence of a static box which was
enabled itself but whose children were all disabled. In passing, I think it
would be better, from the UI point of view, to disable the static box
itself in this case, but I realize that this might be non-trivial to do
and, anyhow, TAB navigation should work in any case.

 The second bug was semantically similar as it affected radio boxes in the
same case, but happened in a different part of the code because radio boxes
are not implemented in the way one might naively expect in wxWidgets, hence
they have their own specific problems. The only thing worth noticing here
is that I thought about the possibility of this bug occurring when writing
the commit message of

        http://trac.wxwidgets.org/changeset/74583

but discarded this possibility as being unlikely. I should have been more
diligent...


GC> Let me mention a wx-2.9.3 (not 2.9.5) issue on this notebook tab
GC> that was never noticed before, just in case you restore that old
GC> version's behavior. With that old version, all controls were
GC> reachable with the keyboard, but it required two presses of the
GC> Tab key to advance past the "Term rider" groupbox, and two presses
GC> of shift-Tab to move backward past "Honeymoon".

 This was due to the bug fixed in r74586, we never took into account the
state of the radio box items into account when determining its ability to
focus before. So the focus was actually given to the "Specified amount
changes" radio box itself after the first tab press and was visually lost.

 Thanks again for your testing and please let me know if you find anything
else,
VZ