]>
Commit | Line | Data |
---|---|---|
1 | \section{\class{wxLayoutAlgorithm}}\label{wxlayoutalgorithm} | |
2 | ||
3 | wxLayoutAlgorithm implements layout of subwindows in MDI or SDI frames. | |
4 | It sends a wxCalculateLayoutEvent event | |
5 | to children of the frame, asking them for information about | |
6 | their size. For MDI parent frames, the algorithm allocates | |
7 | the remaining space to the MDI client window (which contains the MDI child frames). | |
8 | For SDI (normal) frames, a 'main' window is specified as taking up the | |
9 | remaining space. | |
10 | ||
11 | Because the event system is used, this technique can be applied to any windows, | |
12 | which are not necessarily 'aware' of the layout classes (no virtual functions | |
13 | in wxWindow refer to wxLayoutAlgorithm or its events). However, you | |
14 | may wish to use \helpref{wxSashLayoutWindow}{wxsashlayoutwindow} for your subwindows | |
15 | since this class provides handlers for the required events, and accessors | |
16 | to specify the desired size of the window. The sash behaviour in the base class | |
17 | can be used, optionally, to make the windows user-resizable. | |
18 | ||
19 | wxLayoutAlgorithm is typically used in IDE (integrated development environment) applications, | |
20 | where there are several resizable windows in addition to the MDI client window, or | |
21 | other primary editing window. Resizable windows might include toolbars, a project | |
22 | window, and a window for displaying error and warning messages. | |
23 | ||
24 | When a window receives an OnCalculateLayout event, it should call SetRect in | |
25 | the given event object, to be the old supplied rectangle minus whatever space the | |
26 | window takes up. It should also set its own size accordingly. | |
27 | wxSashLayoutWindow::OnCalculateLayout generates an OnQueryLayoutInfo event | |
28 | which it sends to itself to determine the orientation, alignment and size of the window, | |
29 | which it gets from internal member variables set by the application. | |
30 | ||
31 | The algorithm works by starting off with a rectangle equal to the whole frame client area. | |
32 | It iterates through the frame children, generating OnCalculateLayout events which subtract | |
33 | the window size and return the remaining rectangle for the next window to process. It | |
34 | is assumed (by wxSashLayoutWindow::OnCalculateLayout) that a window stretches the full dimension | |
35 | of the frame client, according to the orientation it specifies. For example, a horizontal window | |
36 | will stretch the full width of the remaining portion of the frame client area. | |
37 | In the other orientation, the window will be fixed to whatever size was specified by | |
38 | OnQueryLayoutInfo. An alignment setting will make the window 'stick' to the left, top, right or | |
39 | bottom of the remaining client area. This scheme implies that order of window creation is important. | |
40 | Say you wish to have an extra toolbar at the top of the frame, a project window to the left of | |
41 | the MDI client window, and an output window above the status bar. You should therefore create | |
42 | the windows in this order: toolbar, output window, project window. This ensures that the toolbar and | |
43 | output window take up space at the top and bottom, and then the remaining height inbetween is used for | |
44 | the project window. | |
45 | ||
46 | wxLayoutAlgorithm is quite independent of the way in which | |
47 | OnCalculateLayout chooses to interpret a window's size and alignment. Therefore you | |
48 | could implement a different window class with a new OnCalculateLayout event handler, | |
49 | that has a more sophisticated way of laying out the windows. It might allow | |
50 | specification of whether stretching occurs in the specified orientation, for example, | |
51 | rather than always assuming stretching. (This could, and probably should, be added to the existing | |
52 | implementation). | |
53 | ||
54 | {\it Note:} wxLayoutAlgorithm has nothing to do with wxLayoutConstraints. It is an alternative | |
55 | way of specifying layouts for which the normal constraint system is unsuitable. | |
56 | ||
57 | \wxheading{Derived from} | |
58 | ||
59 | \helpref{wxObject}{wxobject} | |
60 | ||
61 | \wxheading{Include files} | |
62 | ||
63 | <wx/laywin.h> | |
64 | ||
65 | \wxheading{Event handling} | |
66 | ||
67 | The algorithm object does not respond to events, but itself generates the | |
68 | following events in order to calculate window sizes. | |
69 | ||
70 | \twocolwidtha{7cm}% | |
71 | \begin{twocollist}\itemsep=0pt | |
72 | \twocolitem{{\bf EVT\_QUERY\_LAYOUT\_INFO(func)}}{Process a wxEVT\_QUERY\_LAYOUT\_INFO event, | |
73 | to get size, orientation and alignment from a window. See \helpref{wxQueryLayoutInfoEvent}{wxquerylayoutinfoevent}.} | |
74 | \twocolitem{{\bf EVT\_CALCULATE\_LAYOUT(func)}}{Process a wxEVT\_CALCULATE\_LAYOUT event, | |
75 | which asks the window to take a 'bite' out of a rectangle provided by the algorithm. | |
76 | See \helpref{wxCalculateLayoutEvent}{wxcalculatelayoutevent}.} | |
77 | \end{twocollist} | |
78 | ||
79 | \wxheading{Data types} | |
80 | ||
81 | {\small | |
82 | \begin{verbatim} | |
83 | enum wxLayoutOrientation { | |
84 | wxLAYOUT_HORIZONTAL, | |
85 | wxLAYOUT_VERTICAL | |
86 | }; | |
87 | ||
88 | enum wxLayoutAlignment { | |
89 | wxLAYOUT_NONE, | |
90 | wxLAYOUT_TOP, | |
91 | wxLAYOUT_LEFT, | |
92 | wxLAYOUT_RIGHT, | |
93 | wxLAYOUT_BOTTOM, | |
94 | }; | |
95 | \end{verbatim} | |
96 | } | |
97 | ||
98 | \wxheading{See also} | |
99 | ||
100 | \helpref{wxSashEvent}{wxsashevent}, \helpref{wxSashLayoutWindow}{wxsashlayoutwindow}, \helpref{Event handling overview}{eventhandlingoverview} | |
101 | ||
102 | \helpref{wxCalculateLayoutEvent}{wxcalculatelayoutevent},\rtfsp | |
103 | \helpref{wxQueryLayoutInfoEvent}{wxquerylayoutinfoevent},\rtfsp | |
104 | \helpref{wxSashLayoutWindow}{wxsashlayoutwindow},\rtfsp | |
105 | \helpref{wxSashWindow}{wxsashwindow} | |
106 | ||
107 | \latexignore{\rtfignore{\wxheading{Members}}} | |
108 | ||
109 | \membersection{wxLayoutAlgorithm::wxLayoutAlgorithm} | |
110 | ||
111 | \func{}{wxLayoutAlgorithm}{\void} | |
112 | ||
113 | Default constructor. | |
114 | ||
115 | \membersection{wxLayoutAlgorithm::\destruct{wxLayoutAlgorithm}} | |
116 | ||
117 | \func{}{\destruct{wxLayoutAlgorithm}}{\void} | |
118 | ||
119 | Destructor. | |
120 | ||
121 | \membersection{wxLayoutAlgorithm::LayoutFrame}\label{wxlayoutalgorithmlayoutframe} | |
122 | ||
123 | \constfunc{bool}{LayoutFrame}{\param{wxFrame* }{frame}, \param{wxWindow*}{ mainWindow = NULL}} | |
124 | ||
125 | Lays out the children of a normal frame. {\it mainWindow} is set to occupy the remaining space. | |
126 | ||
127 | This function simply calls \helpref{wxLayoutAlgorithm::LayoutWindow}{wxlayoutalgorithmlayoutwindow}. | |
128 | ||
129 | \membersection{wxLayoutAlgorithm::LayoutMDIFrame}\label{wxlayoutalgorithmlayoutmdiframe} | |
130 | ||
131 | \constfunc{bool}{LayoutMDIFrame}{\param{wxMDIParentFrame* }{frame}, \param{wxRect*}{ rect = NULL}} | |
132 | ||
133 | Lays out the children of an MDI parent frame. If {\it rect} is non-NULL, the | |
134 | given rectangle will be used as a starting point instead of the frame's client area. | |
135 | ||
136 | The MDI client window is set to occupy the remaining space. | |
137 | ||
138 | \membersection{wxLayoutAlgorithm::LayoutWindow}\label{wxlayoutalgorithmlayoutwindow} | |
139 | ||
140 | \constfunc{bool}{LayoutWindow}{\param{wxWindow* }{parent}, \param{wxWindow*}{ mainWindow = NULL}} | |
141 | ||
142 | Lays out the children of a normal frame or other window. | |
143 | ||
144 | {\it mainWindow} is set to occupy the remaining space. If this is not specified, then | |
145 | the last window that responds to a calculate layout event in query mode will get the remaining space | |
146 | (that is, a non-query OnCalculateLayout event will not be sent to this window and the window will be set | |
147 | to the remaining size). | |
148 |