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