Amebis/wxWidgets
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

This commit was manufactured by cvs2svn to create tag

Browse Source 
'DEBIAN_2_4_3_1_SARGE_v_2_4_2_4'.

git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/tags/DEBIAN_2_4_3_1_SARGE_v_2_4_2_4@34395 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This commit is contained in:
Bryan Petty
2005-05-29 09:56:16 +00:00
parent 86118733af
commit cfd794784f
4010 changed files with 349688 additions and 169530 deletions
Download Patch File Download Diff File Expand all files Collapse all files

43
docs/latex/wx/tsizer.tex
View File

@@ -3,26 +3,27 @@
Classes: \helpref{wxSizer}{wxsizer}, \helpref{wxGridSizer}{wxgridsizer},
\helpref{wxFlexGridSizer}{wxflexgridsizer}, \helpref{wxBoxSizer}{wxboxsizer},
\helpref{wxStaticBoxSizer}{wxstaticboxsizer},
\helpref{wxNotebookSizer}{wxnotebooksizer}
\helpref{wxNotebookSizer}{wxnotebooksizer},
\helpref{CreateButtonSizer}{createbuttonsizer}
Sizers, as represented by the wxSizer class and its descendants in
the wxWindows class hierarchy, have become the method of choice to
define the layout of controls in dialogs in wxWindows because of
the wxWidgets class hierarchy, have become the method of choice to
define the layout of controls in dialogs in wxWidgets because of
their ability to create visually appealing dialogs independent of the
platform, taking into account the differences in size and style of
the individual controls. Unlike the original wxWindows Dialog Editor,
the individual controls. Unlike the original wxWidgets Dialog Editor,
editors such as wxDesigner, wxrcedit, XRCed and wxWorkshop create dialogs based exclusively on sizers,
practically forcing the user to create platform independent layouts without compromises.
The next section describes and shows what can be done with sizers.
The following sections briefly describe how to program with individual sizer classes.
For information about the new wxWindows resource system, which can describe
For information about the new wxWidgets resource system, which can describe
sizer-based dialogs, see the \helpref{XML-based resource system overview}{xrcoverview}.
\subsection{The idea behind sizers}\label{ideabehindsizers}
The layout algorithm used by sizers in wxWindows is closely related to layout
The layout algorithm used by sizers in wxWidgets is closely related to layout
systems in other GUI toolkits, such as Java's AWT, the GTK toolkit or the Qt toolkit. It is
based upon the idea of individual subwindows reporting their minimal required
size and their ability to get stretched if the size of the parent window has changed.
@@ -34,13 +35,13 @@ a hierarchy of sizers can be constructed. Note that wxSizer does not derive from
and thus does not interfere with tab ordering and requires very few resources compared
to a real window on screen.
What makes sizers so well fitted for use in wxWindows is the fact that every control
What makes sizers so well fitted for use in wxWidgets is the fact that every control
reports its own minimal size and the algorithm can handle differences in font sizes
or different window (dialog item) sizes on different platforms without problems. For example, if
the standard font as well as the overall design of Linux/GTK widgets requires more space than
on Windows, the initial dialog size will automatically be bigger on Linux/GTK than on Windows.
There are currently five different kinds of sizers available in wxWindows. Each represents
There are currently five different kinds of sizers available in wxWidgets. Each represents
either a certain way to lay out dialog items in a dialog or it fulfils a special task
such as wrapping a static box around a dialog item (or another sizer). These sizers will
be discussed one by one in the text below. For more detailed information on how to use sizers
@@ -55,7 +56,7 @@ have certain features in common:
{\bf A minimal size:} This minimal size is usually identical to
the initial size of the controls and may either be set explicitly in the wxSize field
of the control constructor or may be calculated by wxWindows, typically by setting
of the control constructor or may be calculated by wxWidgets, typically by setting
the height and/or the width of the item to -1. Note that only some controls can
calculate their size (such as a checkbox) whereas others (such as a listbox)
don't have any natural width or height and thus require an explicit size. Some controls
@@ -192,7 +193,7 @@ the buttons shall be centred as the width of the dialog changes.
It is the unique feature of a box sizer, that it can grow in both directions (height and
width) but can distribute its growth in the main direction (horizontal for a row) {\it unevenly}
among its children. In our example case, the vertical sizer is supposed to propagate all its
height changes to only the text area, not to the button area. This is determined by the {\it option} parameter
height changes to only the text area, not to the button area. This is determined by the {\it proportion} parameter
when adding a window (or another sizer) to a sizer. It is interpreted
as a weight factor, i.e. it can be zero, indicating that the window may not be resized
at all, or above zero. If several windows have a value above zero, the value is interpreted
@@ -312,3 +313,25 @@ aware of:
box around the sizer. Note that this static box has to be created
separately.
\subsection{CreateButtonSizer}\label{createbuttonsizer}
As a convenience, CreateButtonSizer ( long flags ) can be used to create a standard button sizer
in which standard buttons are displayed. The following flags can be passed to this function:
\begin{verbatim}
wxYES_NO // Add Yes/No subpanel
wxYES // return wxID_YES
wxNO // return wxID_NO
wxNO_DEFAULT // make the wxNO button the default, otherwise wxYES or wxOK button will be default
wxOK // return wxID_OK
wxCANCEL // return wxID_CANCEL
wxHELP // return wxID_HELP
wxFORWARD // return wxID_FORWARD
wxBACKWARD // return wxID_BACKWARD
wxSETUP // return wxID_SETUP
wxMORE // return wxID_MORE
\end{verbatim}