What is @SK

[Kenneth Brody]

(Top-posting corrected.)

On 8/15/2011 12:10 AM, Richard Kreiss wrote:
> On Aug 14, 2011, at 8:53 PM, Kenneth Brody<kenbrody at spamcop.net>  wrote:
>
>> Okay, so I guess I have to concede to George that it might not be so obvious
>> that it doesn't need explaining.  (Unless, of course, the original silence
>> was due to the fact that everyone thought it was so obvious that it didn't
>> need explaining.)  :-)
>>
>> @SK is, was, and always will be, no more, and no less, than the "special
>> key" name of the last keystroke read by filePro.
>>
>> Note that, because of this, it is true that @WLF processing will start with
>> @SK set to the keystroke that caused the field to be left.  However, @SK is
>> more than just that.
>>
> Since you have the most knowledge of how @sk should work and based on your
> last statement "that it much more then that", could you give us some concrete
> examples of what you mean?

I meant exactly what I said.

Although it is true that @WLF will start with @SK equal to the keystroke 
that caused the event to be triggered, it is, in fact, the last keystroke 
read by filePro.  If your @WLF reads input from the user, @SK will reflect 
_that_ input.  If you have a message box, or an input popup, or a popup 
update, or a waitkey, or a listbox, or whatever else you might have anywhere 
in any processing, @SK will reflect the last keystroke read from that.

Want to know if the user broke out of an INPUT POPUP, or a POPUP UPDATE? 
Check @SK.

What to know _which_ keystroke triggered @WUK?  Check @SK.

Want to take over all handling of a browse lookup?  Use PUSHKEY to force the 
browse to immediately return to processing, use WAITKEY to read the user's 
input, and check @SK.

Noticing a pattern?

Note that the lone exception to "the last keystroke read by filePro" is the 
processing debugger, which will not effect @SK, so as to not interfere with 
the processing that is being debugged.

-- 
Kenneth Brody