Re: Display file attributes

[Vernon Hamberg <vhamberg@xxxxxxxxxxx>]

Tim

What is the declaration of &MESG78_A - should be 1 character, right? And 
what value do you give it?

Also, is it defined in the same format where it is used?

Vern

At 06:54 PM 11/3/2004, you wrote:
> Following suggestions made by list members to a previously asked question, I
> have converted a display file from using an indicator driven/hard-coded
> attribute to using a program generated attribute field. I have encountered a
> discrepancy I did not expect. This being my first attempt at using these 'P'
> fields, I don't know if my expectations were wrong or my implementation was
> incorrect.
>
> Initially, the DDS for the field had:
> A            MESG78        78   O 22  2
> A  99                                             DSPATR(RI)
> A  99                                             DSPATR(BL)
> A                                           24  3'F12>'
> I changed this to:
> A            MESG78        78   O 22  2
> A                                      DSPATR(&MESG78_A)
> A                                           24  3'F12>'
>
> Note that the only change is in the 'DSPATR' lines.
>
> Initially, when there was an error (*In99 - *On) the field Mesg78 would show
> correctly, reverse imaged and blinking. The 'non-field' part of the display
> (line22pos80, line23, and line24pos1) immediately following the MESG78 field
> would show as normal.
>
> After I changed to using the attribute field 'Mesg78_A', the Mesg78 field
> was reverse imaged and blinking, but the attributes did not stop at the end
> of the intended field. Instead, they continued until line 24, position 1.
> This is the position immediately before the space where the attributes for
> next declared field would be. In neither case does the constant 'F12>' have
> any explicitly declared attributes, either hard-coded or P-Fields.
>
> I did not see anything concerning differences between 'hard-code' DSPATRs
> and P-field DSPATRs in the 'DDS Reference: Display Files' manual.
>
> I have not done enough testing to verify my conclusion, but it appears that
> a P-Field attribute is in effect until the next declared screen field is
> reached, and that a hardcode attribute applies only to the intended field.
>
> Is this difference intentional?
> Do I have something incorrect in my code?
> What is the best method of having the P-field attribute end where intended?
> If this is an 'undocumented feature', are there any others that I should be
> aware of before (if) I adopt 'P-fields' as my standard method of applying
> attributes?
>
> Thanks in advance for any help.
>
> Tim Kredlo
> Exterior Wood, Inc
>
>
>
>
> --
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.