]>
Commit | Line | Data |
---|---|---|
1 | ///////////////////////////////////////////////////////////////////////////// | |
2 | // Name: windowsizing | |
3 | // Purpose: topic overview | |
4 | // Author: wxWidgets team | |
5 | // RCS-ID: $Id$ | |
6 | // Licence: wxWindows license | |
7 | ///////////////////////////////////////////////////////////////////////////// | |
8 | ||
9 | /*! | |
10 | ||
11 | @page overview_windowsizing Window Sizing Overview | |
12 | ||
13 | It can sometimes be confusing to keep track of the various | |
14 | size-related attributes of a #wxWindow, how they | |
15 | relate to each other, and how they interact with sizers. This document | |
16 | will attempt to clear the fog a little, and give some simple | |
17 | explanations of things. | |
18 | @b BestSize: The best size of a widget depends on what kind of widget it | |
19 | is, and usually also on the contents of the widget. For example a | |
20 | #wxListBox's best size will be calculated based on | |
21 | how many items it has, up to a certain limit, or a | |
22 | #wxButton's best size will be calculated based on | |
23 | its label size, but normally won't be smaller than the platform | |
24 | default button size (unless a style flag overrides that). Get the | |
25 | picture? There is a special virtual method in the C++ window classes | |
26 | called @c DoGetBestSize() that a class needs to override if it | |
27 | wants to calculate its own best size based on its content. The default | |
28 | @c DoGetBestSize() is designed for use in container windows, | |
29 | such as #wxPanel, and works something like this: | |
30 | ||
31 | ||
32 | If the window has a sizer then it is used to calculate the best size. | |
33 | Otherwise if the window has layout constraints then that is used to calculate the best size. | |
34 | Otherwise if the window has children then the best size is set to be large enough to show all the children. | |
35 | Otherwise if there are no children then the window's min size will be used for the best size. | |
36 | Otherwise if there is no min size set, then the current size is used for the best size. | |
37 | ||
38 | ||
39 | @b MinSize: The min size of a widget is a size that is normally | |
40 | explicitly set by the programmer either with the @c SetMinSize() | |
41 | method or the @c SetSizeHints() method. Most controls will also | |
42 | set the min size to the size given in the control's constructor if a | |
43 | non-default value is passed. Top-level windows such as | |
44 | #wxFrame will not allow the user to resize the frame | |
45 | below the min size. | |
46 | @b Size: The size of a widget can be explicitly set or fetched with | |
47 | the @c SetSize() or @c GetSize() methods. This size value | |
48 | is the size that the widget is currently using on screen and is the | |
49 | way to change the size of something that is not being managed by a | |
50 | sizer. | |
51 | @b ClientSize: The client size represents the widget's area inside | |
52 | of any borders belonging to the widget and is the area that can be | |
53 | drawn upon in a @c EVT_PAINT event. If a widget doesn't have a | |
54 | border then its client size is the same as its size. | |
55 | @b InitialSize: The initial size of a widget is the size given to | |
56 | the constructor of the widget, if any. As mentioned above most | |
57 | controls will also set this size value as the control's min size. If | |
58 | the size passed to the constructor is the default | |
59 | @c wxDefaultSize, or if the size is not fully specified (such as | |
60 | @c wxSize(150,-1)) then most controls will fill in the missing | |
61 | size components using the best size and will set the initial size of | |
62 | the control to the resulting size. | |
63 | @b GetEffectiveMinSize(): (formerly @c GetBestFittingSize) A | |
64 | blending of the widget's min size and best size, giving precedence to | |
65 | the min size. For example, if a widget's min size is set to (150, -1) | |
66 | and the best size is (80, 22) then the best fitting size is (150, | |
67 | 22). If the min size is (50, 20) then the best fitting size is (50, | |
68 | 20). This method is what is called by the sizers when determining what | |
69 | the requirements of each item in the sizer is, and is used for | |
70 | calculating the overall minimum needs of the sizer. | |
71 | @b SetInitialSize(size): (formerly @c SetBestFittingSize) | |
72 | This is a little different than the typical size setters. Rather than | |
73 | just setting an "initial size" attribute it actually sets the minsize | |
74 | to the value passed in, blends that value with the best size, and then | |
75 | sets the size of the widget to be the result. So you can consider this | |
76 | method to be a "Smart SetSize". This method is what is called by the | |
77 | constructor of most controls to set the minsize and initial size of | |
78 | the control. | |
79 | @b window.Fit(): The @c Fit() method sets the size of a | |
80 | window to fit around its children. If it has no children then nothing | |
81 | is done, if it does have children then the size of the window is set | |
82 | to the window's best size. | |
83 | @b sizer.Fit(window): This sets the size of the window to be large | |
84 | enough to accommodate the minimum size needed by the sizer, (along with | |
85 | a few other constraints...) If the sizer is the one that is assigned | |
86 | to the window then this should be equivalent to @c window.Fit(). | |
87 | @b sizer.Layout(): Recalculates the minimum space needed by each | |
88 | item in the sizer, and then lays out the items within the space | |
89 | currently allotted to the sizer. | |
90 | @b window.Layout(): If the window has a sizer then it sets the | |
91 | space given to the sizer to the current size of the window, which | |
92 | results in a call to @c sizer.Layout(). If the window has layout | |
93 | constraints instead of a sizer then the constraints algorithm is | |
94 | run. The @c Layout() method is what is called by the default | |
95 | @c EVT_SIZE handler for container windows. | |
96 | ||
97 | */ | |
98 | ||
99 |