]> git.saurik.com Git - wxWidgets.git/blob - docs/doxygen/overviews/sizer.h
Allow marking wxTreeBook nodes to expand initially in XRC.
[wxWidgets.git] / docs / doxygen / overviews / sizer.h
1 /////////////////////////////////////////////////////////////////////////////
2 // Name: sizer.h
3 // Purpose: topic overview
4 // Author: wxWidgets team
5 // RCS-ID: $Id$
6 // Licence: wxWindows licence
7 /////////////////////////////////////////////////////////////////////////////
8
9 /**
10
11 @page overview_sizer Sizers Overview
12
13 Classes: wxSizer, wxBoxSizer, wxStaticBoxSizer, wxGridSizer, wxFlexGridSizer,
14 wxGridBagSizer
15
16 Sizers, as represented by the wxSizer class and its descendants in the
17 wxWidgets class hierarchy, have become the method of choice to define the
18 layout of controls in dialogs in wxWidgets because of their ability to create
19 visually appealing dialogs independent of the platform, taking into account
20 the differences in size and style of the individual controls. Unlike the
21 original wxWidgets Dialog Editor, editors such as wxDesigner, DialogBlocks,
22 XRCed and wxWorkshop create dialogs based exclusively on sizers, practically
23 forcing the user to create platform independent layouts without compromises.
24
25 The next section describes and shows what can be done with sizers. The
26 following sections briefly describe how to program with individual sizer
27 classes.
28
29 For information about the wxWidgets resource system, which can describe
30 sizer-based dialogs, see the @ref overview_xrc.
31
32 @li @ref overview_sizer_idea
33 @li @ref overview_sizer_features
34 @li @ref overview_sizer_hiding
35 @li @ref overview_sizer_box
36 @li @ref overview_sizer_types
37 @li @ref overview_sizer_button
38
39
40 <hr>
41
42
43 @section overview_sizer_idea The Idea Behind Sizers
44
45 The layout algorithm used by sizers in wxWidgets is closely related to layout
46 systems in other GUI toolkits, such as Java's AWT, the GTK toolkit or the Qt
47 toolkit. It is based upon the idea of individual subwindows reporting their
48 minimal required size and their ability to get stretched if the size of the
49 parent window has changed. This will most often mean that the programmer does
50 not set the start-up size of a dialog, the dialog will rather be assigned a
51 sizer and this sizer will be queried about the recommended size. This sizer in
52 turn will query its children (which can be normal windows, empty space or other
53 sizers) so that a hierarchy of sizers can be constructed. Note that wxSizer
54 does not derive from wxWindow and thus does not interfere with tab ordering and
55 requires very few resources compared to a real window on screen.
56
57 What makes sizers so well fitted for use in wxWidgets is the fact that every
58 control reports its own minimal size and the algorithm can handle differences
59 in font sizes or different window (dialog item) sizes on different platforms
60 without problems. For example, if the standard font as well as the overall
61 design of Linux/GTK widgets requires more space than on Windows, the initial
62 dialog size will automatically be bigger on Linux/GTK than on Windows.
63
64 There are currently five different kinds of sizers available in wxWidgets. Each
65 represents either a certain way to lay out dialog items in a dialog or it
66 fulfills a special task such as wrapping a static box around a dialog item (or
67 another sizer). These sizers will be discussed one by one in the text below.
68 For more detailed information on how to use sizers programmatically, please
69 refer to the section @ref overview_sizer_box.
70
71
72 @section overview_sizer_features Common Features
73
74 All sizers are containers, that is, they are used to lay out one dialog item
75 (or several dialog items), which they contain. Such items are sometimes
76 referred to as the children of the sizer. Independent of how the individual
77 sizers lay out their children, all children have certain features in common:
78
79 <b>A minimal size</b>: This minimal size is usually identical to the initial
80 size of the controls and may either be set explicitly in the wxSize field of
81 the control constructor or may be calculated by wxWidgets, typically by setting
82 the height and/or the width of the item to -1. Note that only some controls can
83 calculate their size (such as a checkbox) whereas others (such as a listbox)
84 don't have any natural width or height and thus require an explicit size. Some
85 controls can calculate their height, but not their width (e.g. a single line
86 text control):
87
88 @image html overview_sizer_03.png
89
90 @image html overview_sizer_04.png
91
92 @image html overview_sizer_05.png
93
94 <b>A border</b>: The border is just empty space and is used to separate dialog
95 items in a dialog. This border can either be all around, or at any combination
96 of sides such as only above and below the control. The thickness of this border
97 must be set explicitly, typically 5 points. The following samples show dialogs
98 with only one dialog item (a button) and a border of 0, 5, and 10 pixels around
99 the button:
100
101 @image html overview_sizer_00.png
102
103 @image html overview_sizer_01.png
104
105 @image html overview_sizer_02.png
106
107 <b>An alignment</b>: Often, a dialog item is given more space than its minimal
108 size plus its border. Depending on what flags are used for the respective
109 dialog item, the dialog item can be made to fill out the available space
110 entirely, i.e. it will grow to a size larger than the minimal size, or it will
111 be moved to either the centre of the available space or to either side of the
112 space. The following sample shows a listbox and three buttons in a horizontal
113 box sizer; one button is centred, one is aligned at the top, one is aligned at
114 the bottom:
115
116 @image html overview_sizer_06.png
117
118 <b>A stretch factor</b>: If a sizer contains more than one child and it is
119 offered more space than its children and their borders need, the question
120 arises how to distribute the surplus space among the children. For this
121 purpose, a stretch factor may be assigned to each child, where the default
122 value of 0 indicates that the child will not get more space than its requested
123 minimum size. A value of more than zero is interpreted in relation to the sum
124 of all stretch factors in the children of the respective sizer, i.e. if two
125 children get a stretch factor of 1, they will get half the extra space each
126 <em>independent of whether one control has a minimal sizer inferior to the
127 other or not</em>. The following sample shows a dialog with three buttons, the
128 first one has a stretch factor of 1 and thus gets stretched, whereas the other
129 two buttons have a stretch factor of zero and keep their initial width:
130
131 @image html overview_sizer_07.png
132
133 Within wxDesigner, this stretch factor gets set from the @e Option menu.
134
135
136 @section overview_sizer_hiding Hiding Controls Using Sizers
137
138 You can hide controls contained in sizers the same way you would hide any
139 control, using the wxWindow::Show method. However, wxSizer also offers a
140 separate method which can tell the sizer not to consider that control in its
141 size calculations. To hide a window using the sizer, call wxSizer::Show. You
142 must then call Layout on the sizer to force an update.
143
144 This is useful when hiding parts of the interface, since you can avoid removing
145 the controls from the sizer and having to add them back later.
146
147 @note This is supported only by wxBoxSizer and wxFlexGridSizer.
148
149 @subsection overview_sizer_hiding_box wxBoxSizer
150
151 wxBoxSizer can lay out its children either vertically or horizontally,
152 depending on what flag is being used in its constructor. When using a vertical
153 sizer, each child can be centered, aligned to the right or aligned to the left.
154 Correspondingly, when using a horizontal sizer, each child can be centered,
155 aligned at the bottom or aligned at the top. The stretch factor described in
156 the last paragraph is used for the main orientation, i.e. when using a
157 horizontal box sizer, the stretch factor determines how much the child can be
158 stretched horizontally. The following sample shows the same dialog as in the
159 last sample, only the box sizer is a vertical box sizer now:
160
161 @image html overview_sizer_08.png
162
163 @subsection overview_sizer_hiding_static wxStaticBoxSizer
164
165 wxStaticBoxSixer is the same as a wxBoxSizer, but surrounded by a static box.
166 Here is a sample:
167
168 @image html overview_sizer_09.png
169
170 @subsection overview_sizer_hiding_grid wxGridSizer
171
172 wxGridSizer is a two-dimensional sizer. All children are given the same size,
173 which is the minimal size required by the biggest child, in this case the text
174 control in the left bottom border. Either the number of columns or the number
175 or rows is fixed and the grid sizer will grow in the respectively other
176 orientation if new children are added:
177
178 @image html overview_sizer_10.png
179
180 For programming information, see wxGridSizer.
181
182 @subsection overview_sizer_hiding_flexgrid wxFlexGridSizer
183
184 Another two-dimensional sizer derived from wxGridSizer. The width of each
185 column and the height of each row are calculated individually according to the
186 minimal requirements from the respectively biggest child. Additionally, columns
187 and rows can be declared to be stretchable if the sizer is assigned a size
188 different from the one it requested. The following sample shows the same dialog
189 as the one above, but using a flex grid sizer:
190
191 @image html overview_sizer_11.png
192
193
194 @section overview_sizer_box Programming with wxBoxSizer
195
196 The basic idea behind a wxBoxSizer is that windows will most often be laid out
197 in rather simple basic geometry, typically in a row or a column or several
198 hierarchies of either.
199
200 As an example, we will construct a dialog that will contain a text field at the
201 top and two buttons at the bottom. This can be seen as a top-hierarchy column
202 with the text at the top and buttons at the bottom and a low-hierarchy row with
203 an OK button to the left and a Cancel button to the right. In many cases
204 (particularly dialogs under Unix and normal frames) the main window will be
205 resizable by the user and this change of size will have to get propagated to
206 its children. In our case, we want the text area to grow with the dialog,
207 whereas the button shall have a fixed size. In addition, there will be a thin
208 border around all controls to make the dialog look nice and - to make matter
209 worse - the buttons shall be centred as the width of the dialog changes.
210
211 It is the unique feature of a box sizer, that it can grow in both directions
212 (height and width) but can distribute its growth in the main direction
213 (horizontal for a row) @e unevenly among its children. In our example case, the
214 vertical sizer is supposed to propagate all its height changes to only the text
215 area, not to the button area. This is determined by the @e proportion parameter
216 when adding a window (or another sizer) to a sizer. It is interpreted as a
217 weight factor, i.e. it can be zero, indicating that the window may not be
218 resized at all, or above zero. If several windows have a value above zero, the
219 value is interpreted relative to the sum of all weight factors of the sizer, so
220 when adding two windows with a value of 1, they will both get resized equally
221 much and each half as much as the sizer owning them. Then what do we do when a
222 column sizer changes its width? This behaviour is controlled by @e flags (the
223 second parameter of the Add() function): Zero or no flag indicates that the
224 window will preserve it is original size, wxGROW flag (same as wxEXPAND) forces
225 the window to grow with the sizer, and wxSHAPED flag tells the window to change
226 it is size proportionally, preserving original aspect ratio. When wxGROW flag
227 is not used, the item can be aligned within available space. wxALIGN_LEFT,
228 wxALIGN_TOP, wxALIGN_RIGHT, wxALIGN_BOTTOM, wxALIGN_CENTER_HORIZONTAL and
229 wxALIGN_CENTER_VERTICAL do what they say. wxALIGN_CENTRE (same as
230 wxALIGN_CENTER) is defined as (wxALIGN_CENTER_HORIZONTAL |
231 wxALIGN_CENTER_VERTICAL). Default alignment is wxALIGN_LEFT | wxALIGN_TOP.
232
233 As mentioned above, any window belonging to a sizer may have a border, and it
234 can be specified which of the four sides may have this border, using the wxTOP,
235 wxLEFT, wxRIGHT and wxBOTTOM constants or wxALL for all directions (and you may
236 also use wxNORTH, wxWEST etc instead). These flags can be used in combination
237 with the alignment flags above as the second parameter of the Add() method
238 using the binary or operator |. The sizer of the border also must be made
239 known, and it is the third parameter in the Add() method. This means, that the
240 entire behaviour of a sizer and its children can be controlled by the three
241 parameters of the Add() method.
242
243 @code
244 // We want to get a dialog that is stretchable because it
245 // has a text ctrl at the top and two buttons at the bottom.
246
247 MyDialog::MyDialog(wxFrame *parent, wxWindowID id, const wxString &title )
248 : wxDialog(parent, id, title, wxDefaultPosition, wxDefaultSize,
249 wxDEFAULT_DIALOG_STYLE | wxRESIZE_BORDER)
250 {
251 wxBoxSizer *topsizer = new wxBoxSizer( wxVERTICAL );
252
253 // create text ctrl with minimal size 100x60
254 topsizer->Add(
255 new wxTextCtrl( this, -1, "My text.", wxDefaultPosition, wxSize(100,60), wxTE_MULTILINE),
256 1, // make vertically stretchable
257 wxEXPAND | // make horizontally stretchable
258 wxALL, // and make border all around
259 10 ); // set border width to 10
260
261 wxBoxSizer *button_sizer = new wxBoxSizer( wxHORIZONTAL );
262 button_sizer->Add(
263 new wxButton( this, wxID_OK, "OK" ),
264 0, // make horizontally unstretchable
265 wxALL, // make border all around (implicit top alignment)
266 10 ); // set border width to 10
267 button_sizer->Add(
268 new wxButton( this, wxID_CANCEL, "Cancel" ),
269 0, // make horizontally unstretchable
270 wxALL, // make border all around (implicit top alignment)
271 10 ); // set border width to 10
272
273 topsizer->Add(
274 button_sizer,
275 0, // make vertically unstretchable
276 wxALIGN_CENTER ); // no border and centre horizontally
277
278 SetSizerAndFit(topsizer); // use the sizer for layout and size window
279 // accordingly and prevent it from being resized
280 // to smaller size
281 }
282 @endcode
283
284 Note that the new way of specifying flags to wxSizer is via wxSizerFlags. This
285 class greatly eases the burden of passing flags to a wxSizer.
286
287 Here's how you'd do the previous example with wxSizerFlags:
288
289 @code
290 // We want to get a dialog that is stretchable because it
291 // has a text ctrl at the top and two buttons at the bottom.
292
293 MyDialog::MyDialog(wxFrame *parent, wxWindowID id, const wxString &title )
294 : wxDialog(parent, id, title, wxDefaultPosition, wxDefaultSize,
295 wxDEFAULT_DIALOG_STYLE | wxRESIZE_BORDER)
296 {
297 wxBoxSizer *topsizer = new wxBoxSizer( wxVERTICAL );
298
299 // create text ctrl with minimal size 100x60 that is horizontally and
300 // vertically stretchable with a border width of 10
301 topsizer->Add(
302 new wxTextCtrl( this, -1, "My text.", wxDefaultPosition, wxSize(100,60), wxTE_MULTILINE),
303 wxSizerFlags(1).Align().Expand().Border(wxALL, 10));
304
305 wxBoxSizer *button_sizer = new wxBoxSizer( wxHORIZONTAL );
306
307 //create two buttons that are horizontally unstretchable,
308 // with an all-around border with a width of 10 and implicit top alignment
309 button_sizer->Add(
310 new wxButton( this, wxID_OK, "OK" ),
311 wxSizerFlags(0).Align().Border(wxALL, 10));
312
313 button_sizer->Add(
314 new wxButton( this, wxID_CANCEL, "Cancel" ),
315 wxSizerFlags(0).Align().Border(wxALL, 10));
316
317 //create a sizer with no border and centered horizontally
318 topsizer->Add(
319 button_sizer,
320 wxSizerFlags(0).Center() );
321
322 SetSizerAndFit(topsizer); // use the sizer for layout and set size and hints
323 }
324 @endcode
325
326
327
328 @section overview_sizer_types Other Types of Sizers
329
330 wxGridSizer is a sizer which lays out its children in a two-dimensional table
331 with all table fields having the same size, i.e. the width of each field is the
332 width of the widest child, the height of each field is the height of the
333 tallest child.
334
335 wxFlexGridSizer is a sizer which lays out its children in a two-dimensional
336 table with all table fields in one row having the same height and all fields in
337 one column having the same width, but all rows or all columns are not
338 necessarily the same height or width as in the wxGridSizer.
339
340 wxStaticBoxSizer is a sizer derived from wxBoxSizer but adds a static box
341 around the sizer. Note that this static box has to be created separately.
342
343 wxGridBagSizer is a rather special kind of sizer which, unlike the other
344 classes, allows to directly put the elements at the given position in the
345 sizer. Please see its documentation for more details.
346
347 @section overview_sizer_button CreateButtonSizer
348
349 As a convenience, wxDialog::CreateButtonSizer(long flags) can be used to create a
350 standard button sizer in which standard buttons are displayed. The following
351 flags can be passed to this function:
352
353 @code
354 wxYES_NO // Add Yes/No subpanel
355 wxYES // return wxID_YES
356 wxNO // return wxID_NO
357 wxNO_DEFAULT // make the wxNO button the default,
358 // otherwise wxYES or wxOK button will be default
359
360 wxOK // return wxID_OK
361 wxCANCEL // return wxID_CANCEL
362 wxHELP // return wxID_HELP
363
364 wxFORWARD // return wxID_FORWARD
365 wxBACKWARD // return wxID_BACKWARD
366 wxSETUP // return wxID_SETUP
367 wxMORE // return wxID_MORE
368 @endcode
369
370 */
371