I'm sure that we've all had to deal with the sort of user interface where we are working on a data aware form and only want to enable the OK/Save button when a series of conditions (other than simply required which the 4GL can happily enforce) are met. And like me you've probably written a generic validateOKRequirements: subroutine and wired it into every relevant LOSTFOCUS, CHANGED, CLICK event.

Tedious, but necessary.

Or so I thought.

Enter SAVEWARN and SYSMSG.

If you're thinking, "Oh I know about that" then please resume normal programming. If, like me, you apparently have been living under a rock for all these years then read on.

The SAVEWARN property of the Window is a "Dirty" flag. If it is true then the data on the screen has changed from how it was when it was originally loaded. This is the flag the system checks the generate the "Changes will be lost... Continue?" prompt. 

So to enable/disable our own button all we need to do it check the value of SAVEWARN and if it is true, gosub our validation, and enable/disable accordingly.

All well and good - but the thing that has evaded me all of these years, was how to actually do that. It seems the answer has been staring me in the face for years. The system already tells you when something becomes dirty and it does so through code 21 with SYSMSG.. 

The SYSMSG event is raised to a Window to allow the developer to intercept and modify/replace system responses to such situations as "Data will be lost, continue?" or "Are you sure you wish to delete?". Each of these passes the SYSMSG event a code to identify itself, such as 1 for the former and 2 for the latter.

But scan to the end of the list and there at 21 is 

 equ SYSMSG_SAVEWARNINFO$      to 21  ; // Save warn has been changed - null msg

This is triggered each time SAVEWARN changes state. So when it becomes true and when it becomes false. So now we can do away with all of our LOSTFOCUS,CLICK,CHANGE type events and instead simply have one SYSMSG event with code like the following