Crunch CRiSP File Editor 6 - Manual (Page 59)

Page 59
DBOX_TREE A tree-like widget which supports outlining views of
data. A tree widget is a bit like a DBOX_LIST
widget but you can control the visibility of
hierarchies of the data.
DBOX_VSCROLLBAR Obsolete.
DBOX_HSCROLLBAR Obsolete.
Some of the object types described above are not fully implemented. They may be in future versions, but
there is no guarantee of this.
For a long period of time, CRiSP has evolved internally to create the object structure described in this
manual. Some of the mechanisms are object types are artefacts of this historical evolution, but now that
CRiSP has become a stable and mature software product, it is unlikely that many of these historical
artefacts will be removed. These artefacts will be documented as necessary.
Geometry Layout
The dialog box mechanism of CRiSP provides for various geometry management mechanisms. Geometry
management is a fancy way of saying how objects are to be positioned in a dialog box.
In the early versions of CRiSP, the layout mechanisms were very simple and these simple ways evolved to
offer a lot of flexibility. Geometry management is a complicated area and it is this area in which you can
waste a lot of time trying to lay things out properly and understand why things do not appear the way you
expect them to be. Geometry management is complex because there are so many different requirements for
the laying out of objects within a dialog box. For example, you may want a particular input field to be so
many characters wide. Another input field may be described as being stretchable, so that if the dialog box is
resized by the user, then the input field expands to make use of the extra space. Another possibility is to
constrain the width of one object to be exactly the same width as another object, e.g. an input field place
directly above or below an input list.
There are no hard and fast rules about geometry management, and it is always advisable to try one thing at
a time. If you try to constrain the objects in a dialog box too much, then you may end up producing
inconsistent constraints leading to peculiar behaviour.
It is worth describing the evolution of the geometry management mechanism so that you can understand the
need for complexity.
Every object created inside a dialog box can be treated as a rectangle occupying a piece of the physical
area of the dialog. Under default conditions, the objects created inside a dialog box are placed immediately
below the preceding object. On its own this would lead to some very restricted and horrible looking skinny
dialog boxes. To this model was added the ability to place objects next to each other. (This is done with the
DBOX_NEXT_COLUMN attribute). Thus, using the default rules we can create a dialog box containing a
series of objects, some next to each other and some below each other.
These initial semantics are actually fine for most dialog boxes, but they do not provide a very fine level of
control. One issue that must be met head on is the issue of the different platforms. For example, a push
button under Microsoft Windows has a very different appearance and size characteristics compared to a
Motif or XView button. It is therefore important to avoid trying to lay things out in a dialog box using absolute
pixel values as this would be fairly disastrous, if contemplating using your dialog box on a different system.
(Even using a dialog box by a different user can lead to problems as each user may have a different default
font, and the size of a push button or label may be different depending on the font actually used).
It is therefore wise to treat each object as a rectangle for which you do not know its eventual size. This leads
to problems, for which various solutions are described below.
Now we can layout a series of rows of objects. The next thing to be implemented was support for equi-
spaced push buttons, e.g. like those normally located at the bottom of the dialog boxes (e.g. OK, Help,
Cancel). This is impossible to do with a simple policy of laying one rectangle out on the same row as another
or below a row of rectangles. To this was added the DBOX_CENTERED attribute. When this attribute is
used, then the object is centered within the free space of a row. For example, you will see typical usage of
this attribute for the buttons at the bottom of a dialog box, e.g.:
obj_id = create_object(make_list(
....
....
DBOX_BUTTON, " Ok ",