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

[Kenneth Brody]

On 10/18/2010 3:51 PM, flowersoft at compuserve.com wrote:
>> So, the code that was posted here which toggled the value of field 5 if
> you
>> are on screen 9 would cause the user to see the exact wrong value when
>> viewing the record via screen 9.  (ie: if the field were blank, you would
>> see "Y", and if the field had "Y", you would see blank.)
>
> I beg to differ.  You cannot view the record via screen 9 because there are
> no fields on screen 9 to view and therefore there is no way for a user to
> switch from let's say screen 1 to screen 9.

What stops them from pressing "9"?  I suppose you could use "@key9 / end" if 
you insist on this plan of attack.

Okay, so you get around the fact that the screen would show data different 
from the real data by simply not showing the mismatch.

> You are going into the file via a browse format, so automatic processing
> does not even run on the first record at that point.

Correct.

> The only way to get automatic processing to run from the browse format is to
> hit "U", which then changes the value of field 5 and displays it on the
> browse screen immediately.

I guess I missed the part of the processing that puts you back into browse mode.

> Or to hit<Enter>, which programmatically does
> change the value of field 5, but in reality does not change it because it
> never gets written to disk.

And you're left looking at a blank screen 9.

> At no point will the user see the incorrect value for field 5.  Not while
> viewing the browse screen and not even when viewing the record from screen 1
> or any other screen for that matter.

If your plan is to take the user into update mode, immediately come out of 
update mode, and take you back to browse, then why do you insist on 
modifying the real field in automatic processing, rather than input 
processing where it belongs?

-- 
Kenneth Brody