Event based Programming

Post date: Feb 15, 2011 4:27:01 AM

Conceptual Background:

Although the user perceives the application as an environment in which several tasks can be performed concurrently, events in an OpenROAD application are executed one at a time. The sequential ordering of tasks is handled by the event queue that is maintained for an entire application, as well as event queues for each frame.

Event code is not necessarily executed immediately after the event is triggered.

The process for executing events is:

1. When the event is triggered, OpenROAD sends the event code to the bottom of the application event queue.

2. When the event reaches the top of this event queue, OpenROAD dispatches the event to the bottom of the appropriate frame’s event queue. If the event is a user event from an external application, it may go to more than one frame.

3. The event code block is executed when the event reaches the top of the frame’s event queue.

Although actions may appear to the user as concurrent, you must consider the exact order in which various events are triggered. When you understand how the events work, you can use OpenROAD to communicate between frames for synchronization and to ensure that the user can perform tasks concurrently.An important concept to keep in mind when planning your OpenROAD scripts is that the user’s actions, rather than the order of your code, control the flow of the application.In most cases, the code that you provide for a particular event is executed only when the user triggers that event from the user interface. Depending on how the user interacts with the application, the order in which the events are triggered may differ and some events may not be triggered at all.

The order in which the events are placed onto the application event queue if the user clicks on  Button A, Button B, Button C, and Button D, is as given

below

click event of btn A

click event of btn B

click event of btn C

click event of btn D

In this example, the events will execute in the same order in which they are placed on the application event queue. However, it is possible to have events execute in a different order when external or user events are being sent. When a frame is blocked (for example, by a WaitFor), external and user events are still delivered. They are not executed until the event that the frame is waiting for arrives. Events that occur later in time for unblocked frames will execute before the earlier events of the blocked frame. You should not rely on the sequence of events as a means of simulating the effect of a local procedure. To avoid duplication of code, use a local procedure instead of sending a user event to the current frame.

 The Ordering of Events: Event Queues:

OpenROAD processes a separate queue for each active frame. If there are two or more concurrently active frames, there is no guarantee as to the order in which the frame queues are processed. Therefore, if you send a user event to more than one active frame, you cannot assume that the order of sending will be the order of processing.

Within a queue, events are processed on a “First In First Out” (FIFO) basis. When OpenROAD processes the frame queue, it finishes executing the current event block before executing the next event on the queue. By default, when the event is being executed, all the open frames are blocked so that the user cannot select ahead and trigger more events. However, you can change this behavior by setting the BlocksFrames attribute to FALSE. The following example event block from the video_detail frame includes the SendUserEvent method,

which triggers the specified user event. When OpenROAD executes this method:

1. It sends the UpdateTitle user event to the application event queue and finishes executing the SetValue event block.

2. When the UpdateTitle event reaches the top of the application event queue, it places this event on the frame queue for the graphic_frame frame.

3. It executes the code associated with the UpdateTitle user event only after that event reaches the top of the frame queue.

on setvalue video.title =

begin

CurFrame.WindowTitle = video.title;

if graphic_frame is not null then

 graphic_frame.SendUserEvent (eventname = ’UpdateTitle’, messagevarchar = video.title);

endif;

end

Event Types:

The online help describes the events you can include in your application. These events can be grouped into the following basic types:

1. frame events

2. field events

3. menu events

Frame Events:

Frame events include events that are triggered by user interactions with the frame’s window, such as the WindowResized event which is triggered when the user resizes the window. Frame events also include interactions with the background of the frame, such as the Details event, which is triggered for the frame when the user chooses the Details button on the area surrounding the fields. The following example from the video_detail frame script shows the event block for the WindowIcon frame event. This event is triggered whenever the user iconifies the video_detail frame. The code in the following Step 2 prevents the child, graphic_frame, from remaining displayed if the parent frame is iconified. If a user iconifies the parent frame, this event:

1. Verifies that graphic_frame is displayed.

2. sets the WindowVisibility of that frame so that it will also iconify.

on windowicon =

begin

if graphic_frame is not null then

 graphic_frame.WindowVisibility = WV_ICON;

endif;

end

A frame also receives child events when the user interacts with the fields on the form. Because the form associated

with the frame is considered a single subform containing all non-menu fields on the frame, events triggered in any field

also trigger a child event for the frame. This enables the frame to provide generic code that is triggered when any of the

fields on its form receive a particular event. For example, a frame receives a ChildEntry event when any of its child

fields receives an Entry event. The following ChildEntry event block changes the color of the field that the user has

entered to pale cyan.

This code uses the TriggerField attribute of the FrameExec system class to determine which entry field triggered the current event:

on childentry =

begin

if CurFrame.TriggerField.ISA(class =EntryField) = TRUE then

EntryField(CurFrame.TriggerField).BgColor=CC_PALE_CYAN;

endif;

end

WindowClose and Terminate are two other important frame events:

WindowClose

This event is triggered when the user selects the window manager close operation for the running

frame.

Terminate

This event is triggered in any of the following circumstances:

• When the frame is closed by the Terminate method

• When the frame’s parent frame closes itself

• When the frame’s parent is itself closed by another frame or procedure

• When the user selects the window manager Close operation for the running frame You

can use an event block for either the WindowClose or Terminate events to clean up  

frame (for example, to close open transactions) prior to closing it. To keep the window

open under specified circumstances, use the WindowClose event. The UserEvent event, which is a

user-defined event used primarily for communicating between frames and with external programs, is

also considered a frame event

Field Events

Because users mostly interact with individual fields on a form, the events for fields are the most diverse and complex.

For example, the following table summarizes the events that can be triggered by a user for a button field: