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

[Kenneth Brody]

On 10/25/2010 12:06 AM, flowersoft at compuserve.com wrote:
[...]
>> 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"???

What I meant was that you modify field 5 in automatic processing any time 
it's run on screen 9, even if you're not entering update mode and will 
simply throw out the modified value.

>  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

And what does your handling of the break key have to do with your assignment 
to field 5?

[...]
>> (+)  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

What about the "enter" key?

-- 
Kenneth Brody