Re: Indicator Coding Technique

Apart from the keyboard locking issue (which was the original reason to let go 
of the ERRMSG keyword), often, we need to position the cursor even if there is 
no error. Example: the user press F4 to get a list of possible values for a 
field. Upon returning, we want the cursor to be where it was when F4 was 
pressed, not on the first input field.

Some other less important benefit of using message subfile :
- The F1 key is supported to display extended help for a massage
- It also help us in debugging/user support. Because we use subfile message, we 
can press F1 on a message and see details (especially the message ID). We can 
then look into the RPG source for this ID to find out what caused the error. 
- We can send several message at once and the user can see them all (position 
himself on the message line and press page up to see next message). This way, 
we avoid the fix one error, press enter, fix another error, press enter ... If 
the use wants to , he can see all error message at once.

Also, this is a personal preference, I like having all the logic in the RPG 
program and none in the display file. But I am sure that valid argument can be 
made for putting more logic in the DSPF.

Denis Robitaille
Directeur services technique TI
819 363 6130

SUPPORT
Jour (EST) Daytime : 819-363-6134
En-dehors des heures (EST) After hour : 819-363-6158
Network Status : 819-363-6157

>>> booth@xxxxxxxxxxxx 2006-01-12 17:03:43 >>>
ahhh...  that must be it.  I always supposed it was the use of the 
keyword ERRSFL that stopped the keyboard lock irritation.

I am unclear why you would use an indicator for just cursor positioning, 
when  the use of the same indicator can specify the message, the cursor 
position, and be set off with the ERRMSGID keyword?



Denis Robitaille wrote:
> But, if memory serves me right, when we use this keyword, we must press 
> "reset" to regain access to the keyboard. Also, this forces me to use an 
> indicator for each error condition. But you are right, it would take care of 
> the cursor positioning and highlithing. In our case, we would use ERRMSGID 
> instead of ERRMSG since our system support several languages.
> 
> Thanks for the info.
> 
> Denis Robitaille
> Directeur services technique TI
> 819 363 6130
> 
> SUPPORT
> Jour (EST) Daytime : 819-363-6134
> En-dehors des heures (EST) After hour : 819-363-6158
> Network Status : 819-363-6157
> 
>>>> booth@xxxxxxxxxxxx 2006-01-12 16:10:16 >>>
> Consider using the EERRMSG keyword for errors.  There's no need for you 
> to position the cursor.
> 
> "When the message is displayed, the following conditions occur:
> 
> For all errors:
> The message is highlighted.
> ... (snip)...
> The cursor is repositioned to the first displayed field that is in error.
> 
> ...'
> 
> 
> 
> Denis Robitaille wrote:
>> I like most of this post.
>> ...
>> I also want to stress that using the display file data structure to find out 
>> the pressed key is the way to go. this way, all keys can be treated the same 
>> way (function keys, page up/down, print screen, even enter).
>>
>> Denis Robitaille
>> Directeur services technique TI
>> 819 363 6130
>>
>> SUPPORT
>> Jour (EST) Daytime : 819-363-6134
>> En-dehors des heures (EST) After hour : 819-363-6158
>> Network Status : 819-363-6157
>>
>>
> -----------------------------------
> Booth Martin
> http://martinvt.com 
> -----------------------------------