Trapping an Update

[Boaz Bezborodko]

I'm sure that many of you probably already have this as a tool in your 
toolbox, but I figured I'd just share a simple way I used to trap an 
Update in a specific screen.

The core of our software was written about 20 years ago and included a 
control file that also contained pertinent daily information such as 
daily and monthly sales totals.  One screen was used to allow you to 
total up all existing open AR invoices, open AP invoices, and open 
orders.  It would do this in one screen that contained a slew of dummy 
variables.  Once we started doing a lot of business that required large 
amounts of dropship orders (each package requires its own order, 
invoice, etc.) this record started to get a lot of activity and totaling 
up these numbers in the screen could freeze other people until the 
totals were completed and unlocked.  The totaling routine looked at 
other files and didn't touch anything in the record itself.

Obviously totaling from within the record was not a good idea and I 
wanted to have this done from within @entsel which wouldn't lock the 
record.  But I didn't want to change the look and feel of the program 
which entailed that people hit "U" to start the process.  I was thinking 
of trapping "U" with an @keyU, but that meant that I would have to have 
a different line to jump to each of the other screens someone might want 
to update.

The solution was to have a @WEF for the first field in this screen's 
cursor path that looked something like this:
@wefaa     if:
                 then: DECLARE What_Mode(7,*,g)
                     if:
                 then: What_Mode="Totals" ; ESCAPE

@Entsel     if: What_Mode="Totals"
                 then: Gosub (routine) ; What_Mode="" ; GOTO @Entsel

Now the users can run this routine to their hearts content without 
interrupting anyone else.  The @Entsel and "What_Mode" trick I learned 
from John Esak.

Just in case this helps anyone else.

Boaz