wxruby users - Mar 2009 - StaticText-only Notebook page eats tab key

I''m working on the keyboard interface for a small application. The app
has several controls on a Panel. One of those controls is a Notebook
with 4 pages, each of which is another panel. Three of the tab panels
contain ListCtrls, the fourth has only StaticText controls.

The Notebook is in the middle of the tab order. When one of the ListCtrl
tabs is selected, the tab order progresses normally: through each
control before the notebook, then to the notebook''s tab, then to the
control(s) on that page of the notebook, then back off the notebook to
the controls later in the tab order. (The progression with shift-tab is
a bit weird -- always to the tab first, *then* backwards through the
controls on that page, then back through the controls before the
notebook. But I can live with that.)

The problem is with the fourth tab that has only StaticText controls. If
that tab is visible, the tab progression stops once the notebook is
reached. The focus goes to the tab itself like normal, then the next tab
key entry makes the focus disappear, and further tab keystrokes do
nothing.

Sample code below demonstrates the problem. I hadn''t noticed it in my
real app, but in this sample it looks like the focus is going to one of
the controls on the *other*, hidden page of the notebook, then getting
stuck, presumably since that control is hidden and not supposed to
accept keystrokes.

Is there something I''m doing wrong? Is there some window other than a
Panel that is better for holding controls in Notebooks? Or is this just
the way the Notebook widget works, and I have to live with it? (I know I
could put a control that accepts keystrokes on that page to work around
the problem, but that would have no useful function on the page in
question in the actual app.)

David Peoples

#!/usr/bin/env ruby

require ''wx''
include Wx

class MainFrame < Frame
  
  def initialize(title)
    super(nil, :title => title)
    panel_1 = Panel.new(self)
    box_1 = BoxSizer.new(VERTICAL)
    panel_1.sizer = box_1

    box_1.add(TextCtrl.new(panel_1, ID_ANY), 0, ALIGN_LEFT | ALL, 10)
    box_1.add(TextCtrl.new(panel_1, ID_ANY), 0, ALIGN_LEFT | ALL, 10)

    nb_1 = Notebook.new(panel_1, ID_ANY, DEFAULT_POSITION, DEFAULT_SIZE,
NB_TOP, "notebook_1")
    box_1.add(nb_1, 0, ALIGN_LEFT | ALL, 10)

    panel_n1 = Panel.new(nb_1)
    box_n1 = BoxSizer.new(VERTICAL)
    panel_n1.sizer = box_n1
    box_n1.add(TextCtrl.new(panel_n1, ID_ANY), 0, ALIGN_LEFT | ALL, 10)
    box_n1.add(TextCtrl.new(panel_n1, ID_ANY), 0, ALIGN_LEFT | ALL, 10)

    panel_n2 = Panel.new(nb_1)
    box_n2 = BoxSizer.new(VERTICAL)
    panel_n2.sizer = box_n2
    box_n2.add(StaticText.new(panel_n2, ID_ANY, ''Text 1''), 0,
ALIGN_LEFT
| ALL, 10)
    box_n2.add(StaticText.new(panel_n2, ID_ANY, ''Text 2''), 0,
ALIGN_LEFT
| ALL, 10)

    nb_1.add_page(panel_n1, "Tab 1", true)
    nb_1.add_page(panel_n2, "Tab 2", false)
    
    box_1.add(TextCtrl.new(panel_1, ID_ANY), 0, ALIGN_LEFT | ALL, 10)

  end
  
end

Wx::App.run do 
  self.app_name = ''TestNotebook''
  frame = MainFrame.new("Test notebook tab order")
  frame.show
end

I forgot to mention that I''m testing this on Linux, so this is
wxGTK-2.8.9 and the wxruby 2.0.0 gem.

David

Hi David

David Peoples wrote:
> I''m working on the keyboard interface for a small application. The
app
> has several controls on a Panel. One of those controls is a Notebook
> with 4 pages, each of which is another panel. Three of the tab panels
> contain ListCtrls, the fourth has only StaticText controls.
>
>
>   
...
> The problem is with the fourth tab that has only StaticText controls. If
> that tab is visible, the tab progression stops once the notebook is
> reached. The focus goes to the tab itself like normal, then the next tab
> key entry makes the focus disappear, and further tab keystrokes do
> nothing.
>
> Sample code below demonstrates the problem. I hadn''t noticed it in
my
> real app, but in this sample it looks like the focus is going to one of
> the controls on the *other*, hidden page of the notebook, then getting
> stuck, presumably since that control is hidden and not supposed to
> accept keystrokes.
Thanks for the report and the example. I get the same thing on GTK. I 
spent a little time with it but couldn''t get to the bottom of
what''s
happening here. As point 6, second list here says, tab traversal is 
platform dependent:

http://www.wxwidgets.org/docs/technote/wxaccesstips.htm

So I''m not sure whether this is a wxWidgets bug, or a problem for Gtk 
apps in general which have a notebook pane containing no controls which 
accepts focus (see Window#accepts_focus).

It''s probably best to work around it by avoiding problematic layouts,
or
you may be able to code around it by using various classes / events 
related to focus and keyboard navigation (FocusEvent, ChildFocusEvent 
and NavigationKeyEvent). NB FocusEvent#get_window is missing in 2.0.0 
but fixed in SVN.

If you''re able to get to figure it out, please do post a bug to the 
wxWidgets tracker.

http://trac.wxwidgets.org/

a

On Tue, 2009-03-10 at 18:50 +0000, Alex Fenton wrote:
> Hi David
> 
> Thanks for the report and the example. I get the same thing on GTK. I 
> spent a little time with it but couldn''t get to the bottom of
what''s
> happening here. As point 6, second list here says, tab traversal is 
> platform dependent:
> 
> http://www.wxwidgets.org/docs/technote/wxaccesstips.htm
> 
> So I''m not sure whether this is a wxWidgets bug, or a problem for
Gtk
> apps in general which have a notebook pane containing no controls which 
> accepts focus (see Window#accepts_focus).
> 
> It''s probably best to work around it by avoiding problematic
layouts, or
> you may be able to code around it by using various classes / events 
> related to focus and keyboard navigation (FocusEvent, ChildFocusEvent 
> and NavigationKeyEvent). NB FocusEvent#get_window is missing in 2.0.0 
> but fixed in SVN.
> 
> If you''re able to get to figure it out, please do post a bug to
the
> wxWidgets tracker.
> 
> http://trac.wxwidgets.org/
> 
> a
> 
Alex,

Thanks for your help. I have one more observation / clue about this
problem.

I hooked up the ChildFocusEvent to report what has focus when the tab
sequence gets trapped, and my original guess (that the focus is going to
one of the controls on a hidden page) was wrong. The focus is going to
the Panel itself of the visible tab page. I don''t understand C++ well
enough to make much of the wxWidgets code so I won''t be the source of a
patch, but perhaps that clue can help someone else find the problem.

(I think I''ve seen evidence that the tab sequence won''t jump
from a set
of controls on one panel to the controls on another panel, just keeps
cycling through the first panel''s set. If true, that might be related
to
this issue. But I can''t reproduce the demonstrating code, so maybe I
imagined that (or some other bug in my code caused it).

I''m working around the problem right now by using ListCtrls in report
mode to display the info that had been in the static text controls. It
is ugly but it works.

I''ll think some more about using the ChildFocusEvent and
NavigationKeyEvent events to force the focus beyond the trap. My first
attempt kept getting stuck in a loop in shift-tab because of the
notebook''s weird sequence when tabbing backwards. But I might have
given
up too quickly.

David