RE: Function key indicators

Carel wrote:

   Two things.

   1) Instead of indicators, why not use the INFDS and the AID?

   2) To use the DUP key I would have to DSs: one contain all the screen
fields, the other similar fields with obvious other names (on V5R1 you may
use key word     QUALIFIED). Then first press, move from DS1 to DS2, second
press move from DS2 to DS1. Unless this is an old RPG III programme.

******
My reply: 
This is a new V5R2 ILE program.
In effect, I do have 2 data structures. Input## being defined as
LikeRec(CIPB00##:*Input) allows it to be set up when the program is just
started being written and no matter how the input fields get added, removed,
or reordered on the screen it still works. It has also been declared as
'qualified'. I originally had PrvInput## defined as a data structure but
changed it to an array so I could code PrvInput##(ForIdx)  vs.
%Subst(PrvInput## : Foridx : 1). This (the array) method is slightly more
intuitive (for me) and easier (for me) to read. This is a tossup, and just a
matter of preference (again, for me).

I need the ability to 'dup' only a part of a field, so moving the entire
field from a saved data structure will not accomplish my goal. 

Having looked through the archives I understand that there has been a
religious war as to whether *InK? or the AID byte method gets you closer to
god, but the *InK? method is intuitive (for me) and I have never used the
AID byte method. I still don't understand why *InK#'s are not being set when
the 'read - format name - data structure'  is used. Is the AID byte being
set correctly when the 'read - format name - data structure' is used? I
don't know. 

Thanks for the suggestions, but I would like to get the *InK? to work if
possible.

Tim Kredlo
Exterior Wood, Inc

Following original message not removed for readers understanding, and
hopefully to generate more responses.

On 3-8-04 at 16:49 Tim Kredlo wrote:

>I am attempting to 'genericize' the routine I use to test for the 'dup' 
>key use.
> 
>I would like it to be generic enough so that it would work without 
>modification when the length or layout of the input data changes. Most 
>screens have I, O,and B data interspersed. (## represents the 'screen 
>number id')
>
>To do this I declare the input buffer (Input## -LikeRec(PgmScrn##:*Input)).
I cycle through the input data structure character by >character
substituting any found 'dup' characters with the corresponding character
from a 'saved' input buffer (PrvInput03  S   1 >Dim(%Len(Input##))), until I
get to the end (%Len(Input01)). For this to work I changed my typical (all I
ever use) 'exfmt' with a 'write >format' line, followed by a
'read-formatname-data structure' line. (I could not figure out how to
automatically fill the input buffer data >structure using 'exfmt')
>
>This works fine. However, changing from 'exfmt' to 
>'read-formatname-data structure' stops the function key indicators 
>(*InKA-*InKY) >from automatically being set on when the corresponding 
>function key is pressed.
>
>If I remove the data structure name from the 'read' line, hitting a 
>function key DOES set on the corresponding *InK? indicator 
>>automatically, just like when I used 'exfmt'. Why does the 
>absence/presence of this data structure name change this?
>
>Is there a way to set up the screen 'reads' so that functions keys 
>automatically set on the corresponding *InK? indicator (like 'exfmt' 
>>does) AND the input buffer data structure gets filled automatically 
>like when the 'read-formatname-data structure' method is used?
>
>(Because of legacy issues I cannot (do not want to) use *In01-*In99 to 
>represent the function keys without a lot more code >modifications than 
>I care to do.) Or is there a different way of declaring the input 
>buffer so that all input fields are contiguous and its length can be 
>determined?