The odds are pretty good that you can see at least one calendar from where you are now seated. Calendars have always been a necessary part of any business environment. In respect to information services, almost all data entry functions involve one or more date fields. If you take these two facts under consideration, you could probably draw the following logical conclusion: Combining an online calendar with data entry functions will save labor and enhance ease of use. It is this very premise that serves as the foundation for this article.
Past and Present
If you followed our article last month (“Turning Pop-ups into Home Runs,” MC, August 1998), you will remember that our focus was on using pop-up windows to enhance software “usability.” This month’s focus is going to follow the same theme, except that we will show you how to code a pop-up calendar that is ready for the Year 2000 and beyond.
The simple print request program seen in Figure 1 looks very much the same as the print request program we looked at last month. The RPG IV code in Figure 2 is the code to replace the Browse subroutine in the PRT002RG program we published last month (the differences in the subroutine are represented by the shaded area of the code). You may find the code for the PRT002DF display file and the PRT002RG RPG IV program either in last month’s issue of Midrange Computing or on the Web site at http://www.midrangecomputing.com/code.
What’s new in this article is the pop-up window calendar program seen in Figure 3. The pop-up calendar can go back to January 1, 1901 (the base date used in the calendar program) or forward for the next 8,000 years or so (assuming IBM maintains the sliding window. It is currently 40, but it will probably be 50 in the next couple of years or so). This can be accomplished because of the date data type and the date “math” that RPG IV
allows us to use. Obviously, the calendar program is Y2K safe and may be called from any RPG III or RPG IV program.
What a Difference a Date Makes...
Let’s begin by talking about the simple print request prompt screen seen in Figure
1. If you read last month’s article, you will remember that this program allows operators to press the F4 prompt key when the cursor is located on the printer field. The result of this action is that a pop-up window with a list of available printers is presented on the screen.
This month, we updated the program so that the operator could also press the F4 prompt key when the cursor is located on either the “from” or “to” date fields.
The pop-up calendar seen in Figure 3 will be presented when F4 is pressed and the cursor is located on either field. The operators may use the Page Up or Page Down key to scroll through the months until they find the desired month, day, and year. They may then select a date by keying the two digits they see on-screen, which represent the date they wish to select. The corresponding date will be returned to the calling program.
By examining the code in Figure 2, you can see that the Browse subroutine calls the CAL001RG program (which you can download from the MC Web site at http://www.midrangecomputing. com/code), which presents the pop-up calendar, or it calls the WIN001RG program (seen in last month’s article), which presents a pop-up window for printer selection.
The determination for which program is called is predicated upon the name of the field where the cursor resides when the F4 key is pressed. If the cursor is on the field named PRINTER, the WIN001RG program will be called so that the operator may select a valid printer from the selections presented in the pop-up window program. If the cursor happens to be positioned on the fields named FROMDATE or TODATE, the CAL001RG program will be called, and the pop-up calendar will be presented.
Regardless of which program is called, the operator will have the opportunity to select one of the options, and the associated value will be returned to the print request prompt screen.
In last month’s article, we discussed how the Return Cursor Location (RTNCSRLOC) DDS keyword utilized in our display file (seen in last month’s article) can be used to tell your RPG programs where the cursor is located when certain functions are performed. In that example, the field named CSRFLD (cursor field) is defined as a hidden field (designated by a usage of H in column 38) at the field level of the display file and then used in the record level when the RTNCSRLOC keyword is specified. The combination of these two DDS allows us to query the field named CSRLOC from within our RPG IV program to determine the field name where the cursor resides at the time F4 is pressed. If the field name in CSRLOC is deemed to be “browse” or “prompt” capable, the appropriate pop-up window program is called and the operator makes the desired selection.
The CSRROW (cursor row) and CSRCOL (cursor column) hidden fields defined in the display file are used in conjunction with the CSRLOC (cursor location) DDS record- level keyword to set the cursor location, once the browse function has been performed. This function is explained in detail in last month’s article.
I’m Late! I’m Late for a Very Important Date!
Now that we have covered the background material and the print request prompt program, it is finally time to get to the principal purpose of this article.
The pop-up calendar seen in Figure 3 is coded using the display file described in Figure 4 and the RPG IV program CAL001RG.
Taking a look at the DDS for the display file in Figure 4, you can see that the primary record format is coded using DDS window keywords that invite the system to take care of the pop-up window management for you. The Page Up and Page Down keys are allowed because that is how the operator will page back and forth through the months and years.
We also specified a dummy format with the KEEP and ASSUME DDS keywords, but this format is never used. This code is generally required when one interactive program calls another program that happens to present a DDS window. When the KEEP and ASSUME keywords are not present in the display file of the called program, the display format of the calling program is inexplicably blanked out, even though the DDS window keywords are present.
The code for the CAL001RG RPG IV program uses a base date of January 1, 1901, as we mentioned earlier. We could have chosen any arbitrary date as our basis for our calendar calculations. We chose a date quite far in the past because it made our coding a little easier. Regardless of the base date used, the Add Duration (ADDDUR) and Subtract Duration (SUBDUR) operation codes, which were added with RPG IV, may then be used to create a very simple calendar program.
There are two parameters for our calendar program. We allowed for a return code (aptly named ReturnCode) and a six-digit date (which we named PassDate). If the operator presses one of the function keys, we simply pass a value back to the calling program, indicating the function that was chosen. If the operator chooses to select a date by keying in the two digits that correlate to a date seen on the on-screen calendar, the selection is translated to a six-digit date (as mmddyy); it is then passed back to the calling program, along with a return code indicating that a valid date selection was chosen.
When the operator presses Page Up or Page Down, we use ADDDUR or SUBDUR to add or subtract a month from the displayed calendar and then redisplay the screen. If the operator keys a date that is not displayed on the screen, an error indicator is turned on and the screen is redisplayed along with the error.
For aesthetic purposes, we also added a compile-time array representing the names of the months. This table is used to simply convert the numerical month to its alphanumeric equivalent so it can be displayed in the heading.
We also used an old RPG trick to highlight the current date on the calendar. By setting the appropriate hexadecimal values, you can control screen display attributes on the fly. For our purposes here, we wanted to be able to show the current date as high intensity. To do so required that we define two fields: one for setting on high intensity and another to return the screen to normal intensity. The calendar subroutine concatenates these fields around the two-digit day if the display date happens to match the current date.
We could have added a little code to implement DDS pull-down menus to help aid in the selection of the month and year, but, because of space constraints, we will have to leave that for yet another article.
This program is coded so generically that it can easily be called from any place where a date is required. As you can see from the code in the Browse subroutine in Figure 2, it is very simple to implement this handy pop-up calendar window.
The Dating Game, RPG IV Style
We have written numerous articles about RPG IV and the date data type. This article includes yet another example of how to combine RPG IV and the date data type to make your system ready for the next century. The AS/400 is ready for the twenty-first century. Are you?
Figure 1: Simple print request program
***** subroutine: “Browse” ***********************************
***** perform browse/prompt function ***************************
C Browse begsr * find and set cursor location so cursor will stay at same position when
* screen is redisplayed
c Bin div 256 CsrRow
c mvr CsrCol
c eval *in77 = *on * if prompt was requested on a “prompt capable” field, get window
c Select
c when csrfld = ‘PRINTER’
c call ‘WIN001RG’
c parm *blanks ReturnCode
c parm csrfld FileName
c parm *blanks PassCode
c if ReturnCode = ‘50’
c movel PassCode Printer
c endif * browse date fields
c when csrfld = ‘FROMDATE’ or
c csrfld = ‘TODATE’
c call ‘CAL001RG’
c parm *blanks ReturnCode
c parm *zeros PassDate 6 0
c if ReturnCode = ‘50’
c if CsrFld = ‘FROMDATE’
c movel PassDate FromDate
c endif
c if CsrFld = ‘TODATE’
c movel PassDate ToDate
c endif
c endif
c endsl
csr endsr
Figure 2: Replacement “Browse” subroutine for the PRT002RG program
LATEST COMMENTS
MC Press Online