InputEvent Class
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.
Available triggers include:
• Mouse actions (down, up, enter, exit, setfocus, losefocus, move, hover)
• Double-click actions for the left, right, and middle button (with or without modifying key-press)
• Timer actions (pulses and tick events)
• 4GL-triggered actions
All of these trigger immediately—they are not queued like conventional 4GL events.
You can define single or multiple responses, field-specific or generic, to any occurrence of any such sub-event. Responses may include:
• Changing style or emphasis:
– Switching the background image within the multi-image BgBitmap
– Changing the mouse cursor
– Modifying a wide range of highlight properties, background sprite positions, appearance, or activation
• Triggering 4GL procedures to provide complex custom logic and effects
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:
fields[1] = field(title);
fields[2] = field(description);
CurInputEvent.ActivateFields(fields=fields, usereventactions='IE_MOUSEHOVER IE_LOSEFOCUS');
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()):
on userevent 'IE_MOUSEHOVER' =
{
targetfield = curframe.MessageObject;
CurInputEvent.LastInputAction(targetfield=targetfield, action='mousehover');
callproc ExplainMarkedWord(string=description,
wordloc=CurInputEvent.CharacterPosition);
}
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.
Inherits From
Inherited By
None
Attributes
Action
FieldID
FieldX
FieldY
FrameID
ModifierKeys
MouseButton
ScreenX
ScreenY
Sprite
Tick
VirtualKey
Methods
ActivateFields
EventKey
LastInputAction
LoadEventBehavior
QueueResponse
RemoveEventBehavior
Response
StopEventBehavior
TriggerEventBehavior