When logic errors occur during data entry, an audible alarm (beep) is required.
The following simple statement
DISPLAY SPACE WITH BELL.
will generate the following compiler error
Screen DISPLAY does not have a LINE or COL clause
Nevertheless the syntax manual specifies that the AT clause is optional, as is the WITH clause:
DISPLAY { identifier-1 [ at-clause ] [ upon-clause ] [ with-clause ] } …
This oddity is observed in cvs download of commit 904.
BTW, this was correct in the official release (build 658).
This error currently exists because the behaviour of a screen
DISPLAYwithout aLINEorCOLclause varies significantly between vendors. Until this fixed, consider using a screen item with theBELLclause orDISPLAY X"07"(if that doesn't workCALL "beep"might).We have a system library call for the beep:
CALL x"E4".But it isn't appropriate to change sources that worked fine with 1.1 if they should work. Althought the behaviour differ I suggest to use the current screen positions and use this for the
DISPLAY- is there anything that speaks against doing so (I think this was the old behaviour).If I remember correctly, the issue with the old behaviour was that the cursor is moved unpredictably in an
ACCEPT/DISPLAY, so subsequent data ends up overwriting previous data ([bugs:#94] and [bugs:#202]).Related
Bugs:
#202Bugs:
#94Last edit: Edward Hart 2016-06-09
Attached is a first draft of a fix. It is quite big.
This bug is fixed by introducing the
LINE/COLUMN 0extension from Micro Focus, ACUCOBOL and RM/COBOL. It is documented here, General Rule 16;LINE 0 COLUMN 0positions aDISPLAYafter the lastDISPLAYstatement (and similarly forACCEPT).LINE 0 COLUMN 0is implied for any fields which have no clauses and which are not the first item. Example:Here,
xis displayed atLINE 1 COLUMN 1,yatLINE 0 COLUMN 0andzatLINE 4 COLUMN 1.Support for
LINE/COLUMN 0can be enabled or disabled with thefield-crt-display-and-pos-zeroconfig option, which I'm thinking of renaming tomf-acu-rm-display-extensions. If the config option is set to "no", the behaviour follows the standard:LINE 0 COLUMN 0is interpreted asLINE 1 COLUMN 1and exceptions are raised. I don't know iffield-crt-display-and-pos-zerowould be better in the runtime configuration or perhaps have a separate runtime configuration flag to complement it.The patch is almost complete except that
field-crt-display-and-pos-zero: nodoes not cause GnuCOBOL to reject statements likeI have also reverted the changes I made allowing mixing of CRT and non-CRT displays. Firstly, to make the syntax more similar to that of Micro Focus. Secondly, because I don't know what ACUCOBOL considered to be an unambiguous
DISPLAY. I also no longer think the current behaviour is unambiguous, e.g. in the statementit is not obvious that
ywill be displayed on STDOUT, not the CRT.To the configuration option:
display-extensionswould be fineTo ACUCOBOL:
The most important part is: ACU defaults to CRT display if the UPON phrase is omitted, see
DISPLAY scr-itemANSI-Format, Syntax Rule 5To the patch:
Whoa... may break something but it is much better than the current version. BTW: clever idea and nice addition of LINE/COL 0.
This second patch has the following changes:
ACCEPTandDISPLAYstatements;field-crt-display-and-pos-zerotoaccept-display-extensions;console-is-crtconfig option for ACUCOBOL; andACCEPTstatements.Very good. The only thing that I'd try to change is
(!cb_accept_display_extensions) { cb_error_xtocb_verify(we may need a change here for something likecb_verify_x).And updating the copyright year in the files you change including 2016 if it isn't in already.
One question:
The second patch removes function declarations in common.h which the first doesn't. Is this intended?
Yes, it was because
cob_field_acceptdidn't need a flag indicating whether to allowLINE/COL 0.Patch commited (with change from
cb_error_xtocb_verify_x) in [r996].