When I run the code below in a Progress 10.2B08 GUI client, I will see iNumber and rRecid with value 123.
But when I add an extra '>' to both formats, I will see iNumber with value 123, but rRecid is shown blank.
In character I see both values, even when I add extra '>' to the format.
DEFINE VARIABLE iNumber AS INTEGER NO-UNDO INIT '123'.
DEFINE VARIABLE rRecid AS RECID NO-UNDO INIT '123'.
DISPLAY iNumber FORMAT '>>>>>>>>>>>9'
rRecid FORMAT '>>>>>>>>>>>9'
.
The fill-ins are different widths because the rules for determining the default width of a fill-in take the data type into account. Numeric data types like DECIMAL and INTEGER use a fixed-width font. CHARACTER, RECIDs, and some others use a variable-width font. I don't know why RECIDs aren't considered to be numeric.
In a variable-width font spaces are thinner than digits, while in a fixed-width font spaces and digits are the same width. The compiler makes sure that a numeric fill-in is wide enough to display the largest value which can be displayed by its format, but it calculates the width for non-numeric fill-ins (including RECID) using a formula which doesn't guarantee that the data will always be completely visible. In this case, the extra position in the format causes the right-justified data to get "clipped" off the end. It's there but you can't see it because it's beyond the right edge of the fill-in.
If you want RECIDs to display the same way as numeric types, specify a fixed font for the fill-in. In your example, adding "FONT 2" after the format string fixes the issue.
The fill-ins are different widths because the rules for determining the default width of a fill-in take the data type into account. Numeric data types like DECIMAL and INTEGER use a fixed-width font. CHARACTER, RECIDs, and some others use a variable-width font. I don't know why RECIDs aren't considered to be numeric.
In a variable-width font spaces are thinner than digits, while in a fixed-width font spaces and digits are the same width. The compiler makes sure that a numeric fill-in is wide enough to display the largest value which can be displayed by its format, but it calculates the width for non-numeric fill-ins (including RECID) using a formula which doesn't guarantee that the data will always be completely visible. In this case, the extra position in the format causes the right-justified data to get "clipped" off the end. It's there but you can't see it because it's beyond the right edge of the fill-in.
If you want RECIDs to display the same way as numeric types, specify a fixed font for the fill-in. In your example, adding "FONT 2" after the format string fixes the issue.
That explains. Thanks.