]> git.saurik.com Git - wxWidgets.git/blobdiff - docs/latex/wx/tconstr.tex
Fixed to work with the new wxMacControl system.
[wxWidgets.git] / docs / latex / wx / tconstr.tex
index 4d14c3dff004319d6c34e1d414265f9db94aaa71..c5c546109caebbcf0ba0fa8b557b5442a47c0a56 100644 (file)
@@ -2,8 +2,10 @@
 
 Classes: \helpref{wxLayoutConstraints}{wxlayoutconstraints}, \helpref{wxIndividualLayoutConstraint}{wxindividuallayoutconstraint}.
 
-Objects of class wxLayoutConstraint can be associated with a window to define the
-way its subwindows are laid out, with respect to their siblings or parent.
+{\bf Note:} constraints are now deprecated and you should use \helpref{sizers}{sizeroverview} instead.
+
+Objects of class wxLayoutConstraint can be associated with a window to define
+the way it is laid out, with respect to its siblings or the parent.
 
 The class consists of the following eight constraints of class wxIndividualLayoutConstraint,
 some or all of which should be accessed directly to set the appropriate
@@ -34,9 +36,12 @@ label).
 
 The constrains calculation is done in \helpref{wxWindow::Layout}{wxwindowlayout} 
 function which evaluates constraints. To call it you can either call
-wxWindow::SetAutoLayout to tell default OnSize handlers to call Layout
-automatically whenever the window size changes, or override OnSize and call Layout
-yourself.
+\helpref{wxWindow::SetAutoLayout}{wxwindowsetautolayout} if the parent window
+is a frame, panel or a dialog to tell default OnSize handlers to call Layout
+automatically whenever the window size changes, or override OnSize and call
+Layout yourself (note that you do have to call 
+\helpref{Layout}{wxwindowlayout} yourself if the parent window is not a
+frame, panel or dialog).
 
 \subsection{Constraint layout: more detail}
 
@@ -52,13 +57,13 @@ This object contains a constraint for each of the window edges, two for the cent
 and two for the window size. By setting some or all of these constraints appropriately,
 the user can achieve quite complex layout by defining relationships between windows.
 
-In wxWindows, each window can be constrained relative to either its {\it
+In wxWidgets, each window can be constrained relative to either its {\it
 siblings} on the same window, or the {\it parent}. The layout algorithm
 therefore operates in a top-down manner, finding the correct layout for
 the children of a window, then the layout for the grandchildren, and so
 on. Note that this differs markedly from native Motif layout, where
 constraints can ripple upwards and can eventually change the frame
-window or dialog box size. We assume in wxWindows that the {\it user} is
+window or dialog box size. We assume in wxWidgets that the {\it user} is
 always `boss' and specifies the size of the outer window, to which
 subwindows must conform. Obviously, this might be a limitation in some
 circumstances, but it suffices for most situations, and the
@@ -69,13 +74,13 @@ When the user sets constraints, many of the constraints for windows
 edges and dimensions remain unconstrained. For a given window,
 the wxWindow::Layout algorithm first resets all constraints
 in all children to have unknown edge or dimension values, and then iterates through the constraints,
-evaulating them. For unconstrained edges and dimensions, it
+evaluating them. For unconstrained edges and dimensions, it
 tries to find the value using known relationships that always hold. For example,
 an unconstrained {\it width} may be calculated from the {\it left} and {\it right edges}, if
 both are currently known. For edges and dimensions with user-supplied constraints, these
-constraints are evaulated if the inputs of the constraint are known.
+constraints are evaluated if the inputs of the constraint are known.
 
-The algorithm stops when all child edges and dimension are known (success), or there
+The algorithm stops when all child edges and dimension are known (success), or 
 there are unknown edges or dimensions but there has been no change in this cycle (failure).
 
 It then sets all the window positions and sizes according to the values it has found.
@@ -85,7 +90,7 @@ irrelevant, however you may reduce the number of iterations (and thus speed up
 the layout calculations) by creating the controls in such order that as many
 constraints as possible can be calculated during the first iteration. For example, if
 you have 2 buttons which you'd like to position in the lower right corner, it is
-slighty more efficient to first create the second button and specify that its
+slightly more efficient to first create the second button and specify that its
 right border IsSameAs(parent, wxRight) and then create the first one by
 specifying that it should be LeftOf() the second one than to do in a more
 natural left-to-right order.