How to Display some ASCII codes

[Eugenio Di Lorenzo]

Hi ,
does anyone know how to display the ASCII symbols associated with the codes from X'00 'to X'0F' and from X'10 'to X'1F'?
They are symbols that can be useful in a character interface such as vertical and horizontal arrows and other ...

GnuCOBOL displays only space characters or "CTRL" characters see screenshot.

[Eugenio Di Lorenzo]

in this second image at first line are ASCII symbols fron X'00' to X'1F' often named "non printable chars ...

[Simon Sobisch]

You can print whatever the console allows you :-)
I guess the pyqode one either doesn't or isn't in codepage 437. Possibly your PDCurses screen would not display those either. I suggest to start with plain cmd with the cp-437 active and a simple DISPLAY.

[Anonymous]

Hi SImon,
unfortunately I can't understand how to display the symbols from X'00 'to X'1F'.
Example: the suits of the cards: spades, hearts, clubs, and diamonds.
Following is a simple program and attached its screenshot result.
The system displays spaces or the CTRL characters instead of the desired graphic symbols.

Note: code page 850 and code page 437 from X'00 'to X'1F' have the same symbols. however I put in the program the command to set code page = 437.

Same results executing (windows 10) inside OCIDE or outside from a CMD window.

  id division.
  program-id. GCASCIITAB.

  data division.
  working-storage section.
          01  AA PIC X VALUE SPACE .
          01  ll PIC 99 value 0.
          01  cc PIC 99 VALUE 7.
          01  bco PIC 9 VALUE 0.

  procedure division.

  begin.

   call "SYSTEM" USING "MODE CON: CP SELECT=437".
   ACCEPT OMITTED.

   move 1 to ll
  display ' ' at 0101 with blank screen end-display

  DISPLAY "THIS COMPUTER'S ASCII TABLE "      
          AT LINE ll COL cc with background-color bco highlight END-DISPLAY
  compute ll = ll + 2 end-compute
  DISPLAY "---------------------------------" 
          AT LINE ll COL cc with background-color bco END-DISPLAY
  compute ll = ll + 2 end-compute
          DISPLAY "    0 1 2 3 4 5 6 7 8 9 A B C D E F"               
  AT LINE ll COL cc with background-color bco END-DISPLAY
  compute ll = ll + 1 end-compute
  DISPLAY "0x " &
         X"2000" & X"2001" & X"2002" & X"2003" & X"2004" & X"2005" & X"2006" & X"2007" &
         X"2008" & X"2009" & X"200A" & X"200B" & X"200C" & X"200D" & X"200E" & X"200F"
         AT LINE ll COL cc with background-color bco highlight END-DISPLAY
  compute ll = ll + 2 end-compute

  DISPLAY "1x " &
         X"2010" & X"2011" & X"2012" & X"2013" & X"2014" & X"2015" & X"2016" & X"2017" &
         X"2018" & X"2019" & X"201A" & X"201B" & X"201C" & X"201D" & X"201E" & X"201F"
         AT LINE ll COL cc with background-color bco highlight END-DISPLAY
  compute ll = ll + 2 end-compute

  DISPLAY "2x " &
         X"2020" & X"2021" & X"2022" & X"2023" & X"2024" & X"2025" & X"2026" & X"2027" &
         X"2028" & X"2029" & X"202A" & X"202B" & X"202C" & X"202D" & X"202E" & X"202F"
         AT LINE ll COL cc with background-color bco highlight END-DISPLAY
  compute ll = ll + 2 end-compute

  DISPLAY "3x " &
         X"2030" & X"2031" & X"2032" & X"2033" & X"2034" & X"2035" & X"2036" & X"2037" &
         X"2038" & X"2039" & X"203A" & X"203B" & X"203C" & X"203D" & X"203E" & X"203F"
         AT LINE ll COL cc with background-color bco highlight END-DISPLAY
  compute ll = ll + 2 end-compute


  DISPLAY "4x " &
         X"2040" & X"2041" & X"2042" & X"2043" & X"2044" & X"2045" & X"2046" & X"2047" &
         X"2048" & X"2049" & X"204A" & X"204B" & X"204C" & X"204D" & X"204E" & X"204F"
         AT LINE ll COL cc with background-color bco highlight END-DISPLAY
  compute ll = ll + 2 end-compute

  DISPLAY "5x " &
         X"2050" & X"2051" & X"2052" & X"2053" & X"2054" & X"2055" & X"2056" & X"2057" &
         X"2058" & X"2059" & X"205A" & X"205B" & X"205C" & X"205D" & X"205E" & X"205F"
         AT LINE ll COL cc with background-color bco highlight END-DISPLAY
  compute ll = ll + 2 end-compute

  DISPLAY "6x " &
         X"2060" & X"2061" & X"2062" & X"2063" & X"2064" & X"2065" & X"2066" & X"2067" &
         X"2068" & X"2069" & X"206A" & X"206B" & X"206C" & X"206D" & X"206E" & X"206F"
         AT LINE ll COL cc with background-color bco highlight END-DISPLAY
  compute ll = ll + 2 end-compute

  DISPLAY " " 

         AT LINE ll COL cc with background-color bco highlight END-DISPLAY


  STOP RUN.
  exit program.

[Simon Sobisch]

So that was a PDCurses output, now try again without any additional clause to recheck what cmd/pyqode-console do in this case.

[Anonymous]

Hi Simon, thnks forthe hint, I edited the program and re-attach it.
Running only DISPLAY without PDCURSES.
I attach two screenshots.
One by running the program from OCIDE and one by running the program from CMD.
The execution from OCIDE displays strange symbols, but the execution from CMD displays the expected characters!
Now the problem remains of how to view them from PDCURSES.
Do you think it would be possible in some way?

  id division.
  program-id. GCASCIITAB2.

  data division.
  working-storage section.
          01  ll PIC 99 value 0.
          01  cc PIC 99 VALUE 7.
          01  bco PIC 9 VALUE 0.

  procedure division.

  begin.
   call "SYSTEM" USING "MODE CON: CP SELECT=437".

  DISPLAY "THIS COMPUTER'S ASCII TABLE "
  DISPLAY "---------------------------------"
  DISPLAY "    0 1 2 3 4 5 6 7 8 9 A B C D E F"

  DISPLAY "0x " &
         X"2000" & X"2001" & X"2002" & X"2003" & X"2004" & X"2005" & X"2006" & X"2007" &
         X"2008" & X"2009" & X"200A" & X"200B" & X"200C" & X"200D" & X"200E" & X"200F"

  DISPLAY "1x " &
         X"2010" & X"2011" & X"2012" & X"2013" & X"2014" & X"2015" & X"2016" & X"2017" &
         X"2018" & X"2019" & X"201A" & X"201B" & X"201C" & X"201D" & X"201E" & X"201F"

  DISPLAY "2x " &
         X"2020" & X"2021" & X"2022" & X"2023" & X"2024" & X"2025" & X"2026" & X"2027" &
         X"2028" & X"2029" & X"202A" & X"202B" & X"202C" & X"202D" & X"202E" & X"202F"

  DISPLAY "3x " &
         X"2030" & X"2031" & X"2032" & X"2033" & X"2034" & X"2035" & X"2036" & X"2037" &
         X"2038" & X"2039" & X"203A" & X"203B" & X"203C" & X"203D" & X"203E" & X"203F"

  DISPLAY "4x " &
         X"2040" & X"2041" & X"2042" & X"2043" & X"2044" & X"2045" & X"2046" & X"2047" &
         X"2048" & X"2049" & X"204A" & X"204B" & X"204C" & X"204D" & X"204E" & X"204F"

  DISPLAY "5x " &
         X"2050" & X"2051" & X"2052" & X"2053" & X"2054" & X"2055" & X"2056" & X"2057" &
         X"2058" & X"2059" & X"205A" & X"205B" & X"205C" & X"205D" & X"205E" & X"205F"

  DISPLAY "6x " &
         X"2060" & X"2061" & X"2062" & X"2063" & X"2064" & X"2065" & X"2066" & X"2067" &
         X"2068" & X"2069" & X"206A" & X"206B" & X"206C" & X"206D" & X"206E" & X"206F"

  DISPLAY " "

  STOP RUN.
  exit program.

[Eugenio Di Lorenzo]

This issue remained open, I try to ask the question again.

In a windows environment does anyone know how to DISPLAY from a GnuCOBOL program the ASCII symbols associated with the codes from X'00 'to X'0F' and from X'10 'to X'1F'?
(There are some symbols that can be very useful in a TUI character interface such as vertical and horizontal arrows and other ...).

This works well for me by changing the code page to 437 and making DISPLAYS without the "AT" clauses ( = without activating PDCURSES).
If instead I make DISPLAYS with the "AT" clause then the symbols are not displayed well.
Screenshots attached.

I attach two test programs that display all characters with code page 850 (the default) and then with code page 437.

A program does DISPLAY without PDCURSES and a program does DISPLAY with PDCURSES.
The one with PDCURSES (which is obviously the one I'm interested in using) doesn't display the symbols I'm interested in.
Anyone know how to do it?

[Simon Sobisch]

You don't want to display "common characters" (what curses will try to do) but extended tui values (>255 in curses) that would have been at a special position in special codepages (<= 255).

For curses you'd need to pass either:

• the according (non "char") symbols as direct calls (needed to send values > 255)
• the UTF8 values in a pdcurses UTF8 build (or wide build for ncurses with an UTF8 locale active)

Some special values can be explicit requested by DISPLAY GRAPHIC (in this case libcob translates other characters to the curses symbol definitions).

[Michael F Gleason]

Is this what you want?
This program displays all the ascii characters. I wrote it a couple of years ago to see what is actually displayed vs what the docs say.
Tell the program L for characters 0 to 127 or U for characters 128 to 255.

Michael :-)

[Eugenio Di Lorenzo]

HI, Your program is very nice but it doesn't solve my need.
I'll try to explain better.

If instead of the statement
DISPLAY xxxxx
that you used in your program, try using the
DISPLAY xxxxx AT LINE LL COLUMN CC with background-color 2 foreground-color 7
then GnuCOBOL no longer displays the same ASCII characters!

From what I understand, if you use the statement
DISPLAY xxxxx
then GnuCOBOL does not use the functions of the PDCURSES library and therefore displays all ASCII characters well, if instead you use the statement
DISPLAY xxxxx AT LINE LL COLUMN CC with background-color 2 foreground-color 7
then GnuCOBOL uses the functions of the PDCURSES library and unfortunately in this case it no longer displays some ASCII characters well!

I would like to display symbols that correspond to the following ASCII characters:
Dec 16; hex = 10 small triangle with the tip towards the right
Dec 17; hex = 11 little triangle with the tip towards the right
Dec 24; hex = 18 up arrow
Dec 25; hex = 19down arrow
Dec 30; hex = 1E small triangle with the tip pointing upwards
Dec 31; hex = 1Fsmall triangle with the tip pointing downwards

For example, with GnuCOBOL the statement:
DISPLAY x"1E" AT LINE 10 COLUMN 15 with background-color 2 foreground-color 7
doesn't work well, displays something wrong.

This seems very strange to me because the PDCURSES library is used a lot for example by those who program in the C language.
How do C programmers display the characters I mentioned above? (they are symbols that are very useful in a character-based and non-graphical TUI interface).

[Simon Sobisch]

Those are NOT ASCII characters, but characters from some 8bit encoding (codepage).
"This ain't DOS".

How do C programmers display the characters I mentioned above?

As those programmer's likely want portable results, they use either Unicode or UTF8 with a terminal that supports it (after years now also available with newer Windows version as codepage 65001 / CP_UTF8) for "direct" console output and UTF8 for file io. They use the same when working with curses (using either PDCurses UTF8 build [possibly a wide build for Unicode values] or ncursesw with a matching TERM setting).

[Eugenio Di Lorenzo]

Thank you. precise technical response.
The problem remains open, for me it "doesn't make sense" that these two instructions, even placed in the same program, produce a different result on screen.

DISPLAY x"1E"
and
DISPLAY x"1E" AT LINE 10 COLUMN 15 background-color 2 foreground-color 7

Unfortunately I still haven't understood if there is a solution that can be approached by a normal GnuCOBOL developer who uses the version downloaded from Arnold's site.
I'm almost convinced that there isn't a solution within my reach.
I found a discussion on this same topic but I don't think it gave a solution.
https://sourceforge.net/p/gnucobol/discussion/help/thread/577e1225b3/?limit=50#fdae/ae9e/d5e5

If there is a solution, could you give a small code example?
It is just one statement.
DISPLAY x"1E" AT LINE 10 COLUMN 15 background-color 2 foreground-color 7

[Simon Sobisch]

As noted in the PDCursesMod issue tracker you could try to
CALL STATIC "raw_output" USING 1 before and CALL STATIC "raw_output" USING 0 after those displays - which I haven't tested.

Note that this may only work with some ports / terminals and only with PDCurses*.

As noted there: this is definitely not portable, your best bed would be to manually CALL STATIC 'add_wch' USING unicode-int with various values (which quite possibly only works with wide builds).

If there is no problem with wide builds (that would have to be tested), then Arnold could adjust his builds accordingly.

[Eugenio Di Lorenzo]

I added the two CALLS but I have a strange error.
I attach the GnuCOBOL program with the two CALLS I added and a screenshot of the output of the program execution which displays an error message.

cobc -info :

cobc (GnuCOBOL) 3.2.0
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Keisuke Nishida, Roger While, Ron Norman, Simon Sobisch, Edward Hart
Built     Jul 28 2023 16:07:38
Packaged  Jul 28 2023 16:58:47 UTC
C version (MinGW) "13.1.0"

build information
build environment        : i686-w64-mingw32
CC                       : gcc
C version                : (MinGW) "13.1.0"
CPPFLAGS                 : -I/mingw32/include
CFLAGS                   : -O2 -pipe -finline-functions -fsigned-char
                           -Wall -Wwrite-strings -Wmissing-prototypes
                           -Wno-format-y2k
LD                       : R:/msys64/mingw32/i686-w64-mingw32/bin/ld.exe
LDFLAGS                  : 

GnuCOBOL information
COB_CC                   : gcc
COB_CFLAGS               : -pipe -I/mingw32/include -I/mingw32/include
                           -Wno-unused -fsigned-char -Wno-pointer-sign
COB_DEBUG_FLAGS          : -ggdb3 -fasynchronous-unwind-tables
COB_LDFLAGS              : 
COB_LIBS                 : -L/mingw32/lib -lcob
COB_CONFIG_DIR           : /mingw32/share/gnucobol/config
  env: COB_CONFIG_DIR    : C:\OpenCobolIDE\GC20base2\config
COB_COPY_DIR             : /mingw32/share/gnucobol/copy
  env: COB_COPY_DIR      : C:\OpenCobolIDE\GC20base2\copy
COB_MSG_FORMAT           : GCC
COB_OBJECT_EXT           : o
COB_MODULE_EXT           : dll
COB_EXE_EXT              : exe
64bit-mode               : no
BINARY-C-LONG            : 4 bytes
endianness               : little-endian
native EBCDIC            : no
extended screen I/O      : pdcurses
variable file format     : 0
sequential file handler  : built-in
indexed file handler     : BDB
mathematical library     : GMP
XML library              : libxml2
JSON library             : cjson

[Simon Sobisch]

I think that's the "you need an extended DISPLAY first" error.

[Eugenio Di Lorenzo]

Good news.
All codepage symbols are displayed correctly , see screenshot

I will continue with my tests.
Thank you very much for all your precious work.

Attached the working source code.

[Eugenio Di Lorenzo]

I would say that the simple solution you pointed out is just what we were looking for for a long time.
I attach an example of the use of symbols that could not be visualized before.
It is the new version of the GC26LISTVIEW.COB program with horizontal and vertical scroll bars that have arrows at the ends. You can click on them with the mouse to scroll the list.
I'm working on it, as soon as it will be ready it will be released to replace the current version at:
https://sourceforge.net/p/gnucobol/contrib/HEAD/tree/trunk/tools/TUI-TOOLS/

[Simon Sobisch]

Please either include CDF to switch between the "old" mode and the new one or provide two versions. The existing one does work with ncurses, a program with raw_output will be PDCurses* only.

[Eugenio Di Lorenzo]

I will try to create a new version that can also be used with "ncurses".
Attached is a screenshot of the version that does NOT use (arrows) ASCII symbols.

Do you have an idea how you can test into the source code of the GnuCOBOL program at runtime whether you are running under pdcurses or ncurses?
or how to test at runtime whether you are running under Windows or Linux...?

or same hint using CDF ...

[Simon Sobisch]

I'd leave that completely to CDF, at least the Win32 / Linux part; but you have both pdcurses on GNU/Linux and BSD as well as ncurses on Win32, so the distinction here cannot be made according to the OS.

cobc -D USE_NCURSESW -lncursesw prog.cob

>> IF USE_NCURSESW DEFINED
>> ELSE
>> END-IF

Removing the static calls has the benefit that this is all resolved at run-time (no-dependency on a specific library file, and libcob has the library already "in view").
Static calls bind to the library name and if that's different the programs cannot be CALLed (which can be both good or bad).

Only dynamic calls allow CALL 'raw_output' USING 1 ON EXCEPTION SET NO-PDCURSES TO TRUE..

[Guido Rebry]

Nice!
And now for all the UTF-8 characters to be displayed correctly!!!

[Simon Sobisch]

I think that works with both ncursesw (and an UTF8 TERM setting with appropriate font) and with WinGUI already - when using the appropriate unicode/utf8 characters instead of the 8bit encoding ones.

[Anonymous]

I would gladly try it with UTF-8 and also with wingui but I don't know where to start.
Could you give me some guidance / advice / suggestions?

[Guido Rebry]

A simple display of UTF-8 characters as in UTF8-PDC-NO.cob works fine.
(GnuCOBOL package GC32M-BDB-x64 by Arnold Trembley, Windows Terminal with command prompt profile, codepage 65001)

A display at a certain line and column as in UTF8-PDC-YES.cob doesn' work.
Not with pdcurses-wincon.dll, not with pdcurses-wingui.dll.
Not with the call "raw_output", not without that call.

Am I missing something?

[Simon Sobisch]

Thank for the test. The missing piece is testing with PDCurses that uses UTF8=Y.
I guess that this does work, but then needs UTF8 and won't work with any of the 8-bit encodings. Note: UTF8=Y implies WIDE=Y so the ABI changes and you'd need not only a different pdcurses.dll but also a different libcob.dll