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

[Kenneth Brody]

On 10/18/2010 6:08 PM, flowersoft at compuserve.com wrote:
> The user cannot get to screen 9 because @entsel does a pushkey "b" if @sn="9",  No @key9 needed. You are never left looking at a blank screen 9.  Besides, if that would ever be a problem, we could call the screen "nine" instead of 9.

Again, your "solution" to the problem is to simply not show the field, 
rather than avoid the problem in the first place.

>> 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?
>
> I guess you can put it at the top of the input table, but that could interfere with normal input processing.

It will "interfere with normal input processing" a lot less than modifying 
real fields in automatic processing interferes with things.  In fact, how 
will it "interfere" at all?

> For example, the line
> 3  -------   -   -   -   -   -   -   -   -   -
>        ◄ If: @sk="brky" and @sn="1"
>        Then: switchto 9; pushkey "b"; end
>
> Might cause a problem when in input processing if the user breaks out of the record.
>
> I thought it might be a lot simpler to have it in its own "myauto" processing table.

Actually, it would be simpler to not modify the real field in automatic 
processing, and use input processing instead.

-- 
Kenneth Brody