Archive for the ‘EGL Widgets’ 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.
This post illustrates how to create a new widget so that it can be included into a new project or existing project.
The widget will present a list of items from which the user may select one, some or all to be included into a working list. As they are select from the original list to be added to the working list they are removed from the list on the left.
Shown here is the widget as it appears in the designer.
The widget includes several functions that allow the developer to establish short descriptions that appear above each list and to populate each ListMulti widget with values. The buttons are left as they appear and let the user move the selected items from one list to another.
Here is an example of the widget as it is used by the main application after it has been fully initialized.
Below is the source code for this very short web-page. The start function does all the work of initializing. In this case the list is filled with different types of aircraft. The user may select one or more from the list at the left and then select the button with the “>” arrow which moves the selected item(s) to the list shown on the right. Modifying the list of selected items (at right) is performed the same way; select the desired items from the list at right and select the button marked as “<" and the items are placed back into the list on the left.
Fig.1 – An example of an application using the widget.
Note the start function’s use of the widget’s functions that let the developer initialize the list entries, the short descriptions that appear above each in addition to the length and width of each list. The widget’s functions are listed here.
- setSelectList(stringArray String) Sets the list of selectable items shown on the left side of the widget.
- setSelectTextLabel(labelText String) Sets the text label appearing over the selection list shown at the left of the widget.
- setIncludeTextLabel(stringArray String) Sets the text label appearing over the include list shown at the right of the widget.
- setListWidths(widths int) Sets the widths of the list windows.
- setListSizes(sizes int) Sets the sizes of the list windows in terms of the number of entries that are visible before a scroll bar is made visible.
Below is the full source listing for the widget. To use it, simply add the code to your project and then drag-n-drop it into your page.
Fig.2 – The full source for the widget.
This post showed how custom widgets can be used and re-used across difference applications. Designing EGL applications in this manner can result in productivity gains by reducing development and testing times.