RE: ERRSFL keyword, and WINDOW

You know, it has been so long since I've sent error messages that way I
completely misunderstood the problem and I now remember why I moved away
from their use many moons ago.  I much prefer the control "rolling my
own" error message subfile provides.  

>From the Application Display Programming manual (can be found under the
WINDOW keyword documentation also):

  A few message-related keywords function differently when used for
windows:
 
     The ERRSFL keyword is ignored.  Its function is performed only 
      when there are no windows on the display.
 
     The MSGLOC keyword is ignored if *MSGLIN is specified on the 
      WINDOW keyword.  Its function is performed only when there are no 
      windows on the display or when *NOMSGLIN is specified on the 
      WINDOW keyword.
 
     Messages resulting from the ERRMSGID, ERRMSG, SFLMSG, 
      SFLMSGID, and DDS validity-checking keywords are displayed in the 
      window but do not lock the keyboard.  Such messages do lock the 
      keyboard when displayed on full-screen displays.

Try this with the sample dsiplay file:

1. Add MSGLOC(24) to the display file.
2. Add *NOMSGLIN to the WINDOW keyword (WINDOW(1 6 11 42 *NOMSGLIN).
   This causes the error messages to be displayed on the line specified
by MSGLOC.
3. Add an error message to FIELDNAME.
4. Add another field to the display.
5. Add an error message to this field also.
6. Compile the display file and then use SDA to test it.

Rather amazing that this will cause the keyboard to lock up.