Modifying real fields in automatic (was Re: Some Sort of ControlFrom The Browse Screen)

[flowersoft at compuserve.com]

> Well, to be fair, as I said earlier in this thread, the modifying of a
real field in automatic is not going to cause >data or index corruption(*)
because filePro won't write the modified data!  But, the user will still
see(+) a mismatch > between what's on the screen and what's in the record.

When will the mismatch take place?  Automatic does not run unless the user
clearing the checks presses "U" or hits <Enter>.  The only user that will
see field 5 change is the one clearing the checks. The other users, even if
field 5 was visible on screen 1, would not see field 5 change because a) It
does not change unless @sn="nine" and b) supposedly -y myauto would not be
running from normal processing.

Even if 2 or more users were clearing the records at the same time, the only
thing they would ever see is the browse screen unless they hit "break", in
which case they would be looking at screen 1.  Field 5 does not change
unless @sn="nine", so no change takes place then either.

> However, given that you don't even care about the modified value, and
you're only doing it "just in case" the user has > pressed 'U', why don't
you put it in input processing where it belongs?

I'm not quite sure I understand this sentence.  What do you mean by "you
don't even care about the modified value" and "You're only doing it just in
case the user has pressed 'U"???  but in any case...
As I said previously, I did not put the code in input processing because
a) I did not think (you and John showed me otherwise) thet I could trap the
"break" key from input, so the line
  If: @sk eq "brky" and @sn="nine"
Then: switchto 1; end
would not have executed. And
b) I was afraid that if a regular user working from screen 1, could hit
"break" to get out of a record and be thrown into the browse mode.  Remember
that another line in the code read:
  If: @sk="brky" and @sn="1"
Then: switchto "nine"; pushkey "b"; end

However, I've since realized that that line would have evaluated as "false"
from input processing anyhow.

Those were my reasons for putting the code in automatic processing.

> (*)  Assuming you don't then have processing that, for example, uses the 
> modified value and stores it someplace else, like a lookup file.
There is no need for a 'write' here since we are updating the record.

> (+)  Unless you make sure to never let the user know about the mismatch.
I don't think there will ever be a mismatch since automatic doesn't run from
the browse screen and the user pressing 'U' never "sees" anything but the
browse screen unless he/she hits break and then they are looking at screen
1.  Other users don't have access to screen "nine" and are not running -y
myauto