[wx-dev] [all] scrolled windows and panels

[Julian Smart]

Vadim Zeitlin wrote:
> On Thu, 05 Apr 2007 09:13:31 +0100 Julian Smart <julian at anthemion.co.uk> wrote:
>
> JS> In my StoryLines app I have a class derived from wxScrolledWindow which 
> JS> for the most part doesn't have children, and must accept the focus. But 
> JS> sometimes a temporary control will be created on the window to allow 
> JS> text editing in situ. Which scrolled window would I choose? I guess 
> JS> wxScrolledControl, so that it accepts focus, and I would have to deal 
> JS> with tab traversal myself if required.
>
>  Sorry, I don't understand: why would you need tab traversal at all in this
> case? When it doesn't have children, there is nothing to traverse and when
> it shows the embedded text control there is only one child and pressing TAB
> usually hides it anyhow. So while I agree that you would probably use
> wxScrolledControl/Canvas I don't quite understand why should you deal with
> tab traversal at all?
>   
You're probably right, I can't think of a reason to use tab traversal on 
this particular window,
but I wouldn't rule out having multiple controls on it in future. For 
example, say I decided to
implement all the cards on my window as text controls instead of drawing 
them myself
as I do now. I would still want to be able to focus the underlying 
window in order to do
various operations, such as scrolling using the keyboard, but it would 
be nice to have tab
traversal work as well.
> JS> Couldn't we just have a style and/or accessor to change the tab 
> JS> traversal behaviour?
>
>  This is incompatible with the existing AcceptsFocus(): if we had a
> "accepts focus" flag in wxWindow, overriding AcceptsFocus() in derived
> classes would stop working (worse, it would silently stop working).
>   
Say we had SetAcceptFocus/GetAcceptFocus, with a 3-value enum for
undefined/accept focus/don't accept focus, then if undefined is set (the 
default),
the value returned by AcceptsFocus is used.
> JS> I do think that making the user choose between two similarly-named
> JS> classes is going to introduce undesirable complexity, which I'd like to
> JS> see avoided if possible. (I can see that deriving from a panel is
> JS> conceptual overkill in some cases, but the advantage is simplicity of
> JS> API and reduced confusing choice.)
>
>  OTOH if you keep a single wxScrolledPanel (current wxScrolledWindow)
> class, you would have to do something to indicate that the control needs
> focus for itself, it seems to be impossible to do it automatically (the
> only heuristics I can think of is to accept focus in the window itself only
> if it has at most one child accepting focus itself -- but this is already
> quite complex and still probably doesn't cover all cases). While just by
> deriving from wxScrolledCanvas/Control it would be taken care of.
>   
The good thing about using accessors is that you do have dynamic 
control, even
if it's not automatic.
>  I do believe there is a fundamental difference between wxPanel, which is a
> control container, and a window which may happen to contain other windows
> but is mostly used for something else. And I don't see any simple way to
> make the same wxPanel class (via wxScrolledWindow) behave in both ways at
> once.
>   
The accessors would do it I think... and it would avoid another class, 
backward compatibility issues, etc.

Regards,

Julian