I found this question on the website and I can't comment on it so I repost it for further explanations. Original: AS400 RPG DSPF Character Level Color Change
The author seems to have answered the question himself with a comment:
This question is resolved now. Not possible using DSPF but can change colors of specific character by inserting a blank before then and adding a hexadecimal value of colors.
I'm new to learning the as/400 and I just can't find anything about adding a blank in a field in the program.
How do I add a blank in a field in a program and how do I insert a DSPATR() hex value in my program? If you can explain or point me to documentation that does, I would be grateful.
It's very seldom useful, but it can help in understanding some of the limits of basic display terminal output.
You insert a blank by something like this:
name = 'Bob' + ' ' + 'Marl' ;
There is then a "blank" between the 'Bob' part of name and the 'Marl' part. I'd guess that you're thinking that that's a pretty trivial explanation, but seriously that's all there is to it. Any number of other methods might be used to "insert" a "blank", but they all boil down to that basic idea.
At least, that's all there is to that tiny part. That leads to the more complex question of character level color control for a 5250 display.
The 5250 display protocol is character-based and field-based. You can display printable characters, and various attributes such as color apply at the field level. That is, in order to set a color, you must set it for a complete display field rather than for each character within a field.
In fact, each field necessarily has its attributes held in a bit pattern that occupies a single position on the screen. Examination of any number of screens will show that there is always at least one apparently blank screen position just before any field on the screen (even if that position is at the right-hand end of the previous line). For that reason, there will never be two directly adjacent fields that will have different colors on-screen at the same time.
However, the fundamental definition of "field" may be somewhat manipulated by program code. Consider this code:
name = 'Bob' + x'32' + 'Marl' ;
Now, instead of a blank, we've put a hex value into the middle of the variable. If the name variable is a display field and the above value is on the screen, the terminal/emulator will interpret it as two separate fields. The 'Bob' portion will have whatever attributes were defined in the display file for the name field. But the rest of the 'field' will take on the attribute that is represented by the x'32' bit pattern, i.e., the 'Marl' characters will all be yellow.
There is another character position that immediately follows a field on a display. This marks the end of the field. The default hex value is x'20', but any position that contains a valid attribute bit pattern will be interpreted as the 'end'. Because of that, the position might actually hold the attribute for the next field. So only a single screen position is needed to mark both the end of one field and the beginning of the next. (It's a little more complicated, but we can ignore how field addresses are actually maintained. The relevant part here is the display attributes.)
Okay, that shows one basic part of controlling color at some beginning screen address. But it only hints at how a single character within a field might be manipulated. Here's the ugly part:
name = 'Bob' + x'32' + 'M' + x'20' + 'arl' ;
In that example, the 'Bob' part will have whatever color that the name field was defined to have. Then there will be a blank on the screen, followed by a yellow 'S', followed by another blank position on-screen. After that, 'arl' will be displayed with "normal" display attributes. (That "normal" part is unrelated to whatever the name field is defined to display as. However, a program can also control colors at the field level, so your code can coordinate field color with whatever attribute value you might choose instead of x'20'.)
In short, if you want a value such as 'Bob Marl' displayed so that each letter would have a different color, the minimum you could get away with would stretch out to 'B o b M a r l'. By placing different appropriate hex values into each of those blank spots, each letter could be different.
Not pretty. It's not a very attractive option, neither in code nor as an effect on-screen.
In other words, if you want individual characters to have their own colors, each character must have a position before and after on-screen that will appear as a blank.
A far better option would be to use a browser interface to display data or any of various other means that allow full control of attributes on the client.