Unconfigured Ad Widget



No announcement yet.

Why get rid of the compile-time array entirely?

  • Filter
  • Time
  • Show
Clear All
new posts

  • Why get rid of the compile-time array entirely?

    ** This thread discusses the Content article: The API Corner: Still Using Compile-Time Arrays? **

    To minimize changes, you could still keep the Txt array, but replace the text in there with the message identifier, and then the code would be:

    when OrdSts = 'P';
    RtvMsgTxt(Status :%size(Status) :Txt(1));
    when OrdSts = 'O';
    RtvMsgTxt(Status :%size(Status) :Txt(2));
    when OrdSts = 'C';
    RtvMsgTxt(Status :%size(Status) :Txt(3));

    The benefit of that is that all the message ID's used are held in one place - a compile-time array at the bottom of the source member - rather than being hard-coded in the calc specs.

    Of course, having the compile-time array being a combination of OrdSts AND MsgID would be even better:


    so you could do a simple lookup:

    x = %lookup( OrdSts : OrdStsArr );
    if x > 0;
    RtvMsgTxt(Status :%size(Status) :OrdStsMsgID(x));
    Status = 'Unknown status';

    but that's a bigger code change.

  • #2
    Hi, Rory

    You've suggested some excellent alternative implementations, so don't be surprised if your name shows up in next months API Corner with some code that may look very familiar Depending on the "bigger picture" of the application any of the three approaches might be the right way to go (along with a few others now that I'm thinking of the application code rather than usage of the API) -- and all three get rid of the textual source in the program.


    • #3
      You left out the simplest solution: Create a separate stand-alone RPG program that accepts the letter code as a parameter and returns the text description. There is only one program to change if the size of the table changes. And there is less chance of message assignment conflicts. This becomes more likely as multiple vendor products are added systems and library lists expand.