1998-11-17 17:44:47 -05:00
|
|
|
\section{\class{wxLayoutAlgorithm}}\label{wxlayoutalgorithm}
|
|
|
|
|
|
|
|
wxLayoutAlgorithm implements layout of subwindows in MDI or SDI frames.
|
|
|
|
It sends a wxCalculateLayoutEvent event
|
|
|
|
to children of the frame, asking them for information about
|
|
|
|
their size. For MDI parent frames, the algorithm allocates
|
|
|
|
the remaining space to the MDI client window (which contains the MDI child frames).
|
|
|
|
For SDI (normal) frames, a 'main' window is specified as taking up the
|
|
|
|
remaining space.
|
|
|
|
|
|
|
|
Because the event system is used, this technique can be applied to any windows,
|
|
|
|
which are not necessarily 'aware' of the layout classes (no virtual functions
|
|
|
|
in wxWindow refer to wxLayoutAlgorithm or its events). However, you
|
|
|
|
may wish to use \helpref{wxSashLayoutWindow}{wxsashlayoutwindow} for your subwindows
|
|
|
|
since this class provides handlers for the required events, and accessors
|
|
|
|
to specify the desired size of the window. The sash behaviour in the base class
|
|
|
|
can be used, optionally, to make the windows user-resizable.
|
|
|
|
|
|
|
|
wxLayoutAlgorithm is typically used in IDE (integrated development environment) applications,
|
|
|
|
where there are several resizable windows in addition to the MDI client window, or
|
|
|
|
other primary editing window. Resizable windows might include toolbars, a project
|
|
|
|
window, and a window for displaying error and warning messages.
|
|
|
|
|
|
|
|
When a window receives an OnCalculateLayout event, it should call SetRect in
|
|
|
|
the given event object, to be the old supplied rectangle minus whatever space the
|
|
|
|
window takes up. It should also set its own size accordingly.
|
|
|
|
wxSashLayoutWindow::OnCalculateLayout generates an OnQueryLayoutInfo event
|
|
|
|
which it sends to itself to determine the orientation, alignment and size of the window,
|
|
|
|
which it gets from internal member variables set by the application.
|
|
|
|
|
|
|
|
The algorithm works by starting off with a rectangle equal to the whole frame client area.
|
|
|
|
It iterates through the frame children, generating OnCalculateLayout events which subtract
|
|
|
|
the window size and return the remaining rectangle for the next window to process. It
|
|
|
|
is assumed (by wxSashLayoutWindow::OnCalculateLayout) that a window stretches the full dimension
|
|
|
|
of the frame client, according to the orientation it specifies. For example, a horizontal window
|
|
|
|
will stretch the full width of the remaining portion of the frame client area.
|
|
|
|
In the other orientation, the window will be fixed to whatever size was specified by
|
|
|
|
OnQueryLayoutInfo. An alignment setting will make the window 'stick' to the left, top, right or
|
|
|
|
bottom of the remaining client area. This scheme implies that order of window creation is important.
|
|
|
|
Say you wish to have an extra toolbar at the top of the frame, a project window to the left of
|
|
|
|
the MDI client window, and an output window above the status bar. You should therefore create
|
|
|
|
the windows in this order: toolbar, output window, project window. This ensures that the toolbar and
|
1998-11-21 10:40:35 -05:00
|
|
|
output window take up space at the top and bottom, and then the remaining height inbetween is used for
|
1998-11-17 17:44:47 -05:00
|
|
|
the project window.
|
|
|
|
|
|
|
|
wxLayoutAlgorithm is quite independent of the way in which
|
|
|
|
OnCalculateLayout chooses to interpret a window's size and alignment. Therefore you
|
|
|
|
could implement a different window class with a new OnCalculateLayout event handler,
|
|
|
|
that has a more sophisticated way of laying out the windows. It might allow
|
|
|
|
specification of whether stretching occurs in the specified orientation, for example,
|
|
|
|
rather than always assuming stretching. (This could, and probably should, be added to the existing
|
|
|
|
implementation).
|
|
|
|
|
|
|
|
{\it Note:} wxLayoutAlgorithm has nothing to do with wxLayoutConstraints. It is an alternative
|
|
|
|
way of specifying layouts for which the normal constraint system is unsuitable.
|
|
|
|
|
|
|
|
\wxheading{Derived from}
|
|
|
|
|
|
|
|
\helpref{wxObject}{wxobject}
|
|
|
|
|
1999-02-15 15:41:29 -05:00
|
|
|
\wxheading{Include files}
|
|
|
|
|
|
|
|
<wx/laywin.h>
|
|
|
|
|
1998-11-17 17:44:47 -05:00
|
|
|
\wxheading{Event handling}
|
|
|
|
|
|
|
|
The algorithm object does not respond to events, but itself generates the
|
|
|
|
following events in order to calculate window sizes.
|
|
|
|
|
|
|
|
\twocolwidtha{7cm}%
|
|
|
|
\begin{twocollist}\itemsep=0pt
|
|
|
|
\twocolitem{{\bf EVT\_QUERY\_LAYOUT\_INFO(func)}}{Process a wxEVT\_QUERY\_LAYOUT\_INFO event,
|
|
|
|
to get size, orientation and alignment from a window. See \helpref{wxQueryLayoutInfoEvent}{wxquerylayoutinfoevent}.}
|
|
|
|
\twocolitem{{\bf EVT\_CALCULATE\_LAYOUT(func)}}{Process a wxEVT\_CALCULATE\_LAYOUT event,
|
|
|
|
which asks the window to take a 'bite' out of a rectangle provided by the algorithm.
|
|
|
|
See \helpref{wxCalculateLayoutEvent}{wxcalculatelayoutevent}.}
|
|
|
|
\end{twocollist}
|
|
|
|
|
|
|
|
\wxheading{Data types}
|
|
|
|
|
|
|
|
{\small
|
|
|
|
\begin{verbatim}
|
|
|
|
enum wxLayoutOrientation {
|
|
|
|
wxLAYOUT_HORIZONTAL,
|
|
|
|
wxLAYOUT_VERTICAL
|
|
|
|
};
|
|
|
|
|
|
|
|
enum wxLayoutAlignment {
|
|
|
|
wxLAYOUT_NONE,
|
|
|
|
wxLAYOUT_TOP,
|
|
|
|
wxLAYOUT_LEFT,
|
|
|
|
wxLAYOUT_RIGHT,
|
|
|
|
wxLAYOUT_BOTTOM,
|
|
|
|
};
|
|
|
|
\end{verbatim}
|
|
|
|
}
|
|
|
|
|
|
|
|
\wxheading{See also}
|
|
|
|
|
|
|
|
\helpref{wxSashEvent}{wxsashevent}, \helpref{wxSashLayoutWindow}{wxsashlayoutwindow}, \helpref{Event handling overview}{eventhandlingoverview}
|
|
|
|
|
|
|
|
\helpref{wxCalculateLayoutEvent}{wxcalculatelayoutevent},\rtfsp
|
|
|
|
\helpref{wxQueryLayoutInfoEvent}{wxquerylayoutinfoevent},\rtfsp
|
|
|
|
\helpref{wxSashLayoutWindow}{wxsashlayoutwindow},\rtfsp
|
|
|
|
\helpref{wxSashWindow}{wxsashwindow}
|
|
|
|
|
|
|
|
\latexignore{\rtfignore{\wxheading{Members}}}
|
|
|
|
|
|
|
|
\membersection{wxLayoutAlgorithm::wxLayoutAlgorithm}
|
|
|
|
|
|
|
|
\func{}{wxLayoutAlgorithm}{\void}
|
|
|
|
|
|
|
|
Default constructor.
|
|
|
|
|
|
|
|
\membersection{wxLayoutAlgorithm::\destruct{wxLayoutAlgorithm}}
|
|
|
|
|
|
|
|
\func{}{\destruct{wxLayoutAlgorithm}}{\void}
|
|
|
|
|
|
|
|
Destructor.
|
|
|
|
|
1999-01-30 16:37:17 -05:00
|
|
|
\membersection{wxLayoutAlgorithm::LayoutFrame}\label{wxlayoutalgorithmlayoutframe}
|
|
|
|
|
|
|
|
\constfunc{bool}{LayoutFrame}{\param{wxFrame* }{frame}, \param{wxWindow*}{ mainWindow = NULL}}
|
|
|
|
|
|
|
|
Lays out the children of a normal frame. {\it mainWindow} is set to occupy the remaining space.
|
|
|
|
|
|
|
|
This function simply calls \helpref{wxLayoutAlgorithm::LayoutWindow}{wxlayoutalgorithmlayoutwindow}.
|
|
|
|
|
1998-11-17 17:44:47 -05:00
|
|
|
\membersection{wxLayoutAlgorithm::LayoutMDIFrame}\label{wxlayoutalgorithmlayoutmdiframe}
|
|
|
|
|
|
|
|
\constfunc{bool}{LayoutMDIFrame}{\param{wxMDIParentFrame* }{frame}, \param{wxRect*}{ rect = NULL}}
|
|
|
|
|
|
|
|
Lays out the children of an MDI parent frame. If {\it rect} is non-NULL, the
|
|
|
|
given rectangle will be used as a starting point instead of the frame's client area.
|
|
|
|
|
|
|
|
The MDI client window is set to occupy the remaining space.
|
|
|
|
|
1999-01-30 16:37:17 -05:00
|
|
|
\membersection{wxLayoutAlgorithm::LayoutWindow}\label{wxlayoutalgorithmlayoutwindow}
|
1998-11-17 17:44:47 -05:00
|
|
|
|
1999-01-30 16:37:17 -05:00
|
|
|
\constfunc{bool}{LayoutWindow}{\param{wxWindow* }{parent}, \param{wxWindow*}{ mainWindow = NULL}}
|
1998-11-17 17:44:47 -05:00
|
|
|
|
1999-01-30 16:37:17 -05:00
|
|
|
Lays out the children of a normal frame or other window.
|
1998-11-17 17:44:47 -05:00
|
|
|
|
|
|
|
{\it mainWindow} is set to occupy the remaining space.
|
|
|
|
|