RE: Display file attributes

["Tim Kredlo" <TKredlo@xxxxxxxxxxxxxxxx>]

Vern,

Sorry for the delay in responding to your second question. It IS defined on
the same format.
It is filled dynamically in the program using the display by calling a
couple of subroutines.

In debug the value shows as 'z', the hex equivalent of 'A9', which is what I
had expected, blink/reverse image for protected fields.

Tim 


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Vernon Hamberg
Sent: Wednesday, November 03, 2004 7:27 PM
To: Midrange Systems Technical Discussion
Subject: Re: Display file attributes


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.

--
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.