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

[John Esak]

I'll correct you if you're wrong.  You are. And, no it's not a 5.6 feature.
The very simple answer to capturing BREAK on INPUT is to use a POPUP UPDATE
instead of a screen. I do it all the time... For this very reason.

John
 

> -----Original Message-----
> From: filepro-list-bounces+john=valar.com at lists.celestial.com 
> [mailto:filepro-list-bounces+john=valar.com at lists.celestial.co
> m] On Behalf Of flowersoft at compuserve.com
> Sent: Thursday, October 21, 2010 1:34 PM
> To: 'Kenneth Brody'
> Cc: filepro-list at lists.celestial.com
> Subject: RE: Modifying real fields in automatic (was Re: Some 
> Sort of ControlFrom The Browse Screen)
> 
> > And putting it in automatic won't affect other users?
> 
> No, unless he adds the -y myauto to other menu options.
> 
> > You still haven't given any reason why you can't put it in 
> input, where it
> 
> > belongs, rather than automatic.
> 
> Yes I did, I said I wanted to avoid having to code for
>   If: @sk="bkry"
> Then: switchto 1; goto JUMP1
> When a user other than the one clearing the items was 
> updating the record.
> 
> >> Since you can only detect @sk="brky" from automatic when 
> not at an input
> >> statement,
> 
> > Huh?
> 
> You can?  If I'm updating a record and hit <ctrl+c> or 
> <del><del> you can
> capture that keystroke from input processing?
> Is that a new feature in 5.6?  Because it certainly does not 
> work on my
> version unless you are at an input statement.
> 
> > I don't follow.  What, exactly, do you want to do if the 
> user presses
> Break 
> > that you "can't do" if the assignment to field 5 is in input?
> 
> The menu line puts the user in a "browse" mode from where 
> he/she can press
> "U" to change the value of field 5, which immediately 
> displays on the browse
> screen.  The user never leaves the "browse" mode.  But, if 
> the user wanted
> to make a change to the record, other than changing the value 
> of field 5, I
> was allowing them to hit "break" from the browse screen and 
> that would put
> them on screen 1 from where they could modify the record just 
> like if they
> were outside of this special program.  The only way (that I 
> know) to trap
> the "break" key when not in an input statement is from 
> automatic processing.
> Please correct me if I'm wrong.
> 
> > Actually, I think it's more like saying "don't point a 
> loaded gun at a 
> > person, even if you don't plan on pulling the trigger".
> 
> Exactly.  And my argument is that in this case, the gun is 
> not loaded and
> has the safety on.
> 
> > I think you loaded the gun and the safety is off, and 
> you're hoping that
> no 
> > one drops it.
> 
> On the contrary, I made sure the gun wasn't loaded and the 
> safety was on.
> I bet you can't find a way to fire the gun. :-)
> 
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> Subscribe/Unsubscribe/Subscription Changes
> http://mailman.celestial.com/mailman/listinfo/filepro-list