I have seen numerous ways of handling indicators from display files and print files over the years. At this time, there are no reasons for using the “numeric” indicators in your program that I am aware of. I decided to take a minute and share the process I have gone through over the years for dealing with indicators.
I started like everyone else, using the good old numeric indicators like the following sample:
fMyDspf cf e Workstn
/Free
Dow Not *In03 ;
ExFmt Screen ;
//Do some processing
EndDo;
*InLr = *On ;
Return ;
/End-Free
*In03 was assigned to the F3 key to exit a program and this worked fine. Unfortunately, when you have multiple function keys, the next programmer has no idea what each numeric indicator means what without looking at the display file and figuring it out.
So I moved on to my next idea. So I overlayed a data structure on the numeric indicators:
fMyDspf cf e Workstn
dIndPointer s * Inz(%Addr(*IN))
dIndicators ds Based(IndPointer)
d Exit n Overlay(Indicators:03)
d Prompt n Overlay(Indicators:04)
d Cancel n Overlay(Indicators:12)
/Free
Dow Not Exit ;
ExFmt Screen ;
//Do some processing
EndDo;
*InLr = *On ;
Return ;
/End-Free
What happens here is, I define a pointer named IndPointer that points to the area of memory that contains the programs numeric indicators. I then created a data structure based on that pointer so that I could give the numeric pointers meaningful names.
This worked fine for a while. And then one day I was writing a program that a couple of screens from an existing DSPF file and printed a report using an existing PRTF. And to my dismay, the display file and the print file used the same numeric indicator for completely different purposes. I could not change the screens or the print file records easily because they were used by other objects as well. It would have meant modifying about 20 more programs to correct the issue.
So I found a better way:
fMyDspf cf e Workstn IndDs(Indicators)
dIndicators ds
d Exit n Overlay(Indicators:03)
d Prompt n Overlay(Indicators:04)
d Cancel n Overlay(Indicators:12)
/Free
Dow Not Exit ;
ExFmt Screen ;
//Do some processing
EndDo;
*InLr = *On ;
Return ;
/End-Free
This may not seem like a huge change, but the devil is in the details so to speak. You will notice I removed the pointer and added a file spec keyword “IndDs”. This keyword associates a datastructure for the indicators used in a DSPF or PRTF. That sounds like it does the same thing as the pointer right? Not exactly. Using the INDDS keyword takes the indicators for the display file and puts them directlly into the data structure named, bypassing the RPG numeric indicators all together. This means that you can have a different data structure for each display or print file in your program, and it does not matter what indicator numbers are used in them. Since they don’t use the RPG numeric indicators, they cannot interfere with each other.
So you could have something like:
fMyDspf cf e Workstn IndDs(Screen_Ind)
fMyPrtf o e Printer IndDs(Print_Ind)
f InfDs(Print_Inf)
f OflInd(Overflow)
dScreen_Ind ds
d Exit n Overlay(Indicators:03)
d Prompt n Overlay(Indicators:04)
d Cancel n Overlay(Indicators:12)
dPrint_Ind ds
d Bold n Overlay(Print_Inds:03)
d Underline n Overlay(Print_Inds:04)
d Summary n Overlay(Print_Inds:12)
dPrint_Infs ds
d Overflow_Line 188 189i 0
d Current_Line 367 368i 0
dOverflow s n Inz(*Off)
/Free
Dow Not Exit ;
ExFmt Screen ;
//Print Report
EndDo;
*InLr = *On ;
Return ;
/End-Free
Even though both the print file and display file are using indicators 3, 4, and 12 internally, the program keeps up with them separately. And the meaningful names help the code to self document.
I hope this helps some of you. Maybe you guys have better suggestions for this. Please let me know if tips like these are beneficial so I can taylor the content that I add to the blog.
