Why stop there?

[WoofDog]

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

Nice article!

However, I wonder why you don't go all the way and integrate the field values into the messageids. This way you would eliminate the need for the Select altogether.

If a new value has to be added to the order status code, with the technique demonstrated in your example program, you'd still need to hunt down all the programs that displays order status texts.

By integrating the order status code into the message ID and making them a little more meaningful (like maybe using OST000P in stead of DSP0100, OST000O in stead of DSP0101, etc - OST is Order Status Text) you'd eliminate this need, because then all that's needed is to add the appropriate message to the message file.

The Select construct could then be replaced by a simple
RtvMsgTxt(Status :%size(Status) :'OST000' + OrdSts);

PS. If the above text in unclear, I blame it on the fact that English isn't my first language. Sorry. :-)

[BVining]

An interesting idea, but unfortunately concatenating the OrdSts value won't work in all cases. In general the last four characters of a message ID must to be constructed from the characters 0 - 9 and A - F. So while an OrdSts value of 'C' will result in a valid message ID of OSP000C, an OrdSts value such as 'P' will result in diagnostic message CPF2499 -- Message identifier OST000P not allowed -- when trying to add the OSP000P message description.

One could extend the idea and map the OrdSts character value to a valid message ID value range (such as 'P' being mapped to 'D7' using its EBCDIC hex value, resulting in OST00D7; or its unsigned numeric value, resulting in OST0215), but that's not as simple (and can easily lead to future problems when generalizing the technique outside of OrdSts).

And incidentally, congratulations on your English. It's a whole lot better than many who have English as their first (and only) language