The InputEvent class defines a recent "inputevent", providing methods to populate the object with the event information and to define any behaviors associated with such events.

The InputEvent class does not handle 4GL events, it deals with a new set of OpenROAD triggers, which could be considered sub-events that can happen at any moment, regardless of what 4GL is running. It enables “defined behaviors” (trigger-response combinations) to be built into OpenROAD and to execute automatically, leaving developers free to concentrate on business-specific features using the standard 4GL event coding.

You can declare variables of type InputEvent anywhere in the application for your purposes; additionally there is a global variable CurInputEvent available for use. If you have an existing variable of that name, use core!CurInputEvent to distinguish the global InputEvent variable.

All of these trigger immediately—they are not queued like conventional 4GL events.

There are also built-in responses that support multi-action buttons (the kind with an optional dropdown arrow) and choicelists on entryfields, sprite and field dragdrop, and hotcursor switching. Built-in responses fill some long-standing gaps in OpenROAD displays.

A number of OpenROAD inputevents (internal events, characterized by the IE_ constants) are triggered by actions that do not also trigger a 4GL event; examples are IE_MOUSEHOVER and IE_KEYDOWN. Optionally, these may send a UserEvent, named for the action, to the current frame, so that you can specify complex 4GL responses to those actions in a simple and familiar way. This applies to the timer-, key-, mousehover-, focus- and init-related inputevents.

To set this up, use the InputEvent.ActivateFields() method. The following code fragment shows how this might be done so that hovering the mouse over or removing text focus from either of the fields "title" and "description" would trigger a UserEvent:

Then add "On UserEvent" blocks to your frame script to define 4GL responses to one or more of these inputevent actions. The following example assumes you have written a procedure called ExplainMarkedWord()):

Any InputEvent defined behaviors can be made "permanent"—saved with the frame—so they do not need to be recreated every time the application runs.

You can implement a wide range of animation effects and combinations such as fly-ins, throbbers, progress bars, custom animations, monitors, and more.