Charles Hartman wrote:
I've got that incremental-search-in-a-sorted-field routine working the
way I want it (thanks to all the help from this list.) So I decided to
move it to my mainstack's script to avoid having a dozen copies in the
scripts for the scrollable fields themselves. In the mainstack script
there's an incrementalSearch handler with parameters 'theKey' for the
keystroke, 'theField' for the name of the field from which it's being
called and whose text is being searched (scrolled, selected). Each
field that wants to use the facility includes a little keyUp handler to
call it. No problem.
Try changing your handler to "keydown" rather than "keyup".
Also in the mainstack script are the script-local variables for the
seconds of the last keystroke and the accumulating string of
keystrokes. Perfect use for script-locals (since they're nonvolatile);
it works fine.
But *other* keystrokes get into the script-local variable too.
Specifically, if cmd-U has called up the substack whose field is to be
searched, then the field starts off scrolled to 'U'; a field called up
by cmd-S is scrolled to 'S'. These are keystrokes bound to menu items.
So two questions. (1) Why are they getting into the script-local
variable?? It's supposed to be accessible only from within the script.
The menus (built with MenuBuilder) are owned by card 1 of the
mainstack, but they are not referenced in any way in the mainstack
script. Is something behind the scenes violating the script-local
definition? (2) What's the best way around it? I could build a kludge
filter (maybe, though it would be easier if I knew exactly how those
keystrokes got in there), but there must be a better way.
Any advice & enlightenment much appreciated as always.
You can track what is going on by watching the Message Watcher. When the
command key is down, you get all the keyboard messages except "keydown".
So a keydown handler will trap only keys that are depressed alone.
--
Jacqueline Landman Gay | [EMAIL PROTECTED]
HyperActive Software | http://www.hyperactivesw.com
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
