** 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. :-)
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. :-)
Comment