Japi2 and Umlaut ä ö ü

[Erich Mueller]

Japi stops if you have an Umlaut in the Textfield when using J-GETTEXT()
01 WS-VNAME BINARY-LONG.
01 YY-VNAME PIC X(30).
01 VNAME PIC X(30).

MOVE " umlaute ä ö ä " TO VNAME
MOVE J-SETTEXT(WS-VNAME, VNAME) TO WS-RET
MOVE J-GETTEXT(WS-VNAME, YY-VNAME) TO WS-RET <---- Japi stops here and says nothing

Any ideas ore workarounds out there ?
Thanks Erich

[thomas]

Doesn't stop when i test with the textfield.cob program which is inside \SWING\examples_simple folder.

[Erich Mueller]

thom,
you are right --- in your case
my data comes from a file, is shown on screen, maybe altered and then restored.
I checked table3, the author (Lazlo?) seems to avoid umlaute !
I forced a ü into the copxybook WS-AUTHORS Field
and the table shows something like Ä/? or whatever
which means Japi does something with the Umlauts
Thanks Erich

[László Erdős]

Hello Erich,

Java always uses Unicode. https://en.wikipedia.org/wiki/Unicode

László

[Erich Mueller]

Hallo László,
That is what I was afraid of .......
But I love my old DOS- Data so I will write a GNUcobol Program to convert them.
Thanks Erich

[László Erdős]

Hi,

MF has a function for this: CBL_STRING_CONVERT.
https://www.microfocus.com/documentation/visual-cobol/VC40/EclWin/GUID-7334059D-682F-4BC9-87F6-AD81F05A2B88.html

Maybe can somebody implement it later here in GnuCOBOL.

But if you convert your data in SQL, then for example PostgreSQL uses also Unicode.

László

[thomas]

Hi László,

Could you please try to compile this program on Netbeans, i have eclipse i don't know how to import Netbeans project.

I think this changes might work but it will need to be tested first.

import java.io.UnsupportedEncodingException;

 public void setEchoChar(Character c) {
        String text = getText();

        //24042021 convert to UTF8
        String original = new String(text);
        try {
            byte[] utf8Bytes = original.getBytes("UTF8");
            byte[] defaultBytes = original.getBytes();

            text = new String(utf8Bytes, "UTF8");

        } 
        catch (UnsupportedEncodingException e) {
            e.printStackTrace();
        }
       //24042021



        setText("");
        setDocument(new Japi2EchoCharDocument(c));
        setText(text);
    }

[Erich Mueller]

Hallo László,
Sorry it seems to be not only an UTF Problem
Testing with FormatedTestField you can key in numbers and letters
as often as you like
but ÜÜÜÜ first time is o.k
doing it again with ÖÖÖÖ program hangs !
you only can kill it the hard way
Any ideas ?
Thanks Erich

[László Erdős]

Hello Erich,

I tried to reproduce the behavior you described: "Japi stops here and says nothing" or "doing it again with ÖÖÖÖ program hangs! you only can kill it the hard way".
But that doesn't happen to me. The letters are not OK because of encoding, but the programs are running.
I am using an HP laptop with Windows 10 Pro, 64 bit with an Intel i7-7500U CPU. And I use cygwin64 with GnuCOBOL.

Oracle Java:
$ java -version
java version "1.8.0_281"
Java(TM) SE Runtime Environment (build 1.8.0_281-b09)
Java HotSpot(TM) 64-Bit Server VM (build 25.281-b09, mixed mode)

GnuCOBOL Info:
$ cobc -info
cobc (GnuCOBOL) 3.1.2.0
Copyright (C) 2020 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 Jan 31 2021 19:12:01
Packaged Dec 23 2020 12:04:58 UTC
C version "10.2.0"

build information
build environment : x86_64-pc-cygwin
CC : gcc
C version : "10.2.0"
CPPFLAGS :
CFLAGS : -O2 -pipe -finline-functions -fsigned-char
-Wall -Wwrite-strings -Wmissing-prototypes
-Wno-format-y2k
LD : /usr/x86_64-pc-cygwin/bin/ld.exe
LDFLAGS :

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

Can you please describe your development environment. Maybe someone has the same OS and compiler version and can do a test. And you can also send a small complete program.

László

[Erich Mueller]

Hallo László,

Yes and thanks for caring about it here it is :

cobc (GnuCOBOL) 3.0-rc1.0
Copyright (C) 2018 Free Software Foundation, Inc.
Lizenz GPLv3+: GNU GPL Version 3 oder neuer http://gnu.org/licenses/gpl.html
Dies ist freie Software; die Kopierbedingungen stehen in den Quellen. Es gibt
KEINE Garantie; auch nicht fuer MARKTGAENGIGKEIT oder FÜR SPEZIELLE ZWECKE.
Geschrieben von Keisuke Nishida, Roger While, Ron Norman, Simon Sobisch, Edward Hart
Erstellt Aug 07 2019 12:13:27
Gepackt Apr 22 2018 22:26:37 UTC
C-Version "6.3.0 20170516"

Build-Informationen
Build-Umgebung : x86_64-pc-linux-gnu
CC : gcc
C version : "6.3.0 20170516"
CPPFLAGS :
CFLAGS : -O2 -pipe -finline-functions -fsigned-char
-Wall -Wwrite-strings -Wmissing-prototypes
-Wno-format-y2k -U_FORTIFY_SOURCE
LD : /usr/bin/ld -m elf_x86_64
LDFLAGS : -Wl,-z,relro,-z,now,-O1

There are a lot of differences should I try to update gcc ?

GnuCOBOL-Information
COB_CC : gcc
COB_CFLAGS : -I/usr/local/include -Wno-unused
-fsigned-char -Wno-pointer-sign -pipe
COB_LDFLAGS :
COB_LIBS : -L/usr/local/lib -lcob -lm -lgmp -lncurses
-ldb-5.3 -ldl
COB_CONFIG_DIR : /usr/local/share/gnucobol/config
COB_COPY_DIR : /usr/local/share/gnucobol/copy
COB_MSG_FORMAT : GCC
COB_OBJECT_EXT : o
COB_MODULE_EXT : so
COB_EXE_EXT :
64bit-mode : ja
BINARY-C-LONG : 8 Bytes
Erweiterte Bildschirm-Ei : ncurses
Variablenformat : 0
Sequenzieller Handler : eingebaut
ISAM-Handler : BDB
Mathematische Bibliothek : GMP

[László Erdős]

And exactly which linux version and which java version do you use?

[Erich Mueller]

openjdk version "11.0.11-ea" 2021-04-20
OpenJDK Runtime Environment (build 11.0.11-ea+8-post-Debian-1)
OpenJDK 64-Bit Server VM (build 11.0.11-ea+8-post-Debian-1, mixed mode, sharing)

DEBIAN 9

[László Erdős]

Hello Erich,

I installed your configuration in Oracle VM VirtualBox, and there I was able to reproduce the bug.

It was in Java part, the calculation of the string length was not correct in some cases with special chars. I uploaded a new version of COBJAPI in SVN.

If you have time, please do an update, and test it again. First check, if your java run (ps -e) and kill it, before you start with the new COBJAPI version.

László

[Erich Mueller]

Thank you so much
because I do like japi
I wrote an emehl to Dr. Joost asking about japis future ---- no response
so I am glad to learn now that you are are caring for it
what is really great.
last night I shot my system installing and playing vscodium
so I decided to install Debian 11 and GNUcobol 3.1 xxxx
plus a new hub and a new SSD so it will take a few
days till I can give you a report
I am very keen going on with Japi not only
because it is of German origin -- German Universities
should do much more in Opensource IT - (I think)
Thans again Erich

[Erich Mueller]

twimc

By the way.... Umlaute
doing INSPECT REPLACE "Ö" by "O"
produce an Error different Length
which clear sine Ö is C396 hex in UTF = 2 Byte
while O is only one byte, workarounds comparing hex with hex
do not work, even Replace "Ö" BY "OE" does not work
but it would be very nice and even clever if it worked

are there some some C-poeple who see a solution ?
--- it is not really urgent

Erich

[Simon Sobisch]

This completely depends on the language settings. If your source file is in iso-8859-1 then Ö is a single byte character and replacing (the single not unicode) variant will work.
INSPECT (or STRING or... any character based statements) with unicode will only work when NATIONAL support is added, that's possible but a bigger thing and "pending", but not on the current list of anybody I know of.

If you do want to use Unicode, then:

• ensure that the encoding of your source is UTF-8, possibly with BOM
• don't use extended characters in user-defined names for now (should be working and supported when NATIONAL support is added to GnuCOBOL)
• ensure that your inputs and outputs (mostly the terminal, possibly curses and printing and people that will handle your [line] sequential files after processing) all support utf-8 and are setup that way
• mind the additional size when defining variables as PIC X (always single-byte) and PIC N (currently UTF-16 = two byte, but only "place-wise", this may change)
• if you want to replace (possibly) multibyte characters: use FUNCTION SUBSTITUTE, not INSPECT (or convert the characters before, but then use hex literals)
• for the inputs (terminal, files, external libaries, ...) and outputs that don't handle that: convert on in/out, depending on what you do a plain CALL "SYSTEM" USING "iconv ..." may be best - or otherwise a conversion routine which possibly works on either hex literals and iterating and/or FUNCTION SUBSITUTE (likely with hex-literals for the "not source encoded" variant)

[Erich Mueller]

interesting, I will try
Thanks Erich

[Erich Mueller]

Hallo László,
DEBIAN 11 and latest Version of japi2
seem to be good friends
formatedtextfield works and also my program(s)
thanks and another question:
why comes japi up with an error after STOP RUN ?
(it happens also with the freshly compiled examples
Erich

[Simon Sobisch]

@ericfromgermany I guess you've missed the MOVE J-QUIT() TO WS-RET before the end of the program.
@laszloerdos Wouldn't it be reasonable to auto-register this in the GnuCOBOL exit handlers via CBL-EXIT-PROC on J-START()? This function is available in different PC based compilers, and via ON EXCEPTION CONTINUE this could also stay portable.

[László Erdős]

Hello Erich,

now I've installed Debian 11 in VirtualBox too, and I've had the same message. But that's a problem with GNOME. In recent versions of GNOME there is no real "tray" like before. You have to install it as an extension.
E.g .: https://extensions.gnome.org/extension/2890/tray-icons-reloaded/
The screenshot shows GNOME with the tray extension.

Or you should use another graphic environment instead of GNOME, e.g. MATE.

László

[Erich Mueller]

Hallo Simon, Laslzo

MOVE J-CHOICEBOX2(WS-FRAME,
"Der Satz wurde upgedated",
"Wie möcten Sie weiter machen ?",
" Programm beenden ",
" Anderer Kunde "
)
TO WS-RET

         IF WS-RET = 1
         MOVE J-QUIT() TO WS-RET
         CLOSE  KUND01-UTF-UPD
         STOP RUN
         END-IF
         I copied the code from the examples
         ... I have no more Ideas what I could change 
         plus I do not understand what Laszlo says

         another question:
         I want to delete/empty a textfield
   01  XX-LEER             PIC X(20) VALUE "-                  ".
   01  XX-LEER2            PIC X(20) VALUE "                   ".

         MOVE J-SETTEXT(WS-VVEND, XX-LEER2) TO WS-RET
         has no effect

         MOVE J-SETTEXT(WS-VNAME, XX-LEER) TO WS-RET
         is a work-around

         I cannot find any special command in the ref's for
         that purpose (J-DISPOSE ?????)

         Thanks for you ongoing Help  Erich

[Erich Mueller]

TrayIconReloaded: that was it !!!!
I never would have found that .
and so quick and simple ......
Thanks for working overtime Erich

[László Erdős]

Hello Erich,

another question: I want to delete/empty a textfield

For this problem I have created a new function J-INITIALIZE. With this function you can initialize a TextField, TextArea or FormattedTextField.
I have added J-INITIALIZE to the following examples: textfield.cob, formattedtextfield.cob and texteditor.cob.

László

[Erich Mueller]

Hallo Laszlo,
J-INITIALIZE does the job !
Thank you
So far I had no success to contact Dr. Merten Joost
the uni-Koblenz, the web-page says he is still alive and working
probably his e.mail addresses are not
Erich