Archive for the ‘EGL- InfoBus’ Category
A Dialog Box that uses the InfoBus to Communicate User Driven Events
This post covers the creation of a dialog box and shows how to instantiate it, populate the titles and messages and how to communicate user driven events back to the parent program which launched it. The InfoBus is employed to communicate button events back to the parent program so that it may close the dialog and to act upon those events.
The problem which this post addresses centers on the need of the application to launch a process only after asking the user if it is OK to proceed. The application launches a dialog by injecting a specified widget into a DojoDialog. When the dialog is displayed the user can select the “Cancel” or “Approve” button. At this point the event must be communicated back to the parent application so that it can A.) close the dialog and B.) either launch the process that has been approved by the user when selecting the “Proceed” button or do nothing because the user selected the “Cancel” button. The dialog box is shown below.
The source for the dialog box and the code used by the parent application to launch it.
This section presents the source code for the dialog box along with the code used in the parent application which properly sets it up for presentation to the user.
The dialog box source.
Looking at the code there are two components that are established for a message title and an area for detail related messages. These are messageTextLabel and messagesTextArea The host program launching the dialog is responsible for populating these. In addition there are two functions which handle the button events. These are ApproveButton_onClick(event Event in) and CancelButton_onClick(event Event in)
Fig.1 – Source code for the dialog box (ApproveDialog.egl)
The code used by the parent application to present the dialog box
Shown below is the source code for the function in the parent application which launches the dialog box. It shows how it instantiates an object derived from the source presented above and how it injects the object into a DojoDialog box which simply acts as the container or frame for the object which represents its main body. It also shows how those message components are used.
Fig. 2 – The Service Return function that launches the dialog box.
The service return function above determines if the process has already been performed. While the process can be performed more than once, it is desirable to inform the user before proceeding. The dialog box is used present the outcome of that process to the user so that they can either cancel or proceed.
So far, we’ve shown how a simple widget that acts as the main body for a dialog box is injected into a DojoDialog component that acts as its container. When the DojoDialog is presented to the user they can interact by selecting one of the two available buttons. The buttons then fire the appropriate event functions which we’ll focus on in the next section.
Using the InfoBus to provide a communication link
The parent application relies upon the InfoBus to receive information about events taking place between the user and the dialog box. To receive this information the following lines are added to the start() function in the parent application.
Fig.3 – The Parent Application. Register to the InfoBus the names of the callback functions.
See Fig. 5 for details of these functions, also in the parent application.
As seen in figure 2, the parent application “owns” the dialog meaning it holds a reference to the dialog object. When displayed the dialog is holding a conversation with the user who can select one of two buttons. No matter which button is selected, the dialog “owns” that event. There are 2 problems to be solved here, the first being the dialog cannot close itself, since it is the application which holds the object reference to the dialog. Any attempt by the dialog to close itself results in an “object not found” error. The second problem is then how to communicate the button event back to the application so that it can close the dialog, since it holds the reference to it, and then either do nothing or proceed with the process.
To accomplish this, the dialog has these button-event functions ApproveButton_onClick(event Event in) and CancelButton_onClick(event Event in), shown below.
Fig.4 – The dialog’s button-event functions
They are called when either the Approve and Cancel button are selected. These functions use the InfoBus to “publish” the need to call a function that resides in the parent application. Notice that the constants used (their values are arbitrary) are the same constants used by the parent application’s start up processing which registered the call-back functions. Those functions that are in the parent application are going to get called whenever one of the functions are called.
The constants CONST_APPROVAL_PROCESS_APPROVE_DIALOG_APPROVE_EVENT and CONST_APPROVAL_PROCESS_APPROVE_DIALOG_CANCEL_EVENT of the ConstantsLibrary are used by the Infobus.publish command to establish links back to the parent application’s ApproveDialogCancelButtonInfoBusCallBack and ApproveDialogApproveButtonInfoBusCallBack functions. The values of the constants are arbitrary in nature meaning their values don’t really matter. They simply act as a handle or a means by which a lookup can be performed so that the proper function can be called when the user selects either the “Cancel” or “Approve” button.
When the user selects either button provided by the dialog the function in the parent application is called which then closes the dialog and then proceeds with the appropriate processing.
Fig. 5 – The event functions for the Approve and Cancel buttons.
Shown here is the parent application after the user has selected the “Approve” button. As a result, another dialog is presented which indicates the process has been launched.
This post showed how to create a somewhat reusable dialog box to be injected into a DojoDialog component which was then instantiated, initialized and presented by the parent application. The problem of communicating dialog button events back to the parent application was addressed by the use of the InfoBus which calls the appropriate functions for further processing by the parent program.