BuildViewer: PROC[ menuLabels: LIST OF ATOM,

BuildViewer makes a viewer for you. A list of ATOMs provides both the labels on the menu buttons and the basis for discriminating between buttons. When a button is clicked, the client-supplied ButtonProc will be called with the button label, the x and y coordinates of the mouse, and the state of the control and shift keys passed as arguments. Mouse button actions outside the menu will also generate calls to ButtonProc using predefined atoms (eg. $LeftButton). The predefined atoms are:

$LeftButton, $LeftHeld, $LeftUp,

$MiddleButton, $MiddleHeld, $MiddleUp, and

$RightButton, $RightHeld, $RightUp.

Look at the procedure, MenuHit, in QuickViewerExampleImpl.mesa for an example of a ButtonProc.

BuildViewer also optionally puts up three buttons compliments of QuickViewer, an erase button for clearing the screen, and "<" and ">" buttons for horizontal scrolling. The standard vertical scroll bar is also available at the left side of the viewer. These features may be disabled if the argument "noScroll" is set TRUE.

The client must provide two other procedures, a ReDrawProc and a QuitProc. The ReDrawProc is called whenever the viewer is moved (eg. moved to the color display) or changed (eg. when another viewer is opened or closed in the same column or a scrolling operation takes place). If no changes are expected this can be a null procedure. The QuitProc can also be a null procedure. QuitProc will be called when the viewer is destroyed, allowing the client a clean way to save state or clean up when done.

DrawInViewer: PROCEDURE [proc: PROC [Imager.Context]];

DrawInViewer is the clients access path to using the imager procedures to draw in the viewer. A call on DrawInViewer is used to pass the name of the procedure you wish to execute to the viewers package. The viewers package will in turn call the supplied procedure, providing the imager context neede by all imager procedures. Again see QuickViewerExampleImpl.mesa for examples of the use of DrawInViewer.

As an alternative to this rather convoluted way of doing things, you can, more simply, grab the context returned by BuildViewer and make calls to the imager using that context. This will automate the callback process for you at the cost of a couple of extra procedure calls in the imager chain. For lengthy procedures, this is the preferred method. Look at the procedure DrawSpiral in QuickViewerExampleImpl.mesa for an example. To keep clean, viewers has to lock up a large part of the world during the execution of a procedure it calls. If your procedure gets into trouble, it can be hard to find out what happened. This latter method reduces such exposure to the time spent in calls on the imager.