Crunch CRiSP File Editor 6 - Manual (Page 63)

Page 63
as children of a DBOX_TOOL_BAR.
For the DBOX_MENU_BAR case, only DBOX_MENU_BUTTON or DBOX_DROP_SITE types are
reasonable children. For DBOX_TOOL_BAR, only DBOX_TOOL_BUTTONs are valid. For the
DBOX_STATUS_BAR, DBOX_STATUS_PANEL are the sub-objects which can be used.
In the case of the menu bar, it is necessary to define the hierarchy of sub-menus and cascaded menus
which can be created, along with any attributes each of the sub-objects may require. Toolbars are flat data
structures, in that there are no hidden objects which suddenly popup when activated, but there are
numerous options and attributes which can be specified, many of which are common to all the buttons in the
toolbar. In the case of a status panel, it is useful to be able to split the visible area of the status panel in such
a way so that multiple areas of text can be displayed, and also to allow some degree of rubberness, e.g. the
standard status panel which is displayed when CRiSP comes up has a flexible status message area to the
left, whilst the sizes of the INS/Line:/Col: fields are relatively static and do not take up any slack when the
main window is resized.
Object hierarchies and grouping
As described in the previous section, it is sometimes necessary to create a sub-tree of objects, either
because it is easier to treat a group of objects with common functionality, or because of layout semantics. In
the various descriptions of objects and attributes described so far, it has been shown how to treat the layout
of a dialog box by treating the objects as rectangles which are laid out next to each other or below each
other. There is a certain class of layouts which are difficult or impossible to do with these mechanisms, or
with the constraints mechanisms.
Consider the layout of a dialog box which consists of a small label, centered above a multiline list box. This
sort of layout is easily describable, with something like:
obj_id = create_object(make_list(
...
DBOX_LABEL, "Items",
DBOX_CENTERED,
DBOX_LIST, quote_list(....)
...));
Now consider two lists, side by side, with a label above each one. One way to do this is with something like:
obj_id = create_object(make_list(
...
DBOX_LABEL, "Items#1",
DBOX_CENTERED,
DBOX_LABEL, "Items#2",
DBOX_CENTERED,
DBOX_NEXT_COLUMN, TRUE,
DBOX_LIST, quote_list(....),
DBOX_LIST, quote_list(....),
DBOX_NEXT_COLUMN, TRUE,
...));
The problem is that this is unlikely to work. We need to lay out the objects in approximately the left to right,
top to bottom approach. The effect of the above is that the labels will be centered within their own 50% of
the row, but the relationship of the labels to the list boxes will not necessarily be what you want. For
example, if we extended the dialog box description above to include an object, say a push-button, to the
right of the second DBOX_LIST, then the two labels would no longer be centered directly above the
corresponding list boxes.
The starting point for this type of layout was very simple: take something simple that works, and create two
copies of them side by side. But the problem is that we were not precise enough in our original description
and this lack of exactness shows through as soon as we try to modify the description to encompass other
objects in the dialog box.
This sort of thing is very frustrating and is why it is always a good idea to build up a dialog box a piece at a
time - at the point a dialog box description breaks, you can backtrack and try and understand what has gone
wrong. Trying to understand the problems with the description above can be very difficult if it is a complex