Named Indicators vs. Numbered Indicators

[DaveLClarkI]

Silly me, but I just got done converting 4 Profound UI screens from using numbered indicators to using named indicators. Then I went to test and found that nothing was working. Apparently, using Profound UI named indicators means that you cannot test them as follows:

Code: Select all

         if (Grid.Selected = *on);     // process only "selected" rows

Unless I'm doing something wrong, you'll probably tell me that I have to test them as follows:

Code: Select all

         if (Grid.Selected = '1');     // process only "selected" rows

If so, I'm not a happy camper because that is not as self-documenting as what you get with numbered indicators in RPG. So, what's the deal? Thanks.

[DaveLClarkI]

Well, guess I'll just have to create myself a self-documenting variable against which to test:

Code: Select all

         if (Grid.Selected = iON);     // process only "selected" rows

Thanks.

[Scott Klement]

I always use *ON and *OFF with named indicators, works fine here.

The caveat to 'named indicators' is that they're really 1A fields (since DDS doesn't support actual named indicators), so RPG will initialize them to *BLANKS by default, unlike 'real' indicators.

[DaveLClarkI]

I always use *ON and *OFF with named indicators, works fine here.

Well, to prove there was a problem, I also ran it through debug and (even though the PUI named indicator had a '1' value in it) the IF statement comparing the PUI named indicator to *ON evaluated as FALSE and the ELSE code was executed. After I created a constant with a '1' value and used that in the comparison, then the TRUE part of the IF-ELSE-ENDIF construct executed as desired.

Note that in an assignment statement, setting a variable with a 1A data definition equal to *ON or *OFF is not a problem. RPG will convert that as desired.

(since DDS doesn't support actual named indicators)

Yes, I'm now painfully aware of that.

[Scott Klement]

Please post this test code.

I've written hundreds, maybe even a thousand, programs that use *ON and *OFF, without problems. I did this before I worked at Profound.. back before RPG added the 'N' data type, I used 1A fields for my regular RPG programs all over the place, and all used *ON and *OFF. And it works.

Please post the test code so I can see the circumstance where it does not.

[DaveLClarkI]

Don't know about prior releases... We are at v7r1m0 with TR7 and all the latest PTFs installed.

Code: Select all

       dow ReadingChangedRows();       // read all changed rows
         Grid.Changed = *off;          // clear row changed indicator

         if (Grid.Selected = *on);     // process only "selected" rows
           Grid.Selected = *off;       // clear row selected indicator

           if Screen.mnuOption <= *blanks; // if no option selection entered
             Screen.sflpos = 1;        // reset subfile position to top
           else;                       // else
             Screen.sflpos = sflrrn;   // set subfile position to this record
             select;
               when (Screen.mnuOption = 'Add'); // add to subfile
                 add_to_subfile = *on; // turn on flag for delayed processing

               when (Screen.mnuOption = 'Change'); // change or insert this row
                 callp UpdateThisValue();

               when (Screen.mnuOption = 'Delete'); // delete this row
                 callp DeleteThisValue();

               when (Screen.mnuOption = 'Features'); // manage features for this row
                 pKeyData.Application = Grid.APPNME; // pass selected key data
                 pPgmName = TrgMgt_NextTabProgram(proc_pgm); // go to next screen
                 leave;                // exit from subfile processing

               when (Screen.mnuOption = 'Refresh'); // rebuild the screen
                 rebuild_screen = *on;

               other;
                 errors_found = *on;   // set program error indicator on
                 Grid.Changed = *on;   // flag grid row as changed
                 Grid.Selected = *on;  // flag grid row as selected
                 GenUtl_GetMessageText( 'ACL0004'
                          : %subst(%char(sflrrn) + '     ':1:5)
                            + Screen.mnuOption
                          : var_msg );
                 Screen.ERROR_MSG = var_msg;
                 Screen.ERROR_IND = *on;
             endsl;
           endif;

         else;                         // row not selected
           Grid.Protected = *on;       // set all fields back to protected mode
           Grid.APPNME_PC = *off;      // make sure field attr indicators are off
           Grid.APPCDE_PC = *off;
           Grid.APPENA_PC = *off;
           Grid.ALLUSE_PC = *off;
           Grid.APPDSC_PC = *off;
         endif;

         eval-corr Grid_Out = Grid;    // move corresponding input data to output
         update ACTMAPLD.ACTMAPLS Grid_Out; // update subfile record

       enddo;                          // loop on subfile records

[Scott Klement]

Dave,

I'm not interested in a snippet of code from your application. Your application is complex, and is doing many things unrelated to what we are discussing here. I cannot easily load and run your application, and if I tried it would be difficult and time consuming.

Please post a simple test case that illustrates your point. That means a simple program ("stripped down" program, maybe) that does nothing except prove your point. It should be a complete program that anyone can load and see what you're talking about.

Here's an example of what I mean:

Code: Select all

     D NamedInd        s              1a
                                        
      /free                             
         NamedInd = '1';                
                                        
         if NamedInd = *ON;             
            dsply 'on';                 
         else;                          
            dsply 'off';                
         endif;                         
                                        
         *inlr = *on;                   

See what I mean? anyone reading this can copy/paste this code into RDi, save it, compile it, and run it. It's a complete program that does nothing else but test the situation that is being discussed.. When they run it and it displays 'on' then you'll know that testing for *ON works fine.

Your code would be extremely for anyone (outside of your shop) to load and run. Since you only posted a piece of the program, we'd have to guess at the rest of the program, and may not even do the same thing you're doing. Since your code is doing ohter things like accessing a file, we'd need to have the same files... it's just too complex for a simple test case.

Since your premise is that a 1A field, such as the named indicators that Profound generates, can't be tested with *ON and *OFF, write a program that demonstrates EXACTLY that.

[DaveLClarkI]

Boy, you're just as mean (inconsiderate, really) as you were back on the System iNetwork forums. Since you weren't addressing "customers" back then, it was something that simply had to just be forgiven. But, now that you represent a software vendor it would behoove you to consider your words before posting them.

You asked me to post my code that wasn't working as a result of using the PUI named indicators and that's what I did. Then you snip back that you're not interested in my complex code. A little lesson for you... Instead of saying: "I'm not interested in a snippet of code from your application" it would have been a lot nicer to say:

"I'm sorry that I gave you the wrong impression. Instead of your actual code, I'd like to see a very stripped down version which I can easily compare on my system by running exactly the code you demonstrate. In other words, code which does not require additional procedures, files, or objects. Thanks."

[Scott Klement]

You said you had a test case that proves your point, that was what I was looking for you to post.

My apologies.

[DaveLClarkI]

The code you posted works as expected on my system. The code I posted does not work as expected when reading the value of the named indicator via the PUI-generated DDS file. Don't ask me to explain that -- it is what it is.