Problem ACCEPT data-item using GnuCOBOL 3.2?

[Guido Rebry]

Hi!

Program test1.cob accepts 1 data-item (defined in WS pic x(9)) from the screen, programmed in a loop, 3 times. Every time the cursor is positioned at the beginning of that item.
OK.
Program test2.cob is a copy of test1.cob. The only difference is : I added
. CURSOR IS cursorrowcol (in special-names)
. cursorrowcol pic 9(6) (in WS)
When executing the second accept, the cursor is not positioned correctly. (pos. 5 if 4 chars entered, pos 6 if 5 chars entered, ... etc) and i have to press the home key to position it at the beginning.
I have no explanation. Test1.cob does what I expect. Test2.cob should do the same but doesn't.
Who can help?

Both programs are compiled like this : cobc -x TEST1.cob -l pdcurses and cobc -x TEST2.cob -l pdcurses
I use the package GnuCobol32M-BDB-x64-rc2 (made by Arnold Trembley)

I add the 2 programs.

Regards.
Guido Rebry.

[Anonymous]

I did some more testing with the programs test1 and test2. They don't compile when using cobol 3.1.2 , 32 bits or 64 bits, pdcurses missing.

I copied test2 to test3 and changed it a bit to show that "CURSOR IS" works well with cobol 3.2, 64 bits. It stores the row an column where you clicked the mouse.
And I added 3 accepts, every time on a different line. In that case the cursor is positioned as it should.
Strange, when accepting on the same line, it's not.

I add the program test3.

[Chuck Haatvedt]

Guido,

using GDB I was able to find where in the cobol runtime this behavior is being implemented.

It appears that if the SPECIAL-NAMES CURSOR IS clause is being used and the result of the previous ACCEPT statement resulted in the cursor position being in the same field as the current ACCEPT, then the cursor position after the previous ACCEPT is being used.

To avoid this behavior do NOT use the SPECIAL-NAMES CURSOR clause...

instead use the "CBL_GET_CSR_POS" function to retrieve the current cursor position. Note that the cursor position is changed by both ACCEPT and DISPLAY statements.

PS... I will check with Simon and confirm whether this is the expected behavior and if so we need to document this a bit better in the PROGRAMMERS GUIDE along with the alternative way of using the system function above... Otherwise we need to fix the runtime.

Thanks...

   Chuck Haatvedt

[Chuck Haatvedt]

Hello Guido,

It turns out that this behavior is following the COBOL standard ... see below...

18) The initial position of the cursor is determined by the CURSOR clause in the SPECIAL-NAMES paragraph.

a) If the CURSOR clause is not specified, the initial cursor position during the execution of an ACCEPT screen statement is the start of the first input field described within screen-name-1.

b) If the CURSOR clause is specified, the initial cursor position is that represented by the value of the cursor locator at the beginning of the execution of the ACCEPT screen statement. If the cursor locator does not indicate a position within an input field, the cursor shall be positioned as if the CURSOR clause had not been specified.

ps... I think that my advice on how to avoid this is correct if that is your intention.

Chuck Haatvedt

[Simon Sobisch]

When executing the second accept, the cursor is not positioned correctly. (pos. 5 if 4 chars entered, pos 6 if 5 chars entered, ... etc) and i have to press the home key to position it at the beginning.

According to the quote of the standard that's exactly the right behavior.
If you don't want the CURSOR IS clause to be applied on ACCEPT you'd have to do one of the following:
* don't add it in SPECIAL-NAMES and (only when) you want to get the screen position call CBL_GET_CSR_POS directly after ACCEPT
* leave the CURSOR clause in, but set it to an invalid position (999999 is likely to always be invalid) or the starting position of the field

[Anonymous]

. Leaving the CURSOR clause in and setting it to 999999 works fine.
. Leaving the CURSOR clause in and setting it to the starting position of the field also works fine. It seems strange I have to set that starting position because it is given in the DISPLAY ... AT ... statement. But OK, it works.
. I used the CURSOR clause because I want to know the row/col of a mouse click. Using "CBL_GET_CSR_POS" (and no CURSOR clause) always gives row 0 and col 3...
(because I use "accept screendummy at 001001 with foreground-color black end-accept" with "screendummy pic x(03)" to detect the mouse click?)
I added "unsigned" to the field definition for the line and column because my screen has more than 127 columns.
**. Can i find that " COBOL standard" somewhere online? **

. Anyway, my "problem" is solved. I will set CURSOR to the starting position of the field.

. TYVM!!!

[Simon Sobisch]

The ISO publishes the standard for big $$$ - but you can also grab the last draft (nearly identical to the published 2023 one - content-wise) from the COBOL Working Group.
Saldly this is now also behind the ISO member login, but the old one is archived, for example at https://web.archive.org/web/20221109092121/https://isotc.iso.org/livelink/livelink?func=ll&objId=21916208 so you can grab the draft there.

CBL_GET_SCR_POS is a system library call (so not in the standard) but you'll find it either in the Programmer's Guide or when searching for its name online.

For the mouse: You likely want to use ACCEPT OMITTED for "just a click or function key" and you may want/need to adjust COB_MOUSE_FLAGS.

[Anonymous]

Again, TYVM!