TechTip: Eliminate Indicators in Display Programs

[DougCMH]

** This thread discusses the article: TechTip: Eliminate Indicators in Display Programs **
So I'm not the only one who uses TRUE and FALSE constants. I actually have a copybook that I put into each and every program I write. It has the SDS, TRUE, FALSE, and some other constants like UCase, LCase, Apost, Numeric, OK, and some fields like SysDate, JobDate, etc. I also have a copybook for my display work, which forces me to standardize my indicators (ie, the 90s are for subfile control, etc), contains constants for working with the AID byte (which can also be used to capture mouse events, by the way), constants for display attributes,etc. The one drawback to an INDDS data structure that I don't like, however, is that you can only put in N fields, or arrays of N fields. I sometimes like to group certain indicators together into one field, so I can do code like SflAction = SflClear or inErrors = *all'0' You can't group indicators like that in an INDDS, but, you can overlay another DS over the INDDS. I have a pointer initialized to the address of the INDDS, and I use it to overlay other DSs, defined however I like, over the INDDS. I have a standard one in my copybook, and I usually define one separately in each program, where I can set up named indicators specific to the program. I don't have a point here, other than to say I agree and to ramble.

[Chipper2]

** This thread discusses the article: TechTip: Eliminate Indicators in Display Programs **
Another option to get rid of indicators in programs is to use program to system fields (P-fields). This also requires creating hex values (similar to defining the F-Keys). I tried to find my handout from Charlie Massoglia, but couldn't. Let me try to see if I have a copy at home.

[Guest.Visitor]

** This thread discusses the article: TechTip: Eliminate Indicators in Display Programs **
Eliminating Indicators in Display Programs is a good idea, but I also try to avoid them in the DDS whenever possible. That means instead of specifying indicators to set display attributes, I use a single character program field that is specified with the display attribute in DDS and fill this field in my RPG code with the appropriate hex values of the display attributes.

 A A1STS 1A P A R1STS R B 20 33REFFLD(STS LLREFDP) A TEXT('Status') A DSPATR(&A1STS) 

To archieve this I wrote two functions. For the first one I can pass the display attributes as I'd specify them in DDS, for example 'YLW': 'UL' and return the appropriate hex value. The valid hex values are x'20' to x'3F' for unprotected display attributes and x'A0' to x'BF' for protected display attributes. Instead of handling different situations with switching different indicators Off and On I simply determine the hex value in my program: Example:

 /Free Select When Action = Display and R1Sts = Active; A1Sts = SetDspAttr('WHT': 'PR'); When Action = Display and R1Sts = Inactive; A1Sts = SetDspAttr('RED': 'PR'); When Action <> Display and R1Sts = Active and R1Date <= %Date(); A1Sts = SetDspAttr('YLW': 'UL'); When Action <> Display and R1Sts = Active and R1Date > %Date(); A1Sts = SetDspAttr('TRQ': 'UL'); When Action <> Display and R1Sts = Inactive; A1Sts = SetDspAttr('RED': 'PR'); EndSl; /End-Free 

The other function I've written returns the reverse image for a given display attribute in hex. In this way I easily can change the display attribute without taking care about the conditions I set before. Example:

 /Free Monitor; ChkFkt(R1Sts); On-Error; A1Sts = SetDspAttrRI(A1Sts); SetCsrPos(R1Row: R1Col: 'DSPF': 'FORMAT': 'FIELD'); EndMon; /End-Free 

A little more trickier is to position the cursor to a specified field without hardcoding column and row, because the API QDFRTVRD (Retrieve Display File Description) must be used. But a prodecure, written once and tested, will work forever. The only thing for what I have to use indicators, is for subfiles. There is no workaround to avoid indicators in DDS. Birgitta

[DougCMH]

** This thread discusses the article: TechTip: Eliminate Indicators in Display Programs **
I pulled this from the RPG Reference on the V5R4 InfoCenter: Indicator Data Structure An indicator data structure is identified by the keyword INDDS on the file description specifications. It is used to store conditioning and response indicators passed to and from data management for a file. By default, the indicator data structure is initialized to all zeros ('0's). The rules for defining the data structure are:

[*]It must not be externally described.[*]It can only have fields of indicator format.[*]It can be defined as a multiple occurrence data structure.[*]%SIZE for the data structure will return 99. For a multiple occurrence data structure, %SIZE(ds:*ALL) will return a multiple of 99. If a length is specified, it must be 99.[*]Subfields may contain arrays of indicators as long as the total length does not exceed 99.[/list] If your code compiles and works, then either I'm not understanding that part in italics above, or, the documentation is lying again. If the latter, maybe I can use a left-side %subdt.

[Steve.Kiferd]

** This thread discusses the article: TechTip: Eliminate Indicators in Display Programs **
I use the indicator ds to eliminate them in rpg programs. However using program to display fields to eliminate the indicators in dds seems like overkill to me and would make maintenance of these processes more difficult for the next person. Sometimes the KISS principle does make sense. just my .02

[Guest.Visitor]

** This thread discusses the article: TechTip: Eliminate Indicators in Display Programs **
Hi, it was already difficult to handle the following display file. But then I had to add an additional indicator, to handle an other exception.

 A R1TNR R B 8 33REFFLD(TNR LLREFDP) A TEXT('Artikel-Nr.') A 12 DSPATR(RI) A N80 60N82 DSPATR(UL) A 80 AON60 AO 82 DSPATR(PR) A 12 DSPATR(PC) A N80 60N82 COLOR(YLW) A 80 AON60 AO 82 COLOR(WHT) A 83 R1LAB R B 19 33REFFLD(LAB LLREFDP) A TEXT('Lagerort') A 20 DSPATR(RI) A N80 60 DSPATR(UL) A 20 DSPATR(PC) A 80 AON83 AON60 DSPATR(PR) A N80 60 83 COLOR(TRQ) A N80 60N83 COLOR(YLW) A 80 AON60 COLOR(WHT) A 83 R1LBE R O 19 38REFFLD(LBE LLREFDP) A TEXT('Bezeichnung Lagerort') A COLOR(WHT) 

The following snippet not only looks much easier, but its much easier to handle the different situations in the RPG program (where setting paranthesis is allowed).

 A A1TNR 1A P TEXT('Display-Attribute für – A Artikel-Nr.') A A1LAB 1A P TEXT('Display-Attribute für Lager') A R1TX11 30 O 6 2TEXT('Artikel-Nr.') A MSGID(FTX 0503 LLMSGF) A R1TNR R B 6 33REFFLD(TNR LLREFDP) A TEXT('Artikel-Nr.') A DSPATR(&A1TNR) A R1TX13 30 O 19 2TEXT('Lagerort') A MSGID(FTX 4668 LLMSGF) A R1LAB R B 19 33REFFLD(LAB LLREFDP) A TEXT('Lagerort') A DSPATR(&A1LAB) 

Birgitta

[J.Pluta]

** This thread discusses the article: TechTip: Eliminate Indicators in Display Programs **
Isn't that always the case, Barbara? Joe

[tstephens55]

** This thread discusses the article: TechTip: Eliminate Indicators in Display Programs **
I also will set up variables valid/notvalid, etc. It makes the code much more readable as I would rather see "If pTestAddr = Valid" then "If pTestAddr = *on". (pTestAddr refering to a procedure that returns an indicator variable).

[J.Pluta]

** This thread discusses the article: TechTip: Eliminate Indicators in Display Programs **
Which is why I prefer to use completely meaningful names like TestAddressIsValid. Then I can just say "If TestAddressIsValid". By using the name of the Boolean to completely describe the *ON condition, you can avoid having to do any comparison at all. Joe

[J.Pluta]

** This thread discusses the article: TechTip: Eliminate Indicators in Display Programs **
And actually that's the standard for the OO world. If you have a boolean, the getter for the boolean is normally isVariableName. Thus you name your booleans to indicate the condition name. For example, I might have a boolean named numeric for a field, and then I can write "if field.isNumeric()". That's pretty self-documenting. And you could do that with a qualified data structrue just as easily if you name the fields with the "is" prefix. If you have a data structure named Customer with an indicator named isOnCreditHold, you could write "if Customer.isOnCreditHold;". Joe