Crunch CRiSP File Editor 6 - Manual (Page 67)

Page 67
CRiSP takes a Microsoft Windows style approach. CRiSP is an interpreter and the macro language can best
be considered as a very powerful language for configuring CRiSP. It is not necessarily designed to
incorporate all the latest and greatest ideas in programming methodology, and hence takes poetic license to
implement the most reasonable and easiest approach to the problems it wants to solve.
Macros in general are very high level programming statements. The mechanism CRiSP uses for supporting
user actions on the dialog boxes is via a callback mechanism, whereby a single callback macro function is
used to handle all input and events on a dialog box. This is achieved by using the DBOX_CALLBACK
attribute, normally the second entry in the list of arguments to create_object() (immediately after the
DBOX_TITLE attribute). The argument to the DBOX_CALLBACK attribute is a string which contains the
name of a macro (and any optional parameters).
The macro is called with four parameters as arguments whenever an event occurs. The arguments are:
reason This is an integer event code indicating why the callback function was invoked. (Similar to
a Windows message or an X11 event type).
obj_id This identifies the dialog box. This allows a single callback routine to handle an arbitrary
number of dialog boxes.
sub_obj This parameter is reserved, and is present for historical reasons. (Early versions of CRiSP
referred to the objects in a dialog box by their ordinal position, but this lead to a
maintenance problem as new objects were inserted into the dialog box).
name_id This is a string corresponding to the DBOX_NAME of the object which triggered the event.
To handle the actions in the callback, it is simply a matter of deciding what the action was, and possibly
which object in the dialog box caused the event to take place. (For example, you would need the name_id
field if you had two or more push-buttons).
Platform Specific Issues
The CRiSP dialog box implementation hides most platform specific issues from the macro programmer. This
means that the macros you write are highly portable with usually no changes required whether running
under Microsoft Windows, X11/Motif or X11/XView. There are some things which may need to be borne in
mind when writing dialog box macros - things which are available on some of the windowing systems, but
not necessarily on the complete range.
One issue which is not immediately obvious is that of dismissing a dialog box. Most CRiSP dialog boxes
contain a CANCEL button which is used to dismiss the dialog box without taking any further action. On each
of the main windowing platforms, it is also possible to dismiss the dialog box by selecting the CLOSE option
in the system (or window manager) menu. In this case the name_id parameter in the callback will be blank,
but the callback reason will be LCB_CANCEL. You should always handle this message otherwise you may
end up with undismissable dialog boxes which is usually very annoying (but quite common during dialog box
programming and testing).
The size and shape of various objects is different on a per-platform basis. For example, Motif has very
square buttons, whereas Microsoft Windows rounded buttons The fundamental idea of the dialog box
system is to allow you to write dialog boxes without concern about the final appearance, yet at the same
time knowing your dialog boxes will work on each system unchanged. Under some circumstances you may
find yourself relying on the default layout semantics, but end up with horrible looking layouts in your dialog
box, due to the difference in default sizes of the user interface objects.
How to create your own Colorization file
Colorization This section describes the CRiSP colorization facility, gives you information on how to
create your own configuration and gives a couple of case studies to illustrate the points discussed.
The colorization process allows CRiSP to dynamically color certain parts of files, whether they be program
source files, scripts or data files. Most files are actually very similar from a syntactical point of view: files
contain comments, keywords, and string or number constants.
The beauty of colorization is that instead of looking at flat monochrome text, certain parts of your file are
colored, which makes it easy on the eye to divide long files up into sectional components. For example, look
at the following screen snapshot: