Menu

#246 display: AT clause is required?

GC 2.2
closed
5 - default
2017-04-10
2016-06-09
wim niemans
No

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 ] } …

Related

Bugs: #248
Bugs: #264
Wish List: #103
Patches: #26

Discussion

  • wim niemans

    wim niemans - 2016-06-09

    This oddity is observed in cvs download of commit 904.
    BTW, this was correct in the official release (build 658).

     
  • Edward Hart

    Edward Hart - 2016-06-09
    • labels: --> screen section
    • status: open --> accepted
    • assigned_to: Edward Hart
     
  • Edward Hart

    Edward Hart - 2016-06-09

    This error currently exists because the behaviour of a screen DISPLAY without a LINE or COL clause varies significantly between vendors. Until this fixed, consider using a screen item with the BELL clause or DISPLAY X"07" (if that doesn't work CALL "beep" might).

     
    • Simon Sobisch

      Simon Sobisch - 2016-06-09

      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).

       
      • Edward Hart

        Edward Hart - 2016-06-09

        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: #202
        Bugs: #94


        Last edit: Edward Hart 2016-06-09
  • Edward Hart

    Edward Hart - 2016-07-14

    Attached is a first draft of a fix. It is quite big.

    This bug is fixed by introducing the LINE/COLUMN 0 extension from Micro Focus, ACUCOBOL and RM/COBOL. It is documented here, General Rule 16; LINE 0 COLUMN 0 positions a DISPLAY after the last DISPLAY statement (and similarly for ACCEPT). LINE 0 COLUMN 0 is implied for any fields which have no clauses and which are not the first item. Example:

    :::cobolfree
    DISPLAY x, y, z AT LINE 4
    

    Here, x is displayed at LINE 1 COLUMN 1, y at LINE 0 COLUMN 0 and z at LINE 4 COLUMN 1.

    Support for LINE/COLUMN 0 can be enabled or disabled with the field-crt-display-and-pos-zero config option, which I'm thinking of renaming to mf-acu-rm-display-extensions. If the config option is set to "no", the behaviour follows the standard: LINE 0 COLUMN 0 is interpreted as LINE 1 COLUMN 1 and exceptions are raised. I don't know if field-crt-display-and-pos-zero would 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: no does not cause GnuCOBOL to reject statements like

    :::cobolfree
    DISPLAY "not a screen" AT LINE 1, HIGHLIGHT.
    

    I 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 statement

    :::cobolfree
    DISPLAY x AT LINE 1, y
    

    it is not obvious that y will be displayed on STDOUT, not the CRT.

     
  • Simon Sobisch

    Simon Sobisch - 2016-07-15

    To the configuration option:

    • it should stay a compiler configuration as some (possbily older) programs may need it while others don't - if we'd use a runtime configuration this would change the behaviour of all
    • please don't rename it to mf-acu-rm-stuff, I think display-extensions would be fine

    To ACUCOBOL:
    The most important part is: ACU defaults to CRT display if the UPON phrase is omitted, see DISPLAY scr-item ANSI-Format, Syntax Rule 5

    To 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.

     
  • Edward Hart

    Edward Hart - 2016-07-17

    This second patch has the following changes:

    • added checks for non-standard CRT ACCEPT and DISPLAY statements;
    • changed field-crt-display-and-pos-zero to accept-display-extensions;
    • added console-is-crt config option for ACUCOBOL; and
    • fixed a bug where context-sensitive words weren't activated in ACCEPT statements.
     
    • Simon Sobisch

      Simon Sobisch - 2016-07-17

      Very good. The only thing that I'd try to change is (!cb_accept_display_extensions) { cb_error_x to cb_verify (we may need a change here for something like cb_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?

       
      • Edward Hart

        Edward Hart - 2016-07-18

        The second patch removes function declarations in common.h which the first doesn't. Is this intended?

        Yes, it was because cob_field_accept didn't need a flag indicating whether to allow LINE/COL 0.

         
  • Edward Hart

    Edward Hart - 2016-07-18

    Patch commited (with change from cb_error_x to cb_verify_x) in [r996].

     
  • Edward Hart

    Edward Hart - 2016-07-18
    • status: accepted --> closed
     

Log in to post a comment.

MongoDB Logo MongoDB