[wx-dev] Re: GTK: Tab navigation (EVT_CHAR_HOOK)

[ATS]

> 
> > > On implementing EVT_CHAR_HOOK (to give controls a first go at key
> > > presses even inside dialogs), I noted that TAB navigation for
> > > certain controls (wxComboBox) is not working. You cannot tab out of
> > > a combo to the next control.
> > 
> > 1. Which wx version are you talking about?
> > 2. How can we reproduce it in the samples? It seems to work just fine 
> > for me in samples/widgets, both on the trunk and 2.8 branch.
> > 3. If it's the trunk, is it something broken by r52476?
> > 
> 
> I'm on trunk. I tested building the widgets sample and then I can tab
> past the combos. 
> 

OK, I tracked it down, it's a regression in trunk. If one _never_ calls
wxWindow::SetFocus on the combo, things work fine. But if at dialog setup 
time on calls SetFocus, the tab chain is broken. And, of course the XRC
handler does this if we have the 'focus' attribute. 

Inside wxWindow::SetFocus() there is these lines of code: 

        // wxWindow::SetFocus() should really set the focus to
        // this control, whatever the flags are
        if (!GTK_WIDGET_CAN_FOCUS(m_widget))
            GTK_WIDGET_SET_FLAGS(m_widget, GTK_CAN_FOCUS);

For a GTK container prepared by 'native' GTK, we mess up things by 
changing this flag. GTK knows what it does when it does _not_ set the
flag.

It worked in older versions because wxComboBox had an override for 
SetFocus which side stepped this error.

Two ways of fixing it:

1 - Take away the call to GTK_WIDGET_SET_FLAGS(...) for a GTK container.

2 - Restore wxComboBox::SetFocus() method. 


I really think 1 is to prefer. If GTK creates the container widget 
without this flag, it does so because that's the way it's supposed to
operate.


Regards
// ATS: