Crunch CRiSP File Editor 6 - Manual (Page 62)

Page 62
/* The first object is an input field, */
/* and we have a label to the left of the */
/* input field. */
DBOX_FIELD, "Please type in: ",
/* The input field is marked as stretchable */
DBOX_ALLOW_RESIZE, TRUE,
/* Constrain the left side of the */
/* input field to be in the position as */
/* the left side of the object called */
/* "list" */
DBOX_ATTACH_LEFT_TO_LEFT, "list",
/* Do the same for the right side */
DBOX_ATTACH_RIGHT_TO_RIGHT, "list",
/* Create a scrolling list widget with 3 lines in it. */
DBOX_LIST, quote_list(
"line 1",
"line 2",
"line 3"),
DBOX_NAME, "list",
/* Create a push button so we can dismiss */
/* the dialog. */
DBOX_BUTTON, " Ok "
));
A more complete description of constraints and the attribute values is described in the manual page entries
for the attributes.
Object hierarchies: menu bars, tool bars, status panels
When building a dialog box layout, what you are really building is a tree of objects whose grand parent (or
root) object is the dialog box owner (referred to as the DBOX_OWNER object). For a simple dialog box, you
can simply layout objects in multiple rows, with each object adjacent to the previous one, as described
previously.
The tree-of-objects idea comes into play in two contexts: certain objects act as place-holders, or umbrellas
for multiple constituent sub-objects; also, you can create a tree of objects to refine the layout of a dialog box.
In the first case, placeholders are used for certain types of objects. The three most notable objects are for
the menu bar, toolbar and status panel. In each of these three cases, we have a generic object type, e.g. the
menu bar, but there is a lot of fine level of detail that is needed to describe each menu entry, or each icon.
The mechanisms for supporting these three types is slightly steeped in the history of evolution of CRiSP,
and so each is subtly different from the other, but the idea is the same.
The idea of the objects is to define a rectangle of area within which the object is displayed and can respond
to user actions (mouse and/or keyboard events). To make life easier for the macro programmer, a lot of
housekeeping is hidden behind the scenes and a relatively simple interface is provided. If we take the menu
bar, for example. A menu normally lives at the top of a dialog box and is as wide as the dialog box, even if
this means that some menu entries are not visible because the owning dialog box is too narrow. The point of
interest here, initially, is the real-estate space taken up by the menu bar, and not the real-estate taken up by
the individual menus and menu items. (Especially as these are invisible until the associated menu button is
clicked on). Mentally, we think of a menu bar and the associated menus and sub-menus as a hierarchy.
When programming them in a CRiSP macro, you will lay them out in a hierarchy.
As described before, you create a dialog box containing a list of objects to be displayed. In the case of the
menu bar, toolbar, and status bar, you create a composite object. This object acts like a single object, but
contains a tree of sub-objects. The sub-objects are restricted in their object types. For example, you only
create DBOX_MENU_BUTTONs as children of the DBOX_MENU_BAR, and DBOX_TOOL_BUTTONs are created