Event handling

From PxPlus

Jump to: navigation, search

Contents

Introduction

PxPlus Version 11 includes application EVENT handling that will allow for the simple generation and intervention of key specific events within an application program. The developer will have the ability to define (by name) application generated events, the parameters associated with each event, and how each of these events will be processed.

Problem Statement

In many applications, developers would like (or require) a means to intercept specific events within the system such as adding/removing clients, posting GL transactions, and printing reports. The ability to intercept when these occur and to run site/user specific code, provides the ability for application developers to create add-on modules/components that satisfy specific client needs.

A simple means of detecting and responding to these occurrences (events) does not currently exist in the PxPlus language.

Previous Options

In order to provide similar functionality, a few options currently exist:

  1. In each component module have a number of pre-defined "Callouts" to custom/site specific code. For example whenever a Customer is added to the system, have the problem issue a CALL to a standardized 'Stub' (empty sub-routine) that could be tailored to the specific requirements. Problems with above:
    • It would be difficult to implements if multiple pieces of code are required on a single event
    • The additional "CallOuts" could add a significant load on the system.
  2. Use Objects and have replacement object replace specific methods and/or properties. The Objects could inherit the primary application object and just intercept those methods that are needed. Problems with above:
    • Requires the use of Object Oriented programming which existing applications may not be designed to use
    • Trying to overlay a method often means that the programmer needs to duplicate a significant amount of code if the place you want the actual interception point is midway through the function. The only way to avoid this is to break the object into multiple methods, with each trappable event being an individual method.

Solution

Overview

Adding built-in event processing logic to the PxPlus interpreter has helped address many of the problems mentioned above. Two directives were added to the system, one that allows the programmer to define what 'action' will occur when an event occurs in terms of program to call / perform or Object method to execute. Once defined, the actions will be kept internally within PxPlus. The second directive actually initiate's the event and can optionally pass values to/from the event handler.

If no action is defined for an Event, the event will be ignored. If one or more actions are specified for an event, the actions will be executed in the order in which they were defined.

Language Changes

The following two new directives were be added to the language:


To Define the Actions to take when an Event occurs:

ON PROCESS EVENT "NameOfEvent"  [ REMOVE ] [ CALL "..." | PERFORM "…" | ObjectId'Method() ] 

This directive is used to define the action to be done when the event "NameOfEvent" occurs. Possible actions include calling a program, performing a program or invoking an object method. The actual name of the event is up to the user and is case insensitive. Event names must be non-blank between 1 and 32 characters is length.

To remove an action the programmer can specify the same CALL/PERFORM/Method parameters used to add the event preceded by the keyword REMOVE. No error will be generated if the action/event specified does not exist.


To initiate the occurrence of an Event:

PROCESS EVENT "NameOfEvent" [, ERR=stmtref ] [,arglist…]

This directive will cause the system to execute the actions assigned to the Event named. It will also pass any parameters (values, variables, or expressions) supplied in the arglist to the action processing logic. In the case where an action is an object method, the arglist will be passed to the method as if entered between parentheses.

An optional ERR= branch may be supplied to trap any errors which may occur or be returned by the event actions.


Getting access to Event action table:

The application programmer can use the TSK ( ) function to view which Events are defined in the system and what the associated action is for each. New TSK function option:

TSK (EVENT)

This new EVENT option to the TSK function returns a list of all Events that currently have actions associated with them. Each entry will consist of the event name followed by a TAB ($09$) and the action followed by another TAB ($09$) and a Line Feed ($0A$).

The same values can be returned by the system inter-task debugger using TSK(*EVENT) and will return the list for the task currently being debugged.

Benefits

There are a number benefits realized by using this approach to event handling over the methods currently employed within applications:

  1. Performance of the system and handling of events is more efficient as this logic will be done internally within the PxPlus executive modules as opposed to by external 'interpreted' application logic.
  2. Multiple actions for an event can be easily supported by the system.
  3. Works with Objects and 3GL style coding.
  4. Allows virtually unlimited number of events with very low overhead to initiate event.

Summary

This new V11 feature provides an easy to use mechanism to add Events to business applications. The core design can be easily extended to allow system 'internal' events to be added the event table thus in a future release we could add hooks to external events such as receiving data on a communication channel, file updates, etc.

Personal tools