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