Added sash window and layout window docs; added wxLog... and assert functions
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@1010 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This commit is contained in:
Julian Smart
133
docs/latex/wx/layalgor.tex
Normal file
133
docs/latex/wx/layalgor.tex
Normal file
@@ -0,0 +1,133 @@
|
||||
\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
|
||||
output window take up space at the top and bottom, then the remaining height in between is used for
|
||||
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}
|
||||
|
||||
\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.
|
||||
|
||||
\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.
|
||||
|
||||
\membersection{wxLayoutAlgorithm::LayoutFrame}\label{wxlayoutalgorithmlayoutframe}
|
||||
|
||||
\constfunc{bool}{LayoutFrame}{\param{wxFrame* }{frame}, \param{wxWindow*}{ mainWindow}}
|
||||
|
||||
Lays out the children of a normal frame.
|
||||
|
||||
{\it mainWindow} is set to occupy the remaining space.
|
||||
|
||||
Reference in New Issue
Block a user