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

[Kenneth Brody]

On 10/22/2010 1:03 AM, flowersoft at compuserve.com wrote:
[...]
>>> screen.  The user never leaves the "browse" mode.
>> Nit: The user never _sees_ that they have left browse mode.
> If a tree fall in the forest...

The tree still fell, even if no one heard it.  :-)

>> Well, if you really need to check if the user broke out of update,
> How else am I going to take the user out of the browse screen and into
> screen 1?
>
>> this works on 4.8:
>
>> ::declare Updating(1,*,g):
>> @update::Updating = "y":
>> ::screen:
>> ::end:
>> @entsel:::
>> :Updating = "Y":Updating = "" ; mesgbox "Left update with @SK = '"&  @sk&
> "'":
>> ::end:
>
> And this :@sk="brky":mesgbox "Left update with @SK=BRKY" works from
> automatic

I never said it wouldn't.  You were the one claiming that it wouldn't work 
in input.

> Besides adding 5 more lines of code, if I use @update in this case I cannot
> use "U" to change the value of field 5.

I fail to see how you can't put this in input processing:

   If:  @sn = "9"
Then:  5 = xlate(5," y","y ")

Yes, xlate() requires 4.5 or later.  If you're still using 4.1, then you'll 
have to do this the long way.  :-)

>> However, since you're talking about breaking out of browse mode, and not
> update mode, why not just check for SK="BRKY">  in @ENTSEL?
>> @entsel:@sk = "BRKY":mesgbox "@ENTSEL reached with @SK=BRKY":
>> ::end:
> This does not work for me.  It puts me back to the index search data screen
> when I try it.

Yet putting the exact same thing at the top of automatic will show the 
message box?

> Look, I'm sure there are at least 50 different and better ways to accomplish
> what he wanted to do.
> All I'm saying is that the 7-line solution I posted after looking at his
> problem for 15 minutes, works and does not break anything as far as I can
> tell.

Yet moving the assignment to field 5 into input processing where it belongs 
would avoid any problems in the first place, and wouldn't need any code to 
"make sure the safety is on".

> Let's move on to another topic, like why sometimes it is necessary to use
> "write" in automatic processing. ;-)

Well, that's easy:  it's not(*).


(*) Assuming that we're talking about an unadorned "write", rather than a 
"write lookupname".

-- 
Kenneth Brody