User Manual

Page 53
years, such organisations as Microsoft, IBM, and the OSF have strived to achieve the ultimate user
interface. None of these organisations has produced a finished product, in the sense that no matter what
they do, there are always more tweaks and improvements which can be made.
Dialog boxes and the objects contained within them are fairly abstract. A dialog box is like a box containing
numerous objects inside it, and your job as a macro programmer is to come up with an aesthetic and
obvious user interface handling the events which the user invokes as a result of clicking on objects or typing
into them.
The dialog box architecture is loosely based on concepts and ideas which come from: the XView API and
the Xt toolkit API. The XView API, which has now been abandoned by Sun Microsystems is a simple and
easy to use API which allows for the creation of user interface components using a fairly simple syntax and
style. The XView API suffers because it has limited scope for object orientation in its real sense, and it is
difficult to create nested components. On the other hand, the Xt API is a very large and complicated API
which can be very difficult to understand.
The de facto industry standard, the Microsoft Windows API is also a complex API with hundreds of
functions.
One of the problems in building a user interface library is to provide simplicity of operation combined with
enough expressive power to achieve anything possible. No commercial API has achieved that because,
quite simply, it is not possible to support a user interface with wildly differing requirements but at the same
time to achieve programming simplicity. User interface programming is more akin to real-time programming
where things can happen at random, depending on the actions of the user.
CRiSP does not attempt to solve all problems. It simply provides a programming paradigm that is sufficient
for its purposes of allowing the user interface of CRiSP to be extended and customizable.
In attempting to learn and understand the CRiSP API, it is useful to have some grounding in windowing
system API programming. It is important to understand the issues before coding anything. GUI programming
has proved to be a difficult area for the industry and there are numerous reasons why.
When programming something like a dialog box, it is typical that the functional requirements will change. A
layout or user interface component may need enhancing. A program structure which appeared reasonable
to start off with can be a maintenance nightmare as the program evolves.
Consider the following. In a typical Microsoft Windows environment, a dialog box is created by a description.
This description can come from a plain text file (a resource file) or from an interactive tool, such as the
Visual-C appWizard. Both of these approaches are fine for quickly creating a dialog box, but they can be
very tortuous to change a dialog box, or to have it adapt. For example, a dialog box may contain a single line
input field and an OK button. What happens if the user wants a different sized font? Microsoft Windows until
very recently has not addressed this issue. If you increase your screen resolution to get more pixels on the
screen then your dialog boxes get proportionately smaller until at some point they are difficult to read.
On the other hand, the X11 windowing system addresses this area very cleanly, by virtue of 'geometry
management'. Geometry management is a very important concept which is very difficult to understand
completely. In the Microsoft Windows environment, you tend to describe dialog boxes by using absolute
pixel co-ordinates. This means you cannot scale things very well because otherwise one user interface
component can extend into and overlap another one. With the X11 system (as promoted by the Xt and Motif
toolkits), dialog boxes tend to be described by a set of layout semantics. Instead of saying "Input field#1" is
located at x,y co-ordinates (100,200), and that the "OK" button is located at (200, 250), you would say,
"place the OK button below the input field". Now if the user were to use a larger or smaller font, the relative
placement of the objects will avoid any form of overlap and maintain an aesthetic appearance.
Of course, this description is overly simplistic. You can achieve either effect with either windowing system.
However, the code to do this is not necessarily obvious. It is not uncommon with GUI programming to spend
inordinates amounts of time solving seemingly trivial problems, such as why doesn't this push-button appear
where I expect it to.
At best it is safe to describe windowing programming as a non-linear programming methodology. This
means that you do not follow a sequence of steps and eventually obtain the desired end result. Instead you
handle multiple lines of execution at the same time, and you try to prove your code is correct by repeated
testing.
Overview of the Dialog box system
In order to understand how CRiSP supports dialog boxes, it is necessary to think of the steps involved in