Event tables
The tables in this section describe user interface events, the user actions that generate the events, and widgets that have default behavior for the events. The term field-level widgets refers to any widgets that can be part of a field group in a frame: fill-ins, sliders, selection lists, toggle boxes, radio sets, editors, rectangles, images, text, buttons, combo boxes, and browse widgets. Frames, dialog boxes, windows, menus (including menu bars and pop-up menus), sub-menus, and menu items can also receive events. Note that there is frequently a distinction made between a browse widget and a single cell in an updateable browse. For the most part, a browse cell behaves as a fill-in widget.
The event tables in this section describe the following kinds of events:
Keyboard events
ABL makes all keyboard actions available as events that you can specify by either key label or key function. You can write triggers for these keyboard events, and associate these triggers with any field-level widget that receives input focus. For a complete list of key label and key function names, and information on how to use them, see the chapter on handling user input in OpenEdge Development: Programming Interfaces.
Keyboard events have default effects depending on the widget that receives the event. For example, the “A” key label event displays an uppercase “A” in a fill-in or editor widget, but has no default effect when applied to a button. ABL organizes some key function events into several classes that have default effects on selected groups of widgets. ABL also provides special keyboard events to write default triggers on classes of keys. You can use these default events to write a trigger for all keys in a particular class for which you have not defined a key label or key function event trigger.
Main classes of key function events
ABL supports three main classes of key function events:
Table 111 describes universal key function events.
Table 112 describes navigation key function events.
Table 113 describes field editing key function events.
Default keyboard events
ABL provides two keyboard events that you can use to write default triggers. Table 114 describes these events.
Mouse events
ABL supports two types of mouse events—portable and three-button events. You can use portable mouse events to associate triggers with logical actions of any mouse. You can use the three-button mouse events to associate triggers with specific physical actions of a three-button mouse.
The following tables reference portable mouse buttons for portable mouse events and physical mouse buttons for three-button mouse events. For more information on the mapping between portable and physical mouse buttons and how the AVM processes mouse events, see the chapter on handling user input in OpenEdge Development: Programming Interfaces.
Portable mouse events
Table 115 lists the mouse events that apply to all mice, no matter how the buttons are configured.
Three-button mouse events
Table 116 lists the mouse events associated with physical mouse buttons.
High-level widget events
Table 117 lists high-level widget events. These are events generated by mouse or keyboard actions that perform high-level operations on a widget, such as entering a fill-in, choosing a button, or displaying a menu. Unless noted in the AVM Action column, triggers on these events execute before the AVM applies the event. If the trigger returns NO-APPLY, the AVM does not apply the event. If the trigger executes after the event takes place, NO-APPLY has no effect.
Note: If a CHOOSE, DEFAULT-ACTION, or VALUE-CHANGED event executes a trigger as a result of a mouse click that changes input focus, NO-APPLY will return focus to the widget that had focus prior to the event.
Table 117: High-level widget events Event User action Affected widgets AVM action A keyboard or mouse action that chooses a widget. Button, non-toggle-box menu item Trigger executes after choose takes place A native keyboard or mouse event that confirms the selection of a value in a selection list or browse. In Windows applications, double-click a list item. In character applications, press RETURN or DELETE-LINE. Selection list, Browse Trigger dependent A mouse action that completes a drag-and-drop operation on a widget. Browse, Button, Combo-box, Dialog-box, Editor, Fill-in, Frame, Radio-set, Selection-list, Slider, Toggle, Window Trigger executes after drag-and-drop operation concludesNote: The trigger should call the END-FILE-DROP() method when it has finished processing all the files. Occurs when the user repositions the browse to the end of the query’s result set by pressing the END key. Browse Trigger dependent END-SEARCH1 Occurs when an updateable browse ends a user-initiated search when a user either selects a row marker or clicks in a cell. Browse Trigger dependent A keyboard or mouse action that gives focus to the widget. Browse, browse cell, button, combo box, control container, dialog box, editor, fill-in, frame, radio set, selection list, slider, toggle box, window Trigger dependentNote: For a browse widget, ON ENTRY OFbrowse-name
specifies a trigger for the browse widget and ON ENTRY OFcolumn-name
IN BROWSEbrowse-name
specifies a trigger for a browse cell. The browse cell is the intersection of the named column and the currently focused row. Occurs when the user repositions the browse to the beginning of the query’s result set by pressing the HOME key. Browse Trigger dependent A keyboard or mouse action that changes the current iteration of a browse. This event is obsolete; see the VALUE-CHANGED Event reference entry. Browse Trigger dependent A keyboard or mouse action that takes focus from the widget. Browse, browse cell, button, combo box, control container, dialog box, editor, fill-in, frame, radio set, selection list, slider, toggle box, window Trigger dependentNote: For a browse widget, ON LEAVE OFbrowse-name
specifies a trigger for the browse widget and ON LEAVE OFcolumn-name
IN BROWSEbrowse-name
specifies a trigger for a browse cell. The browse cell is the intersection of the named column and the currently focused row. A keyboard or mouse action that displays a menu. Menu,3 submenu Trigger dependent OFF-END 4 A keyboard or mouse action that tries to move after the last row of a browse. Browse Trigger dependent A keyboard or mouse action that tries to move before the first row of a browse. Browse Trigger dependent An event that each descendant window receives when the common ancestor window in that family receives a WINDOW-CLOSE event. Window Trigger dependent Any browse action that results in a row being displayed in the browse. Browse Trigger dependentNote: The use of triggers for this event is restricted to special cases. When a row is displayed, use a trigger to modify attributes of individual cells in the column. It should be restricted to the following uses: changing cell colors, changing the cell font, referencing the cell in an expression, and (in Windows) changing the cell format. A keyboard or mouse action that gives an updateable cell focus in a browse row. Browse Trigger dependent A keyboard or mouse action that takes focus from the browse row where an updateable cell has focus. Browse Trigger dependent A mouse action in the scrollbar area of a browse. Browse Trigger dependentNote: This event allows the developer to track physical movement of the focused row in the browse viewport. START-SEARCH1 A keyboard or mouse action that places an updateable browse into search mode. Browse Trigger dependent A keyboard or mouse action that changes the value of a widget. For the browse, any action that selects a row. Browse, combo-box, editor (Windows GUI only), fill-in, radio set, selection list, slider, toggle box, toggle box menu item Trigger executes after value changes A keyboard or mouse action that causes the native window manager to close the affected window or dialog box. Dialog box, window Trigger dependent WINDOW-MAXIMIZED1 A keyboard or mouse action that causes the native window system to resize the window to its maximum size. Window Trigger executes after event takes place. However since the native system has control, a NO-APPLY does not stop the event from occurring.Note: This event occurs only in Windows. A keyboard or mouse action that causes the native window system to minimize (iconify) a window and hide all of its descendant windows. Window Trigger executes after event takes place. However, since the native system has control, a NO-APPLY does not stop the event from occurring. A keyboard or mouse action that causes the native window system to resize the window to any extent vertically or horizontally. Window Trigger executes after event takes place. However, since the native system has control, a NO-APPLY does not stop the event from occurring. A keyboard or mouse action that causes the native window system to restore a window and any descendant windows to the state they were in before a prior maximize or minimize event. Window Trigger executes after event takes place. However since the native system has control, a NO-APPLY does not stop the event from occurring.
1Windows only.
2Graphical interfaces only.
3Supported only if the Menu POPUP-ONLY attribute is set to TRUE and the menu is set as a popup for some other widget.
4The OFF-END event can also occur when there are more rows to retrieve in the query on a ProDataSet temp-table buffer. For more information, see the "ProDataSet events" section.
Direct manipulation events
Direct manipulation events are ABL events that directly modify the size, shape, position, and appearance of a widget. These events are generated by mouse actions. Each user interface widget either has direct manipulation enabled or does not. Some types of widgets, such as menus, cannot have direct manipulation enabled. You can enable widgets for direct manipulation by setting the SELECTABLE, MOVABLE, or RESIZABLE attribute to TRUE.
If a widget has direct manipulation enabled, then direct manipulation events take priority over all other events. In other words, while data manipulation is enabled, the widget cannot perform data entry or application control functions. For example, if you set SELECTABLE to TRUE for a button, ABL interprets a MOUSE-SELECT-UP event as a SELECTION event. If you set SELECTABLE to FALSE, ABL interprets the same event as a CHOOSE event.
Direct manipulation events can be broken down into two types: general and frame-only. General direct manipulation events apply to both field-level and frame widgets. Frame-only direct manipulation events apply only to frames.
The following sections list the ABL events associated with direct widget manipulation. The user actions listed for these events assume that you set the appropriate attributes to make each event possible. For example, a widget must be SELECTABLE to receive the SELECTION event.
General direct manipulation events
Table 118 lists the direct manipulation events that apply to field-level widgets and frames.
Frame-only direct manipulation events
Table 119 lists the direct manipulation events that apply only to frames.
Developer events
ABL provides eleven events, labeled U1 through U10 and CLOSE, that you can invoke on any widget using the APPLY statement. The only function of a developer event is the one provided by your own trigger definition.
Socket events
ABL looks for events to execute in the context of U/I blocking statements. During this processing if the AVM detects that data is available on a socket or that the remote end closed its socket or it detects that a client has connected to a port that the server has enabled connections to, a socket event is generated.
There are only two socket events, the READ-RESPONSE event, which applies only to socket objects, and the CONNECT event which applies only to server socket objects.
READ-RESPONSE event
AVM Detects — Data is available on a socket or the remote end of a connection has closed its socket; applies only to socket objects.
AVM Action — The AVM invokes the READ-RESPONSE event procedure.
The SET-READ-RESPONSE-PROCEDURE( ) method is used to name the READ-RESPONSE event procedure and to associate it with a socket object. The AVM invokes this procedure whenever it detects that data is available on the socket or that the remote end of the socket has closed its end of the socket. In this procedure, the SELF handle identifies the affected socket object.
To determine if the event procedure was invoked because data is available for reading or because of a disconnect, the application can use one of several methods:
- The CONNECTED( ) method returns FALSE if the socket is not connected to a port, TRUE if it is connected.
- The GET-BYTES-AVAILABLE( ) method returns zero if the socket is not connected to a port or the number of bytes available for reading if it is connected.
- The READ( ) method returns FALSE if the socket is not connected to a port. It returns TRUE and the read data if it is connected.
CONNECT event
AVM Detects — A client has connected to a port that the server has enabled connections to; applies only to server socket objects.
AVM Action — The AVM invokes the CONNECT event procedure.
The SET-CONNECT-PROCEDURE( ) method is used to name the CONNECT event procedure and to associate it with a server socket object. The CONNECT event procedure must accept one input parameter of type HANDLE. This is the handle to the implicitly created socket object for this connection. It is via this socket object that the server communicates with the client.
If the SET-CONNECT-PROCEDURE( ) method is not invoked, or if it fails, no connection procedure will be executed when the CONNECT event occurs.
ProDataSet events
ABL provides events you can invoke to execute application-specific code that handles FILL operations on a ProDataSet object or Buffer object, as well as row-level change operations. You can use the SET-CALLBACK-PROCEDURE( ) method to associate an action with these events.
Event procedures must define a single parameter for the ProDataSet object (DATASET or DATASET-HANDLE) as an INPUT parameter BY-REFERENCE. This allows the event procedure to operate on the ProDataSet object using static ABL to reference its buffers and fields, without the ProDataSet object being physically copied. This also means that because the ProDataSet object is not copied, changes made to the ProDataSet object by the event procedure are made to the same copy used by all procedures.
The following sections describe the ProDataSet events:
FILL events
There are two levels of FILL events: the first level is for a ProDataSet object or one of its member buffer objects; the second level is for individual records created in each temp-table.
Table 120 lists the first-level FILL events.
Table 121 lists the second-level FILL events. These events occur once immediately before or after each record is created in a temp-table during a FILL.
Row-level events
Row-level events are defined for making local changes to the records in a ProDataSet member buffer object. Table 122 lists the row-level events.
OFF-END event
The OFF-END event occurs when you position a query on a ProDataSet temp-table buffer past the last row. You can use this event to retrieve additional data source rows to add at the bottom of a ProDataSet temp-table (for example, in batches when there are too many data source rows to retrieve at one time).
The OFF-END event can also occur when the user performs a keyboard or mouse action in a browse that scrolls off the end (past the last row) of a browse on a ProDataSet temp-table buffer. For more information about using the OFF-END event with a browse, see the "High-level widget events" section.
Note: The OFF-END event is similar to the QUERY-OFF-END attribute, which is set to TRUE whenever the associated query object is positioned past the last row. The difference is that you must test the QUERY-OFF-END attribute for this condition at a specific place in your application code, whereas the OFF-END event procedure executes like a trigger whenever the event occurs.Consider the following restrictions when using the OFF-END event with a query on a ProDataSet temp-table buffer:
- You can attach these events only to a query on a single ProDataSet temp-table buffer. You cannot attach these events to a query on a database buffer, or a query that involves a join.
- The query must be a scrolling query.
- If you never RETURN NO-APPLY, from the OFF-END event handler, the query will infinitely loop.
- Call the SET-CALLBACK-PROCEDURE( ) method before the query is opened.
- If you use the GET LAST statement or GET-LAST( ) method to get the last record associated with the query, the event handler is called repeatedly until it does not RETURN NO-APPLY (indicating that all records have been retrieved). For this reason, use caution when offering users the GET LAST action.
- The INDEXED-REPOSITION option is ignored for the query.
FIND-FAILED event
The FIND-FAILED event occurs when a FIND on a ProDataSet temp-table buffer fails. This can be the result of the FIND statement (but not the FIND NEXT, FIND PREV, or FIND LAST statements, and not the CAN-FIND function), or the FIND-FIRST( ) or FIND-UNIQUE( ) methods (but not on the FIND-LAST( ) method).
You can use this event to adjust the contents of the ProDataSet object. The event handler must be able to determine the action to take based on the context of the ProDataSet object, and must RETURN NO-APPLY to indicate the action was successful. For example, when the event occurs, the event handler could retrieve a missing row or a set of related rows from the server automatically.
SYNCHRONIZE event
The SYNCHRONIZE event occurs when a ProDataSet temp-table buffer is synchronized. That is, when the SYNCHRONIZE( ) method is run on the buffer or a parent buffer, or the buffer is selected in a browse. The event handler is invoked recursively at every level of the ProDataSet object hierarchy just before the recursion to the child levels.
By default, if the query is associated with a browse, the synchronize action of reopening the query automatically refreshes the browse. If the query is not associated with a browse, the synchronize action automatically gets the first row in the query by invoking a GET FIRST operation. If there is a REPOSITION data relation and no browse, the synchronize action gets the next record in the query by invoking a GET NEXT operation. Once these actions attempt to populate the buffer at a particular level, the SYNCHRONIZE event runs before moving recursively to the next lower level.
This event allows you to fetch rows, display buffer values in a frame, or take some other action. The handler procedure can also RETURN NO-APPLY to cancel the cascading of the synchronization to child buffers.
OpenEdge Release 10.2B
|