Why is this record being saved? -- A simple test

[filepro list]

> -----Original Message-----
> From: filepro-list-bounces at lists.celestial.com 
> [mailto:filepro-list-bounces at lists.celestial.com] On Behalf 
> Of Barry Wiseman
> Sent: Wednesday, 22 March 2006 5:15 AM
> To: filePro list
> Subject: Re: Why is this record being saved? -- A simple test
> 
> OK, this is bugging me now.  Please try this at home, kids:

snip

> 
> Input processing:
> 
> 	::end:
> 	@KEYT::popup update -,"1":
> 	:@sk eq "BRKY":clearp; end:
> 	::write; end:
> 	@WLF2::3="Updated"; display; end:
> 

Snip

> It appears the record is being rewritten on the fly at the 
> moment the @WLF code 
> writes data to a field!  Note that this is not the behavior 
> with data entered on the 
> popup screen from the keyboard (see test 1).
> 
> I can only say, HUH???
> 
> Is this because filePro knows the record I'm standing on is 
> the same record I'm POPUP 
> UPDATE'ing, and is taking steps behind the curtains to try 
> and keep everything in 
> sync?  But no update is ever requested, either for the record 
> clerk is standing on or 
> for the image of it in the POPUP UPDATE.  Grrrrr.
> 
> Linux dclerk 5.0.14D4.
> 

@key processing is another entry point to update a record, regardless of if
you actually change any values in the current record eg you do a lookup and
update another file.  Even if you don't change anything, the system
maintained fields @ub/@ud will show the record has been updated, which it
has, just not by pressing U to update.  When the end is encountered the
record is written away.

Solution:

If @sk eq "BRKY"
Then clearp; pushkey "[BRKY]"; screen 1; end

Note:  the screen command allows filepro to act on the pushkeyed break in
the buffer as if the user cancelled out of an update session.  Whichever
screen is used MUST contain an updatable field!!!

Shane