User Interface

only for RuBoard - do not distribute or recompile

This application will be called Worldwide Commissions, and the MySQL database will be called commish. The user will initially be presented with a login form (frm_login), followed by a table-view form (frm_table_view) in which she can view the tables she is authorized to see, along with some basic sorting capabilities. The one person authorized to alter the data and produce the commissions reports will also have access to the form that processes the data (frm_commissions); changes to the data can only be made from frm_commissions.

Login Screen: frm_login

First the user will be presented with the login screen. Figure 8.1 shows the schematic of the Login screen. The user will be able to log in and also be able to change his password for the commissions application. In order to change the password, a user will have to enter their login and password anyway. So if all checks pass, the Change Password button will also log them in.

Figure 8.1. frm_login, the Commissions login screen for design.

lbl_messages at the bottom of the screen will be used to communicate messages to the user such as Could not connect to server... or Your new password must have at least four characters in it and so on. Figure 8.2 shows the widget container schema for frm_login.

Figure 8.2. frm_login widget container schema.

frm_login will start with a four-row vertical packing box, into which will be placed the widgets as displayed. The login entry boxes will be placed inside three-by-three table widgets. Clearly, the widgets could be placed into a single vertical packing box, but in this case, users have an expectation of what a login screen should look like. So it is probably best to try to meet that expectation.

Table Display Form: frm_table_display

When the user logs in, this will be the screen he will initially see. Figure 8.3 shows the form design. This window is dominated by the CList widget in the center; it will dynamically show the table selected in the combo box.

Figure 8.3. The frm_table_display design.

frm_table_display will display the following behaviors:

The Table List combo box in the upper-left corner will list all tables the user has privileges to view. It will be filled from one of the database tables, based on the login name given. When the user changes it, the CList widget in the center of the form will change to the newly selected table. The combo box will have its Limit to List property set to Yes.
The Process button in the upper-right corner will only be visible to the person currently listed as authorized to do the processing in the database security table(s). It will be a hide/show widget rather than active/inactive and set at login time.
The Refresh button in the lower-left corner will refresh the CList widget.
The Sort button will work in combination with the spinbutton widget and combo box at the bottom of the screen. Read from left to right, the widgets will be used like this: sort column X ascending /descending. These will allow the user to sort the CList widget based on a designated column. For a long list of items, this will make searching for a certain row easier, without having to code a find routine.

Figure 8.4 shows the widget containment scheme for frm_display_table.

Figure 8.4. The frm_display_table widget container schema.

Process Commissions Form: frm_commissions

Only one FA at any given time will have the authority to alter the database. That is, only the designated FA can process commissions, or add, delete, or modify a data row. Since these permissions are granted only to one person, the controls to perform these functions can all be placed on frm_commissions. Figure 8.5 shows the design layout of frm_commissions.

Figure 8.5. frm_commissions is used for processing commissions and editing tables.

frm_commissions will function according to the following points:

The processing function can be broken into 10 steps: 2 prep, 6 processing, and 2 output or post-processing steps. The 10 command buttons in the top half of Figure 8.5 are for performing these steps. The FA needs to be able to process each step and then verify what was done. The boxes to the right of the command buttons are labels for communicating results to the user.
The two preparation steps are (1) archive previous data and (2) import the revenue data into tbl_revenue.
The six processing steps are outlined here:

Calculate the commissions as indicated in the imported table.
Calculate the commissions for those paid worldwide.
Calculate the commissions for those paid for all sales in a country.
Calculate the commissions for those paid for all sales in a state.
Calculate the commissions for those paid for all sales made within a ZIP code.
Calculate the commissions for those paid based on other people s revenue.

The two output or post-processing steps are (1) create an information file for each salesperson who was paid anything and (2) create a file for each country showing who was paid and how much.
The three command buttons at the bottom of Figure 8.5 are for making changes to the data in the tables. They allow the authorized user to add, delete, or change the data in any of the tables.

Figures 8.6 and 8.7 show the container widget schema for frm_commissions. Note that Figure 8.7 shows the detail for the table that makes up the largest part of the form (table_10_by_3); this is done simply to make the diagrams more easily understandable. Figure 8.6 gets too cluttered when it also contains Figure 8.7.

Figure 8.6. The frm_commissions widget container schema.

Figure 8.7. table_10_by_3 shows a detailed section from Figure 8.7.

only for RuBoard - do not distribute or recompile