wxSizerItem used for painted (solid) areas
ATS
asteinarson at gmail.com
Sat Mar 15 16:09:01 PDT 2008
> > Of course, at the root of the wxSizer tree (a full layout)
> > there is a layout manager that must take care of painting
> > these items.
>
> It can be done simply by the EVT_PAINT handle for the window owning the
> sizer. It can use the siter item to get the rect to be painted.
That's how it works yes.
> > Now... putting spacers items into a wxWrapSizer we see that
> > items of type A should be peeled off (when first or last on
> > a line).
>
> Why? I would think that if there is a spacer it should always be
> represented as empty space.
There's a flag passed to the ctor that selects to do this or not. When
wrapping a number of toolbars on lines in a narrow window, it looks
weird if the first toolbar on line 2,3,... is indented but the one
on line 1 is not.
Compare it to reading a text, It's easier if the left column is
left aligned while the right column may have trailing spaces.
> > Items of type B should stay in the sizer also when first
> > or last on the line.
>
> On the other hand, it is just as easy to use a real wxWindow that paints
> itself and use that in place of having the parent paint on the empty
Possible yes, but it doesn't fit with how the layout manager was designed.
In a layout with many edges, drag handles, toolbar separators, micro
buttons, you end up with a lot of wxWindow:s used for quite simple things.
A derived wxSizerItem used in this role save uses a fraction of the space
and no system resources.
Regards
// ATS.
More information about the wx-dev
mailing list