We have been coding pop-up windows since the /34. (For you rookies out there, the /34 was one of the predecessors to the /36, /38, and AS/400.) We found that pop-up windows made our software products more attractive to prospective buyers. But working with these “pseudo windows” was very difficult because they required so much code to make them work.

Thankfully, things have changed. DDS keywords were designed specifically to help us code pop-up windows. IBM then gave us the ability to code subfiles in pop-up windows. And now IBM has given us special DDS keywords to tell our programs which pop-up window should be presented—a capability that led us to write this article. We found the new keywords that may be used to both acquire and set cursor positions particularly useful when coding pop-up windows, and we thought it might be helpful to some of our readers if we passed this information on.

But why are these new keywords so important? In the first place, the value of popup windows is significantly enhanced when the pop-up window presented bears a direct relationship to the field where the cursor is located when the window is requested. It is also helpful to be able to return the cursor to its original position once the pop-up window processing has been completed. Perhaps an example would be useful to explain these two points.

Batter on Deck

Let’s take a look at the screen presented in Figure 1. What we see here is a simple report prompt screen. It prompts the user to key “from” and “to” dates, the name of the printer ID to receive the printed output, and the desired number of copies to print. The code behind the screen seen in Figure 1 is nothing fancy. The display file DDS may be found in Figure 2, and the code to the RPG IV program may be seen in Figure 3.

Note that in Figure 1 we added an F4 function key, which may be used to “prompt” or “browse” available values for entries on the screen. For the purposes of this

article, we elected to make the printer file “prompt” or “browse” capable. The results of a prompt request on the printer ID field may be seen in Figure 4.

Batter Up!

Let’s begin by taking a look at the DDS in Figure 2. For the most part, the DDS is probably pretty familiar to you. The record format named PROMPT represents the screen you see in Figure 1.

The screen format presented in Figure 1 could realistically have been coded to have three prompt-capable fields: the “from” date, the “to” date, and the printer ID. (In a future issue of MC, we’ll show you a pop-up calendar program useful for making the two-date fields prompt capable. But for our example here, we elected to make the printer ID field the only prompt-capable field.)

If we had elected to make both dates and the printer ID prompt-capable fields, how would we know which pop-up window to present? We could add a function key for each prompt-capable field on the screen, but what would we do if the screen had more of the fields than we had function keys? It would be much easier on users if the program simply presented the correct pop-up window when they pressed the “F4=Prompt” key. How would the program know which pop-up window to present? The location of the cursor is a good place to start.

The problem with using the cursor location is that programs change. If you code your program to look for a specific cursor location on a screen, what happens when your display file field locations are changed? If you forget to change the code in your program, your pop-up window will likely cease to function correctly. It would be better to know what field the cursor was on when the F4 prompt operation is requested. And that is exactly what the new DDS keywords provide.

Stealing the Sign

If you carefully examine the DDS in Figure 2, you will find a return cursor location (RTNCSRLOC) record-level keyword, which may be used to return the name of the field where the cursor currently resides. The cursor record (CSRRCD) and cursor field (CSRFLD) specified in the RTNCSRLOC record are defined further on as hidden fields.

Hidden fields do not visibly reside on the screen format and are designated using the “H” data type.

The RTNCSRLOC keyword tells your program where the screen cursor is located. It passes the display file record and field names to your program, based on the actual cursor location. For our purposes, we chose to use this information when the F4 prompt function key is pressed. If you examine the browse subroutine in the program in Figure 3, you will see that the value in the field named CSRFLD (cursor field) is used to determine if the pop-up window program should be called. If the cursor happens to be on the field named PRINTER, the pop-up window is displayed as seen in Figure 4.

Another item to look for in the DDS (in Figure 2) is the cursor location (CSRLOC) record-level keyword. It is used in conjunction with the CSRROW (cursor row) and CSRCOL (cursor column) hidden fields, also defined in the DDS. The CSRLOC keyword is used to set the cursor location where you want it.

The CSRLOC keyword can be used to eliminate the need for maintaining indicators to set cursor position, making program maintenance easier. In the case of our prompt function, we store the cursor location when the F4 prompt key is pressed, present the popup window for the PRINTER field (as seen in Figure 4), and then set the cursor back to its original position on the screen. How did we set the cursor back to its original position? When we returned control to our calling program (Figure 1), we set indicator 77 on. This caused the cursor to be set to the screen position defined in the CSRROW and CSRCOL

hidden fields when the next WRITE or EXFMT operation was encountered. You will notice that we turned off indicator 77 when the next screen operation was performed so the cursor would return to normal operation once the screen was written.

Look for Your Pitch

Let’s examine the code in the RPG prompt program seen in Figure 3. This program is going to pass the selected report parameters to the submitted report program via the Local Data Area (LDA), so the first thing the program does is clear the LDA. The program then goes into a loop, which presents the report prompt screen. The loop does not terminate unless the operator presses F3 to exit or a valid report request has been completed.

Once the LDA is cleared and the screen is presented, the program edits the data entered for validity. If the tests are not passed, the appropriate error indicators are set, and the screen is presented again along with the error message displayed. Once the data is entered and the edits are passed, the program uses the QCMDEXC API to submit our report program (REPORT) to the job queue. You will note that the LDA is written out just prior to submitting the job, so a copy of the LDA may be used by the submitted job (a submitted job always begins with a carbon copy of the LDA from the program that submitted it).

On the other hand, if the operator presses F4 to prompt, the browse subroutine is executed. If the cursor is located on the field named PRINTER, the WIN001RG program is called, and the pop-up window seen in Figure 4 is presented.

Getting Brushed Off the Plate

The WIN001DF (display file) and WIN001RG (RPG IV) programs present the pop-up window seen in Figure 4. (Because of space constraints, these programs aren’t published here. You can find them on MC’s Web site at http://www.midrangecomputing. com/code). Each program is written in a generic fashion, making it easy to use the same program as a pop-up window over a wide variety of master files. Note that the file open is user controlled (see the USROPN keyword in the File Description Specification) so you only open the file that you want to appear in the pop-up window. The FileCode parameter (parameter 2) in the WIN001RG program is then used to indicate which file should be loaded into the subfile. For our example, the PRINTERS file (described in Figure 5) is the only file used.

The WIN001RG program presents the window subfile that you see in Figure 4. The operator may key a “Position to” value to reposition the file, make a record selection (by keying a 1 in front of the desired record), press F12 to return to the previous display, or press F3 to exit both programs.

Oh, Doctor! It’s Outta Here!

Programs that enhance usability can often have a dramatic effect on user acceptance. Pop-up windows are but one small example of how you can make the jobs of the people using your software easier. If the people running the software you write (and maintain) feel that you are trying to help them out, they are far more likely to be understanding and work with you when problems inevitably occur. So, go ahead, see if you can turn your pop-ups into home runs!

<>
<>
<>

Figure 1: Simple print request program

*===============================================================

* To compile:

*

* CRTDSPF FILE(XXX/PRT002DF) SRCFILE(XXX/QDDSSRC) +

* RSTDSP(*YES)

*

*===============================================================

A DSPSIZ(24 80 *DS3) CHGINPDFT

A R PROMPT

A CA03 CF04

A RTNCSRLOC(*RECNAME &CSRRCD &CSRFLD)

A 40 ALARM

A 77 CSRLOC(CSRROW CSRCOL)

A CSRROW 3S 0H

A CSRCOL 3S 0H

A CSRRCD 10A H

A CSRFLD 10A H

A 1 28’Submit Reports’ DSPATR(HI)

A 4 2’Type options, press Enter.’

A COLOR(BLU)

A 6 29’List Options’ DSPATR(HI)

A 6 56’From’ DSPATR(HI)

A 6 66’To’ DSPATR(HI)

A 7 4’Date range to include on report...-

A ................’

A FROMDATE 6Y 0B 7 55DSPATR(HI) CHECK(RZ)

A 41 DSPATR(PC)

A 41 ERRMSG(‘“From” date is invalid - ke-

A y as mmddyy’)

A 43 ERRMSG(‘“From” date must be less th-

A an “to” date’)

A TODATE 6Y 0B 7 64DSPATR(HI) CHECK(RZ)

A 42 DSPATR(PC)

A 42 ERRMSG(‘“To” Date is invalid - keyA as mmddyy’)

A 7 71’(MMDDYY)’

A 10 26’Spool File Options’ DSPATR(HI)

A 11 4’Printer to receive output.........-

A ................’

A PRINTER 10 B 11 55DSPATR(HI UL)

A 44 DSPATR(PC)

A 44 ERRMSG(‘You must specify a valid pr-

A inter ID’)

A 12 4’Number of copies..................-

A ................’

A COPIES 2D 0B 12 55CHECK(RZ) DSPATR(HI)

A 45 DSPATR(PC)

A 45 ERRMSG(‘You must specify the number-

A of copies’)

A 12 71’(1-99)’

A 23 6’F3=Exit’ COLOR(BLU)

A 23 16’F4=Prompt’ COLOR(BLU)

Figure 2: The PRT002DF display file

*===============================================================

* To compile:

*

* CRTBNDRPG PGM(XXX/PRT002RG) SRCFILE(XXX/QRPGLESRC)

*

*===============================================================

fPrt002Df cf e workstn infds(Wsinfo)

d Command s 512

d FileName s 10

d ISOFrom s d

d ISOTo s d

D Length s 15 5

d PassCode s 10

d ReturnCode s 2

d Wsinfo ds

d WsID 197 206

d Bin 370 371b 0

*

d Lda uds

d Printer 1 10

d Copies 11 12 0

d FromDate 13 18 0

d ToDate 19 24 0

c *dtaara define *lda Lda

c in Lda

c clear lda

c eval Copies = 1

c dou * InKc

c exfmt prompt

* clear error indicators

c movea ‘000000’ *in(40)

c eval *in77 = *off

* eoj requested

c if *InKc

c leave

c endif

* prompt requested

c if *InKd

c exsr browse

* get out if eoj was requested in window program

c if Returncode = ‘03’

c leave

c endif

c iter

c endif

* edit format entries

c *mdy test(d) FromDate 41

c *mdy test(d) ToDate 42

* “ from” date must be less than “to” date

c if *in41 = *off and *in42 = *off

c *mdy move FromDate ISOFrom

c *mdy move ToDate ISOTo

c if ISOFrom > ISOTo

c eval *In43 = *On

c endif

c endif

* must specify a printer and the number of copies

c printer comp *blanks 44

c copies comp *zeros 45

* if any errors are found, set the alarm and re-submit display

c if *in41 or *in42 or *in43 or *in44 or

c *in45

c eval *in40 = *on

c iter

c endif

* free of errors, so submit report

* Write LDA

c out Lda

* Submit report to the job queue

c eval command = ‘ sbmjob cmd(+

c CALL PGM(REPORT))’

c call ‘QCMDEXC’

c parm command

c parm 28 length

c leave

c enddo

c eval * inlr = *on

**** * subroutine: “Browse” ***********************************

*********** Browse printer file *********************************

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

c endsl

csr endsr

Figure 3: The PRT002RG program

<>
<>
<>

Figure 4: Pop-up window

*===============================================================

* To compile:

*

* CRTPF FILE(XXX/PRINTERS) SRCFILE(XXX/QDDSSRC)

*

*===============================================================

A R PRTREC TEXT(‘PRINTER DESCRIPTIONS’)

A PRINTERID 10A TEXT(‘PRINTER I.D.’)

A COLHDG(‘PRINTER’ ‘I.D.’)

A PRINTRDESC 35A TEXT(‘PRINTER DESCRIPTION’)

A COLHDG(‘PRINTER’ ‘DESCRIPTION’)

A K PRINTRDESC

Figure 5: The PRINTERS file