Recently added were CONTROL
(a literal or a variable that contains screen attributes as text names and COLOR
(a variable that contains screenio attributes as calculated integer, an ACUCOBOL extension).
Everything you can use this for is also available with reserved words, which are checked at compile time, on runtime unsupported attributes are just skipped conflicting/duplicate attributes are handled from left to right.
The parsed attributes for CONTROL
can be seen in https://sourceforge.net/p/gnucobol/code/5052/tree//branches/gnucobol-3.x/libcob/screenio.c#l655, the numbers for CONTROL
around line 482+
Together with those changes the screen attributes LEFTLINE
, RIGHTLINE
(GC extension), OVERLINE
are now supported - but those are commonly not available (so far I only know of PDCurses that support those). LEFTLINE
and RIGHTLINE
places a left/right line into every place of the field, therefore I guess they will be mostly used on a single character field.
As other extended screenio features "if the terminal / screenio library used does not support it, they are ignored"; which is possibly something that should be explicit noted - but that also is true for many others, for example BOLD
, BLINK
, BELL
and even for colors (a monochrome display may map all these as black/white/gray).
There is one thing special for CONTROL
(an RM/COBOL extension), that was requested before and cannot be done portable otherwise - drawing of line characters. CONTROL "GRAPHICS"
replaces a specific set of characters to single/double line drawing characters. See [r5057] for the change (the list in screenio.c shows which characters are mapped to which line drawing symbol, but the example that is included in the testsuite in that commit may show that better). Every character that is not in the list is taken over "as-is".
@dilodilo: You're maybe also interested in testing this -if you could help writing the text for these attributes in the programmer's guide / recheck them, that would be quite helpful.
Commit: [r5057]
Discussion: Patch Documentation Improvements
Patches: #58
@dilodilo: please have a look at the referenced entries above to see both what
CONTROL
does and how to use it (seen in the new testsuite entry: you can specifyCONTROL 'literal attr'
orCONTROL data-item
- especially the later is useful as it allows to change the screen attribute at runtime, for example to change the colors, make it bold, ...) - the supported attributes are also seen in this commit (the table, as noted in the text above).CONTROL literal
is most useful forCONTROL 'GRPAHICS
).If you have not executed the tests from
make checkmanual
then this may be a good time (if you build GnuCOBOL from source, otherwise you could copy/paste the interesting entries from the testsuite and execute them manually.I've looked at the links above but frankly it's not enough for me.
If it's a feature that other compilers also have, then can you suggest I look at the manual for those compilers somewhere on the web?
The issue here is that the PG is a free document under a free license - and therefore one should not "copy" the content of another non-free documentation. The best thing to reach that is to document what is implemented "directly".
But we could have a look at the links together, that may be useful.
This still does not hinder anyone to search for "RM COBOL DISPLAY CONTROL phrase" (I think that's where it originally came from and
CONTROL "GRAPHICS"
is so far likely an RM/COBOL only extension) or "ACU COBOL DISPLAY COLOR phrase", but for the documentation part I highly suggest to document from the implementation and the examples (make checkmanual
in a source build, or copy/paste from tests/testsuite.src/run_manual_screen.at) instead.If you don't build GC yourself you could checkout the nightly binaries, the most current one for MinGW are available (30 day from now) at https://ci.appveyor.com/project/GitMensch/gnucobol-3-x-win32-posix/build/job/2q9qjfi1poi24863/artifacts
ping @dilodilo - can we move this from Vince to you, or should it stay there?
Ok
I will write the documentation for the new CONTROL clause of the DISPLAY statement.
As always, Vince will be responsible for updating the PG.
On 13/01/2024 16:30, Eugenio Di Lorenzo wrote:
For every one else that has made changes to the compiler please specify
in detail exactly what changes have taken place and where possible the
text to include and where - it will make my life easier without me
trying to guess your intentions or worse "ASSUME".
At 76 year old - I have stopped "Assuming", actually have stopped, many
years ago when writing manuals or programs.
Hi Vince,
what you rightly ask, in this case, can only be detailed and specified by Simon.
Hi,
below is a draft documentation of the new CONTROL and COLOR clause to be added to statement 7.8.12.4. DISPLAY data-item.
I have reported both the complete syntax scheme with all the current features to which I have added the CONTROL and the COLOR clause.
I suggest copying it in its entirety, not just the lines with the CONTROL and COLOR clause, as I fixed some imperfections on the brackets.
The textual part should be validated by Simon.
It is not clear to me whether the CONTROL and COLOR clause have also been implemented for ACCEPT.
In this case, chapter 7.8.1.4 would also need to be updated. ACCEPT data-item.
Please Simon, let me know.
PS. If the format of this post isn't right, I'll attach a TXT file with the same content.
CONTROL phrase.
The CONTROL phrase allow dynamic (runtime as opposed to compile time) specification of characteristics.
Literal-7 must be a nonnumeric literal. Identifier-7 must be a nonnumeric data item.
The value of identifier-7 or literal-7 in the CONTROL phrase must be a character-string
consisting of a series of keywords delimited by commas; some keywords allow assignment
of a value by following the keyword with an equal sign and the value.
Blanks are ignored in the character-string.
Lowercase letters are treated as uppercase letters within keywords.
Keywords specified override corresponding static options specified as phrases.
Keywords may be specified in any order.
Keywords, which specify options that do not apply to the statement, are ignored.
The keywords that affect a DISPLAY statement are
BEEP, BLINK, CONVERT, REVERSE, UNDERLINE, ERASE, ERASE EOL, ERASE EOS, HIGH, LOW,
NO BEEP, NO BLINK, NO CONVERT, NO REVERSE, NO UNDERLINE NO ERASE.
The meanings of these keywords when they appear in the value of the CONTROL phrase operand are the same
as the corresponding phrases which may be written as static options of the DISPLAY statement,
with the addition of the negative forms to allow suppression of statically declared options.
GnuCOBOL provides three additional keywords in the CONTROL phrase that affect a DISPLAY field.
1. FCOLOR = color-name
When FCOLOR is present, color-name specifies the foreground color of the DISPLAY field.
This name is then used as the default value for subsequent DISPLAY statements in the program.
The initial default for color-name is white.
2. BCOLOR = color-name
When BCOLOR is present, color-name specifies the background color of the DISPLAY field.
This value is then used as the default value for subsequent DISPLAY statements in the program.
The initial default for color-name is black.
Following table contains a list of all the possible names for color-name.
The left column contains the valid color name.
The right column shows the color that appears when high intensity is specified (the default intensity).
The GRAPHICS keyword causes the characters in following table to be translated to line draw characters.
Characters that are not listed in the following table are output unchanged.
If the requested line draw characters are not available, the runtime system uses the best available characters.
If double-line characters are requested and only single-line characters are available, they are used.
If no line draw characters are available, then plus-characters, vertical bars, and dashes are used.
Sample program that demonstrates how boxes are drawn:
Added a screenshot from sample program using "GRAPHICS"
COLOR Phrase
The COLOR phrase provides an alternate method for setting video attributes.
Integer-8 must be a numeric literal. Identifier-8 must be a numeric data item.
They can be set to different numeric values to express various combinations of colors and video attributes.
You may make combinations by adding the appropriate values together.
The following color values are accepted:
You may specify other video attributes by adding the following values:
You may also specify high intensity by adding "8" to the foreground color value.
Sample program that demonstrates how COLOR is used:
Last edit: Eugenio Di Lorenzo 2024-01-14
Both
COLOR
andCONTROL
are valid for bothACCEPT
andSCREEN
(of course, they have to be available as reserved words).COLOR
takes both a (numeric) literal or a numeric integer.Otherwise that explanation looks good to me.
sorry but your last post is not clear.
From yout previous post:
Both COLOR and CONTROL are valid for both ACCEPT and SCREEN (of course, they have to be available as reserved words).
maybe you wanted to write:
Both COLOR and CONTROL are valid for both ACCEPT and DISPLAY (of course, they have to be available as reserved words).
CONTROL and COLOR cannot be used in the SCREEN SECTION !
can you confirm ?
They are implemented in
ACCEPT
andDISPLAY
but not in theSCREEN SECTION
(where they are parsed but raise a not-implemented warning).... thinking about that again, this would be relative easy to add without breaking compatibility (which was the reason that it was not implemented in the first place) using some hack (extending the existingcob_screen
structure, but only handle the additional fields if thecob_module
is 3.3 or newer).Someone wants to provide a patch for that?
Hi Simon,
the previous post has been updated, now also contains documentation of the COLOR clause in addition to the CONTROL clause.
I had to do several tests using GC 3.2 from Arnold, to understand what it was.
Now I think your validation is necessary to verify that it is correct.
Vince will then be able to update the Programmers Guide.
Hi,
attached is the final documentation of the new CONTROL and COLOR clause to be added to statements 7.8.1.4. ACCEPT data-item and 7.8.12.4. DISPLAY data-item.
The documentation has been validated by Simon therefore Vincent can insert it into the PG.
The box of symbols for :
|left tee | t(+) | T(Š) |
|right tee | u(Š) | U(Š) |
|vertical line | x(Š) | X(Š) |
The special character after T, U and X are not understood by tex system
and are ignored - they are omitted from text.
Just what character is it ?
On 15/01/2024 15:46, Eugenio Di Lorenzo wrote:
Attached screenshot shows original graphics characters.
Would it be possible to insert the correct graphic characters into the PG?
Sure but - as noted also in the quoted docs: "system specific"; but if you find the texinfo module/font to add those, we can do so.
The tex package runs under Linux and as far as I know there is NO
provision for IBM chars.
There is even no point to me installing them on my system and I have no
idea if it will cuase issue with the rest of my production system if I do.
Normally IBM char sets are not used under *nix.
On 15/01/2024 21:02, Eugenio Di Lorenzo wrote:
Could be possibly interesting to see what the rest of the text says
regarding Linux - which seems to imply (may be) that there is issues.
On 15/01/2024 19:36, Eugenio Di Lorenzo wrote:
Can some one tell me how I can access these "Featurte Requests" as the do NOT appear under Tickets button.
Am 15.01.2024 um 22:38 schrieb Vincent (Bryan) Coen:
they are named "wish list" there - for historical reaons
I would say that for the moment we can eliminate these graphic symbols from the PG.
The description of each graphic symbol that is present in the table is sufficient.
Later, when we are able, we will insert the graphic symbols for even better documentation.
On 15/01/2024 22:30, Eugenio Di Lorenzo wrote:
Done - see bug report for same thing el al.