[wx-dev] [all] scrolled windows and panels
Vadim Zeitlin
vadim at wxwindows.org
Thu Apr 5 05:07:59 PDT 2007
On Thu, 05 Apr 2007 13:01:39 +0100 Julian Smart <julian at anthemion.co.uk> wrote:
JS> but I wouldn't rule out having multiple controls on it in future. For
JS> example, say I decided to implement all the cards on my window as text
JS> controls instead of drawing them myself as I do now. I would still want
JS> to be able to focus the underlying window in order to do various
JS> operations, such as scrolling using the keyboard, but it would be nice
JS> to have tab traversal work as well.
Tricky. I'm not sure how does GTK+ handle this to be honest.
JS> > JS> Couldn't we just have a style and/or accessor to change the tab
JS> > JS> traversal behaviour?
JS> >
JS> > This is incompatible with the existing AcceptsFocus(): if we had a
JS> > "accepts focus" flag in wxWindow, overriding AcceptsFocus() in derived
JS> > classes would stop working (worse, it would silently stop working).
JS> >
JS> Say we had SetAcceptFocus/GetAcceptFocus, with a 3-value enum for
JS> undefined/accept focus/don't accept focus, then if undefined is set
JS> (the default), the value returned by AcceptsFocus is used.
Ok, I think we can do this... However it would be still very frustrating
IMO if it didn't work automatically, people are definitely going to be very
surprised if they can't give focus to their wxScrolledWindow for no good
reason. And I don't especially look forward updating wxGrid and generic
wxListCtrl, wxTreeCtrl, ... neither.
So I think we need to accept focus by default in wxPanel then and override
wxPanel::AddChild() to check if it has more than one window accepting focus
and call SetAcceptFocus(false) if it does. And, of course, also undo this
in wxPanel::RemoveChild().
How does this sound?
Thanks,
VZ
More information about the wx-dev
mailing list