when field processing

[Kenneth Brody]

John Esak wrote:

A very good explanation, though I do have a couple of quibbles...

[...]
> So, just retrieving the
> record and pressing "U" to update it, you've run it through automatic twice
> and @entsel twice... 

While automatic will be run twice (once when the record is initially read
and displayed, and again when it is re-read to enter update mode), @ENTSEL
will only be run once, when the record is displayed.  It won't be run again
upon pressing "U" to enter update.

[...]
> Why? Simple... the record is not "locked" by AUTOMATIC processing,

Actually, when re-running automatic entering update mode, the record is
locked during automatic.  However, there is no guarantee that you are
entering update mode when automatic is run, so it is best to assume that
the record is not locked.  (And, if you want something done with the
record when entering update mode, just use @KEY or @UPDATE.)

[... discussion about events and input processing, with lots of examples ...]

Sometimes, the simplest explanation really is the best.  (Though examples
never hurt.)

When saving a screen, filePro will start input processing at line 1, if
and only if processing is not already running.  If processing was running,
it will continue from the point following the SCREEN command which caused
you to update the screen.

Think of it like this:

    If you don't have an explicit @UPDATE event, filePro will behave in
    the same manner as if a line zero existed as follows:

      @UPDATE
          If:
        Then:  SCREEN

In this way, there is no need to think of line 1 as being "magical".

-- 
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody        | www.hvcomputer.com |                             |
| kenbrody/at\spamcop.net | www.fptech.com     | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+