Display file DDS supports powerful ways to provide contextual help text to your users…but with limitations. Learn how to get around those limitations.
IBM supports a wide range of help-related keywords in DDS source—too many for me to cover here. If you have a free weekend (or three), you can browse through the latest Programming DDS for Display Files manual starting around page 123. Yes, I know the world is changing and in two (or five or ten) years, there will be no more display files. But then again, I've heard that since the mid-’90s, so forgive me if I'm not quite ready to roll up the 5250 just yet. And as long as we have green-screens, we should have good help text for them.
Contextual Help in the 5250 World
The 5250 interface can be a little constricting, given its 24x80 (or even 27x132) size limit. Programmers tend to create very dense screens, with codes instead of actual words, and even when words are employed, they're often abbreviated. All of this compacting leads to screens that are very powerful for seasoned users but can be daunting for novices. That's what help text is supposed to alleviate. However, the very denseness of the screens leads to a problem: If you provide users with all the possible help for a screen, it will take them too long to read through it, and that defeats the purpose of the help text in the first place.
Over the years, we've settled on the idea of contextual help. Typically, the Help key would provide help that is specific to the field where the cursor is located when the user hits the Help key. Often, a more general help is available as well. This may be invoked when the user hits the Help key but isn't on a specific field. This was the most common technique in the early days of DDS-based help text.
The Simple Method: HLPARA and HLPRCD
In addition to the primary enabling keyword HELP (and it's close relative ALTHELP), only the two keywords HLPARA and HLPRCD are required for traditional help. When you define your display, you are able to specify the help for rectangular sections of the display. You can do this either by specifically using row and column (top-left and bottom-right corners of the rectangle) or by specifying a field name. Rectangles can overlap and also can be conditioned; this provides a lot of flexibility. One use of this feature is to specify a default help for the display. Simply create a help definition that encompasses the entire screen (from position 1,1 to position 24,80) and place this at the end of the list; this help definition will be used any time that the user presses the Help key and the cursor isn't in any of the other definitions.
Each help definition also needs a keyword identifying the help text to display. The two basic concepts are help records (HLPRCD) and panel groups (HLPPNLGRP). Today, we'll assume you're using the HLPRCD keyword, which allows you to specify a record either in the display file or in a completely separate file. The latter is nice because you can change the help even when people are in the program (as long as they're not currently using the help!).
Which Definition Type? Row and Column or Field Name?
If everything else were equal, from a maintenance standpoint I'd prefer to use the field name technique because you don't have to change your help definitions when a field moves on the screen. The system takes care of the details for you and automatically brings up the correct help text.
The row and column technique is required for subfiles. For whatever reason, DDS doesn't support using the field name technique with subfiles. You can only specify the HLPARA in the subfile control record, and you can only specify field names from the record where the HLPARA is defined, so effectively you can only specify field names in the subfile control record. Instead, you're limited to specifying the help text definitions using row and column rectangles. Figure 1 shows an example.
Figure 1: RDi will show you your help rectangles.
In Figure 1, I defined rectangles around the columns in the subfile. Each column has its own rectangle, defined using the HLPARA keyword. Then, I have a default rectangle that covers the entire record. The source looks like this:
A H HLPARA(7 2 21 4)
A HLPRCD(HELP_OPT)
A H HLPARA(7 7 21 10)
A HLPRCD(HELP_ID)
A H HLPARA(7 14 21 43)
A HLPRCD(HELP_DESC)
A H HLPARA(1 1 24 80)
A HLPRCD(HELP_RCD)
Each rectangle has an associated help record which has been defined in the display file using the HLPRCD keyword. As noted earlier, I could also have pointed to an external file to allow separation of the display file and the help file. Overall, this technique works very well when you have subfiles with a single line, with the primary negative being that whenever you change the subfile, you have to change the rectangles in the DDS. However, it gets much harder with a folded subfile.
Figure 2: Folded subfile records don't lend themselves as well to the rectangle approach.
As you can see here, it would be impossible to define columnar rectangles; the column for zone overlaps the column for station, and the column containing city and state overlaps the column for address. The only answer in this case is to specify individual rectangles for every station field in every subfile line—in this case, eight different rectangles for station alone—and then do the same for every other field. And as if that weren't already overly complicated, consider this: What if the subfile can be folded with, say, F11? Now the rectangles are different! You can do it, although it requires a combination of tedious definition in the DDS and unusual programming. It really starts to become a maintenance nightmare.
On the other hand, you might also have noticed that my rectangles in Figure 1 include the headings for the subfile columns. That's a downside to the field name technique: Constants don't have a name, so there's no way to specify the field name. IBM provided a workaround; you can specify a special value called HLPID and that can be used, but remember there's a much larger issue: Fields in subfiles can't be specified by name at all! So unfortunately we're stuck with rectangles.
Or are we? In subsequent articles, I'm going to address two different enhancements to the help system. One has to do with the actual text itself and involves moving from DDS-based help records to far more flexible UIM panel groups. The second involves a one-time piece of programming that allows you to have much better control over your help area definition and allows you to use field names even on subfiles.
So start here, familiarize yourself with the basics of HLPARA and HLPRCD, and stay tuned for more good things in the future!
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online