Crunch CRiSP File Editor 6 - Manual (Page 60)

Page 60
DBOX_CENTERED,
DBOX_BUTTON, " Apply ",
DBOX_NEXT_COLUMN, TRUE,
DBOX_CENTERED,
DBOX_BUTTON, " Help ",
DBOX_NEXT_COLUMN, TRUE,
DBOX_CENTERED,
DBOX_BUTTON, " Cancel ",
DBOX_NEXT_COLUMN, TRUE,
DBOX_CENTERED
));
These very basic layout semantics are now sufficient to describe most types of dialog boxes, but there is still
a long way to go.
One of the next issues to resolve is what happens when a dialog box is resized? Many dialog boxes are
fairly static in nature, and having them resizable is of little benefit. With the attributes described above,
nothing has been said of resizing a dialog box. Without any extra information CRiSP cannot determine what
to do, and the end result of the user making a dialog box bigger is simply to add more blank space at the
bottom and to the right of the dialog box. (The exception is those objects marked with the
DBOX_CENTERED attribute which will scale the gap between the objects to make use of the extra space).
Resizing dialog boxes, and Constraint management
For some dialog boxes, it is plainly difficult to decide what is a reasonable size for the objects inside them.
For example, the buffer list which CRiSP will display comes up by default with about 8 lines for the file list. If
you have less than 8 files loaded into CRiSP then some of the space used by the buffer list is wasted. On
the other hand, if too much space is used then it is conceivable that either the user will not be able to see
the entirety of the dialog box (e.g. on a low resolution screen), or the dialog box will simply obscure other
windows on the desktop and get in the way.
So now you not only have to decide how to lay out the objects in your dialog box, but you also need to
consider if you want to allow the dialog box to be resizable and if so, how the dialog box should stretch or
shrink depending on the user's actions.
In general, there are a number of clear cases for stretchable objects within a dialog box. When we talk about
stretchability we are referring to objects whose rectangular shape can be expanded or contracted by
increasing the height or width of the rectangle enclosing the object. At one extreme, we have objects which
are unlikely to be stretched, for example a text label would normally not expand or contract as a result of a
dialog box being resized; a push-button usually doesn't change it's size or shape, and neither would an
individual icon in a toolbar.
When looking at a dialog box, you can normally distinguish two types of objects within the dialog box: the
major ones providing the raw information, and the noise objects which are there simply to provide a means
for actioning events, e.g. the push-buttons. It is the main objects which are important and the reason why a
user would want to resize a dialog box. One way to handle resizing is to allow these major objects to scale
with the size of the dialog box, making use of any extra space the user allocates and contracting. The main
CRiSP editing window illustrates this very clearly. The main editing area expands to fill the space, and when
you resize the CRiSP window, you are doing it so you can see more of the editing area. You wouldn't
normally resize the CRiSP window in order to get a fatter status bar or menu bar.
So an attribute is needed to mark an object as being able to expand to fill the space. In the early versions of
CRiSP, this was provided by four attributes: DBOX_ANCHOR_TOP, DBOX_ANCHOR_BOTTOM,
DBOX_ANCHOR_LEFT, DBOX_ANCHOR_RIGHT. These attributes indicate that the object should expand
to touch the sides of the dialog box and when the dialog box is resized to maintain the relationship. An
object marked with DBOX_ANCHOR_LEFT and DBOX_ANCHOR_RIGHT would typically be used for
something like the list box in the buffer list or the main CRiSP editing window so that the object extends from
one side of the dialog box to the other, exactly filling the space. Likewise, specifying DBOX_ANCHOR_TOP
and DBOX_ANCHOR_BOTTOM would enable an object to expand to fill the height of a dialog box.