Can removal of window records be prevented when writing to nonwindow record
With respect to an AS400 27*132 display file...
When writing to a nonwindow record, all window records are removed from the display. Is there a way to prevent this whereby none of the windows are removed? We are trying to write a 1-line record to line 27 (SLNO(27)) without a series of cascading windows being removed (only the active window remains as it is written after the nonwindow record on line 27).
Thanks.
Software/Hardware used:
AS400 DSPF RPGLE
Software/Hardware used:
AS400 DSPF RPGLE
ASKED:
November 5, 2012 6:24 AM
UPDATED:
November 5, 2012 1:08 PM
RELATED QUESTIONS
- DDS Keywords for AS400 Windows screens
- can I specify NS records of an AD DNS zone with non-windows dns servers
- Contention when locking an on-line VSAM file using ENQ/DEQ. All users are being locked out of entire file.
- Diplaying Records From Table In A Form Without Having To Use A Query
- Windows Scheduler fails to execute batch file.
Answer Wiki:
Am I safe to assume you are trying to write a record back to the main window like an error message? And when this write is happening all tho open windows are closing ? I would ask what is triggering this line of code you want to write and why the results would not show in the same location. If this is an error condition for the open window, why not show it in the open window on the last line of the window?
If this is not the case a little more info would be nice.
To see all answers submitted to the Answer Wiki: View Answer History.
You are more or less correct. The single line is an error msg related to a requested action from within the active window. In answer to your question, we do not display the msg in the window itself due to the size of the window. We have, in fact, found 3 possible solutions, one of which we have adopted, but we are nonetheless curious to know whether it’s possible to do what we have asked as this would have been the best solution. The first solution was to display the error msg on line 27 by using *NOMSGLIN and SFLMSG in all the window definitions (any of the cascading windows could become the active window) but, though this doesn’t erase all the windows, it locks the keyboard which contradicts our company’s standard for displaying messages, including error msgs. The second solution was to perform repeat “write” commands to all the cascading windows after writing the format on line 27 but this causes “flashing” on the screen which we also don’t want. The third solution which we have adopted is to define lines 24-27 as another window, where the top border (line 24) is defined as an underline, on line 25 are listed the various function keys available, line 26 is an error msg field and line 27 is the bottom border. The side and bottom borders are defined as blanks. Displaying this “window” does not remove all the windows and we then need only redisplay the active window.
The DDS reference says that writing non-window records will erase windows. The Application Display Programming manual implies at one point that it’s possible to have windows remain, but there are no examples. I haven’t seen any examples. Simple tests show that windows are removed.
…perform repeat “write” commands to all the cascading windows after writing the format on line 27 but this causes “flashing” on the screen…
Are you using DFRWRT(*YES)? And do you have USRRSTDSP on your window formats?
Tom
Hi Tom,
Yes we are using both DFRWRT(*YES) and USRRSTDSP. Nonetheless the cascading windows flash. Looks like we’ll remain with our “window” solution for lines 24-27.
Thanks for giving this some thought.
Zack