Overloading Indicators:

Use this technique to reduce the number of required screen indicators.
Attribute fields are one way to eliminate indicators, but are there any other ways? There are screen functions that require indicator usage, but can we at least reduce their usage? We can by doing what I like to think of as overloading indicator functionality.

Now, follow this scenario: You are coding a subfile. To do so, you need a SFLDSPCTL keyword, with an indicator, of course, to display the subfile control record. You also need SFLCLR (or SFLINZ) to clear the subfile. So you put indicator 92 on SFLDSPCTL and indicator 93 on SFLCLR.

In the program, in order to clear the subfile, you need to set 92 off and 93 on. You write the control record to clear. After loading the subfile, you need to display the control record. You set 92 on and 93 off. That's two indicators to keep track of.

Two of a control record's functions are displaying itself and clearing the subfile. These are mutually exclusive functions. So why use two indicators? This is a case where one indicator can serve both functions: It can be overloaded. Indicator 92 can be used to display the subfile, and N92 can be used to clear it.

So now, in order to clear the subfile, you set 92 off. To display the control record, you set 92 on. That's only one indicator to keep track of.

So, you can overload an indicator on mutually exclusive functions; the indicator is on for one function and off for the other.

Another use for overloading indicators is on related functions. For example, consider the SFLDSP keyword on your expanding subfile. This keyword displays the subfile, of course. You turn it on only if there are records in the subfile to display. If there are no records to display, why bother turning on PAGEDOWN? You can use the same indicator, with the same setting, to condition SFLDSP and PAGEDOWN.

Not only that, PAGEDOWN is mutually exclusive to SFLEND (why allow PAGEDOWN when the last page of the subfile is displayed?), so you can also condition PAGEDOWN with the opposite setting of SFLEND.

Here is a standard, basic coding for expanding subfiles:
A 91 SFLDSP
A N91 ERASE(SCRN1F)
A 92 SFLDSPCTL
A N92 SFLCLR
A 93 SFLEND(*MORE)
A N93 91 PAGEDOWN

Only three indicators are in use. Indicator 91 is used this way: If there are records in the subfile to display, then PAGEDOWN is active; otherwise, the area of the screen occupied by the subfile is cleared, and PAGEDOWN is inactive. Indicator 92: Either display the control record or clear the subfile. Indicator 93: If the last page of the subfile is displayed, show "Bottom" and deactivate PAGEDOWN; otherwise, show "More..." and turn on PAGEDOWN.

There are other times to overload indicators too. For example, if you are restricting certain functions of a program to certain users, you can use one indicator to protect screen fields, deactivate function keys, and hide the text for those function keys for unauthorized users. Those are related security functions. Likewise, you can use the opposite setting of that indicator to open the fields, activate the function keys, and display the text for authorized users.

In our quest to rid ourselves of indicators, we can use overloading to reduce the number of required screen indicators. We do this by using the same indicator for related functions and using opposite settings of one indicator for mutually exclusive functions. The fewer indicators we have, the better off the program can be.