Unconfigured Ad Widget

Collapse

Announcement

Collapse
No announcement yet.

TechTip: Eliminate Indicators in Display Programs

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • TechTip: Eliminate Indicators in Display Programs

    ** This thread discusses the article: TechTip: Eliminate Indicators in Display Programs **
    ** This thread discusses the Content article: TechTip: Eliminate Indicators in Display Programs **
    0

  • #2
    TechTip: Eliminate Indicators in Display Programs

    ** This thread discusses the article: TechTip: Eliminate Indicators in Display Programs **
    I personally don't care for the True/False thing, since you're just renaming *On and *Off, which IBM has already provided for us. Since there's no need for them in comparisons anyway (why say 'if Record_Found = True' when 'if Record_Found' or its inverse 'if not Record_Found' are just as clear), the only time to use True/False or *On/*Off is when setting values. Are *On and *Off that hard to understand? Just my preference, of course.

    Comment


    • #3
      TechTip: Eliminate Indicators in Display Programs

      ** 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.

      Comment


      • #4
        TechTip: Eliminate Indicators in Display Programs

        ** This thread discusses the article: TechTip: Eliminate Indicators in Display Programs **
        The whole TRUE/FALSE thing is my preference. There are two reasons for this. First, the code is easier to read. This is particularly in the case of errors on displays (an in the example from the article). Sometimes if the variables you are using are named particularly well then using *ON and *OFF can read well too. But usually that's not the case. Secondly, TRUE and FALSE are commonly used in other languages (C++, PHP and Java for example). But as with most things about language syntax...ultimately its a matter of preference. Thanks for the feedback. Jeff
        Code

        Comment


        • #5
          TechTip: Eliminate Indicators in Display Programs

          ** This thread discusses the article: TechTip: Eliminate Indicators in Display Programs **
          I am ok with the rambling...especially since I do it too. Although it's always easier to endure it when the person doing the rambling is busy agreeing with me. ;-) The overlaying of the INDDS is a good idea. Saves time and trouble re-initializing stuff. Thanks, Jeff

          Comment


          • #6
            TechTip: Eliminate Indicators in Display Programs

            ** 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.

            Comment


            • #7
              TechTip: Eliminate Indicators in Display Programs

              ** 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

              Comment


              • #8
                TechTip: Eliminate Indicators in Display Programs

                ** This thread discusses the article: TechTip: Eliminate Indicators in Display Programs **
                Chipper, You and Birgitta are both correct about the P-fields. They can be used in place of indicators in DDS. The one draw back is that there is not a way to use the P-fields to position the cursor. So you are stuck with using indicators for that. Also, as Birgitta points out, you cannot use the P-fields to condition subfile keywords. P-fields have an additional draw back of requiring a fair amount of changes to both the RPG source and the DDS source when modifying an existing program. With that said, the P-fields are a excellent tool to reduce use of indicators in new development. Thanks for your comments. :-) Jeff

                Comment


                • #9
                  TechTip: Eliminate Indicators in Display Programs

                  ** This thread discusses the article: TechTip: Eliminate Indicators in Display Programs **
                  Birgitta, What I have found is that removing indicators from existing DDS source is most often more trouble than it is worth. Also, as you point out, using P-fields cannot eliminate indicators completely. As I said in my response to Chipper2, P-fields are a great solution for new development. Not so much for updating existing stuff. Thanks for the great description and code example. :-) Jeff

                  Comment


                  • #10
                    TechTip: Eliminate Indicators in Display Programs

                    ** This thread discusses the article: TechTip: Eliminate Indicators in Display Programs **
                    DougCMH wrote: > > 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, ... You _can_ group indicators in the INDDS. You can define A-type subfields, and you can define subfields with no type or length that are defined by the other subfields that are overlaid on them. D indds ds D errInds overlay(indds:31) D nameErr n overlay(errInds:1) D amtErr n overlay(errInds:2) D dateErr n overlay(errInds:3) D showInds 10a overlay(indds:51) D showErrmsg n overlay(showInds:1) D showTotal n overlay(showInds:2) But I'm not sure that using overlay this way is very good; it's not particularly easy to see that amtErr matches indicator 32 in the DDS. Here is another way to define it that may be more clear. It doesn't explicitly overlay the grouped subfields over the group subfield, but the indentation shows the grouping. D indds ds D errInds 3 overlay(indds:31) D nameErr n overlay(indds:31) D amtErr n overlay(indds:32) D dateErr n overlay(indds:33) D showInds 10 overlay(indds:51) D showErrmsg n overlay(indds:51) D showTotal n overlay(indds:52)

                    Comment


                    • #11
                      TechTip: Eliminate Indicators in Display Programs

                      ** This thread discusses the article: TechTip: Eliminate Indicators in Display Programs **
                      Barbara, I think the second snippet of code is the clearer way of coding it (see code below). When it is coded that way it is much easier to decipher which variable corresponds to which indicator. thanks, Jeff
                      Code

                      Comment


                      • #12
                        TechTip: Eliminate Indicators in Display Programs

                        ** This thread discusses the article: TechTip: Eliminate Indicators in Display Programs **
                        Oops, sorry about my previous message. I posted it from a newsreader, forgetting that it would get garbled on the website. Jeff, in my original example, I had the xxxErr subfields indented one more level inside errInds. I think it's important to show visually that the xxxErr subfields are contained within errInds. Your comment lines do a good job of showing the related fields, but I think indentation is also useful.
                        Code

                        Comment


                        • #13
                          TechTip: Eliminate Indicators in Display Programs

                          ** This thread discusses the article: TechTip: Eliminate Indicators in Display Programs **
                          Barbara, You are right. The indentation does make it more obvious what is being done. Nice work. :-) Thanks, Jeff

                          Comment


                          • #14
                            TechTip: Eliminate Indicators in Display Programs

                            ** 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.

                            Comment


                            • #15
                              TechTip: Eliminate Indicators in Display Programs

                              ** 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

                              Comment

                              Working...
                              X