New filePro quiz

Jay Ashworth jra at baylink.com
Sat Aug 13 15:19:23 PDT 2011


> [quoting me, and I am *not* going to reindent all of this, please
get a mail user agent that at least knows how to quote...

> [ back on-list ]
> 
> ----- Original Message -----
> > From: "Kenneth Brody" <kenbrody at spamcop.net>
> > To: "Jay Ashworth" <jra at baylink.com>
> 
> > On 8/12/2011 3:14 PM, Jay Ashworth wrote:
> > [...]
> > >>> Q) What is @SK?
> > [...]
> > > So far as I know, the answer is "SK is a system field which
> > > contains a
> > > text label of the keyboard key used to exit the last field which
> > > was
> > > exited".
> >
> > Just curious as to where you came up with that definition, as it is
> > not
> > correct. (At least, not in the general sense. At the start of @WLF,
> > it
> > will fit that description, however.)
> 
> This is every word the online manual has to say about @SK:
> 
> """
> Special key can be used with INKEY, but avoid INKEY, it is CPU
> intensive, use WAITKEY instead.
> 
> "@sk" is used with when-processing. When-processing fills this field
> with the special key-label of the key last pressed.
> 
> Browse lookups will also pass SAVE, BRKY and ENTR to @sk if users
> press any of these 3 keys while the highlighted bar is visible.
> """
> 
> That seems pretty compatible with what I asserted, especially when you
> combine it with my followup:
> 
> > > I expect it to be valid at the top of input processing and in a
> > > WLF
> block;
> > > I don't expect it to be defined anywhere else, though it might
> > > still
> contain
> > > a value set somewhere else. In particular, I don't expect it to be
> > > valid
> > > in a WEF block.
> 
> On reading it -- and it's *miserably* badly written, BTW -- I have to
> assume that the distinction you're looking for is that it is *not*, in
> fact,
> guaranteed to be valid at the top of input processing, after a SAVE.

And 'flowersoft', whose name eludes me for the moment, and which *is not*
in his email message anywhere (yes, I did go look), replies:

> No, it is guaranteed to be TRUE at the top of input processing after a save.
> Line #1 is always TRUE if the user hits Esc or Esc Esc to leave a field.

The manual quote rather explicitly says the opposite; you have a citation
for that?  Cause if that's true, then *everything* I said as a reply was
accurate, and Ken tells me it's not.

Cheers,
-- jra
-- 
Jay R. Ashworth                  Baylink                       jra at baylink.com
Designer                     The Things I Think                       RFC 2100
Ashworth & Associates     http://baylink.pitas.com         2000 Land Rover DII
St Petersburg FL USA      http://photo.imageinc.us             +1 727 647 1274


More information about the Filepro-list mailing list