The edm display engine provides an environment in which individual widgets are created, edited, executed, and finally destroyed. This environment currently depends on X Windows and includes an application context in which all windows on a given display exist and a window context in which an individual widget exists. A widget therefore utilizes resources from both an application context (e.g. colors) and a window (e.g. a graphics context). At this point, the reader should simply appreciate the natural hierarchy that exists between these different objects. Specific X Window related details are discussed in a later portion of this document.
During the operation of the edm display engine, individual widgets are expected to implement various functions and to conform to a particular set of stylistic and performance norms. For example, when a user interactively creates a widget, the edm engine calls the widget constructor and the createInteractive method which should present a widget property dialog box to the user. After populating this property box with the desired information, the user presses the OK button and the engine calls the draw method which draws an edit mode widget image.
An edm widget is thus simply the implementation of a derived C++ class that includes a number of functions (around 30) and behaves in an expected manner. The following senario illustrates the life of a widget and introduces these functions in the context of the edm display engine. Specific widget method names are displayed in italics.
User draws a box and selects widget from a menu. Display engine calls object constructor and createInteractive methods.
Widget pops up a property dialog box in which user chooses various options. User may press OK, Apply, or Cancel button. Handling of events associated with dialog box data entry and action buttons is performed entirely by native widget code with the aid of available helper auxillery classes. The display engine is responsible for dispatching X Window events.
When the user presses OK or Apply, the widget updates its property information and the edit mode widget image. If the user presses Cancel, the widget erases the edit mode image and schedules itself for deletion.
We will assume in this senario that the user presses the OK button. At this point the new widget creation is complete.
As the user manipulates the window, an X Window refresh event might be delivered (when for example, the window is raised or deiconified). If so, the display engine calls bufInvalidate, updateDimensions, erase, and draw.
The user might resize the object in various ways. In response the display engine may call checkResizeSelectBox or checkResizeSelectBoxAbs.
During display edit, the user may perform drag-and-drop related operations. The engine may call firstDragName, nextDragName, and dragValue.
Other methods that might be called in edit mode include changeDisplayParams and changePvNames.
Note: All widgets do not implement updateDimensions, checkResizeSelectBox, and checkResizeSelectBoxAbs.
At some point the user may test the execute mode behavior of the display. The engine calls getButtonActionRequest, containsMacros, perhaps expand1st, activate, eraseActive, and drawActive.
A multiplexor widget may change a symbol in execute mode. The engine calls containsMacros and perhaps the following three methods: preReactivate, expand2nd, and reactivate.
For control widgets, the user may interact with the widget by clicking or dragging the mouse over it. The engine may call btnDown, btnUp, and btnDrag.
When the mouse pointer moves into and out of the region occupied by the widget, the engine may call pointerIn and pointerOut.
During display execution, the user may perform drag-and-drop related operations. The engine may call firstDragName, nextDragName, and dragValue.
In addition to the above, the widget may get PV value change events or various X Window events (which are events that have explicitly been booked by widget code) to which the widget may respond by updating its execute mode image to reflect the new PV value or new X Window state.
When the execute mode test is complete, the user returns to edit mode. The engine calls deactivate, erase, and draw.
The user may then decide to save his edits. In response, the engine calls save. The widget uses an auxillery class to serialize itself to offline storage.
Finally the user closes the edm display. The engine calls the object destructor in which widget code should free all dynamically allocated memory.
The engine calls the object's copy constructor, erase, and draw.
The engine calls createFromFile, erase, draw.