Re: (RtnDspAtr-like) functionality,for EVERY input/output field

[Frank Kolmann <Frank.Kolmann@xxxxxxxxx>]

fwiw
Beg to differ.  I would expect Colour support to have the following.

1 byte can control 256 colours, why is it limited to 14?

I never understood why the Attribute Byte is written to the screen, 
surely it can be kept in the Device buffer.
I guess then there needs to be a new Api, Read Device Buffer.

Already the devices can handle many attribute bytes in a field, so one 
could have many colours in a field, just don't write the attributes to 
the screen

Who uses 'Selector Pens'?
I guess for Selector Pen functionality there needs to be an Attribute 
Byte on the screen, but otherwise why put attribute to the display.

Monochrome devices would fail on the 256 bit combos, but then it will be 
up to the application to detect the device type, '
and for monochrome devices set the appropriate Attribute.
Finally a use for the "Query Color Support (QsnQryColorSup) API" .
So more work for developers to support Monochrome devices and Colour 
devices, backwards compatibility is broken but have a workaround.

Dont hold your breath, this wont happen.
Or has this already been done, I never worked on AS400 Office word 
processing software, I don't know.

Frank


On 24/08/2022 8:30 am, Roger Harman wrote:
> I think it's just semantics.  It does support color via the attribute byte - albeit rudimentary choices - but does not support a true "color" attribute.
>
> No big deal to me.  I can tell you I sometimes have wished there were no colors - I've seen some massively wasted time by developers to leverage that - likely for their own gratification as it certainly did not add to - indeed, detracted from - the user experience.
>
>
>
> -----Original Message-----
> From: RPG400-L <rpg400-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Frank Kolmann
> Sent: Tuesday, August 23, 2022 1:46 PM
> To: rpg400-l@xxxxxxxxxxxxxxxxxx
> Subject: Re: (RtnDspAtr-like) functionality,for EVERY input/output field
>
> Ok Roger,here goes.  I could be wrong and an happy to be corrected.
>
> Originally IBM had model 5291 monochrome terminals and 5292 colour
> terminals.
> The 5292 terminals were very very expensive and hardly no one purchased.
> However the SAME 5250 data stream worked on both devices.
> It was up to the device as to how the Fields attribute byte was interpreted.
>
> When the IBM PC arrived it had by default a colour display.
> Suddenly by inserting a 5250 emulator card into a PC everyone had a
> colour terminal but the screens all looked like GREEN screens.
> One could change how the emulator hardware interpreted the 'attribute
> byte' , so the PC screens had colours even though the
> 5250 data stream was written for 5291 monochrome terminal.
>
> There are at most 14 colours available even on 5292 colour terminals but
> ALL these colours are controlled by the SAME  Field Attribute byte.
> I guess IBM did this so that the SAME code could run no matter what
> terminal type was used.
> There is nothing like the 256 colours available in xterm.
>
> Whenever I coded UDDS or DSM I never bothered with checking if the
> device supported colour or not.
> DSM does have a command  "Query Color Support (QsnQryColorSup) API"
> (QsnQryColorSup) determines if the display device supports color, but I
> never used this API.
>
> In that sense the 5250 data stream simply has a Field Attribute Byte,
> It does not have a Field Colour Byte.
> It does have FCW  Field control Word, but I hardly used that as mostly,
> I think, it had to do with selector pens, that I never used.
>
> fwiw
> Frank
>
>
>
>
> On 23/08/2022 2:50 pm, Roger Harman wrote:
> > I'm confused about your statement re: "...it still has no colour commands" since you reference the "red" attribute byte (x'28').
> >
> > All the attribute bytes,*including color*, should be listed here.
> > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ibm.com%2Fdocs%2Fen%2Fi%2F7.4%3Ftopic%3Dssw_ibm_i_74%2Fapis%2Fdsm1f.htm&amp;data=05%7C01%7C%7Cf6ef820d5dc04c7eb39508da85487d43%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637968843633300980%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=R%2BM%2FeVTO3OQnidJfI1Zh1w3g7ppZ3iNpaukLdQiwITI%3D&amp;reserved=0
> >
> >
> > Roger Harman
> > COMMON Certified Application Developer - ILE RPG on IBM i on Power
> >
> >
> >
> > -----Original Message-----
> > From: RPG400-L<rpg400-l-bounces@xxxxxxxxxxxxxxxxxx>  On Behalf Of Frank Kolmann
> > Sent: Monday, August 22, 2022 9:08 PM
> > To:rpg400-l@xxxxxxxxxxxxxxxxxx
> > Subject: Re: (RtnDspAtr-like) functionality,for EVERY input/output field
> >
> > Hi Gad
> >
> > The short answer is No.
> >
> >
> > The long answer, and I stand to be corrected is:-   (been a while)
> >
> > The best you are going to get is Program-to-screen fields
> >
> > FIELD1_ATR = x'28' ;  // Set colour to red
> >
> >
> >         A            FIELD1           10A  B  4 10DSPATR(&FIELD1_ATR)
> >         A            FIELD1_ATR     1A  P
> >
> >
> > I never noticed lower case field names are not allowed, how archaic is
> > that eh?
> >
> > Your qualified field names ie Field1.color , introduce new RPG reserved
> > words,  ie .color  .BL  .PC  that wont happen IMO.
> > (5250 data streams are all pre OOP)
> >
> > The 5250 data stream was designed for monochrome displays, it still has
> > no Colour commands. afaik
> > Colours are the result of how colour hardware interprets the monochrome
> > controls, IMO this wont change.
> >
> > 5250 Cursor control is not part of the attribute character, It is
> > contained in the FFW Field Format word, FFW is not directly controllable
> > from DDS.
> >
> >
> > Frank