Re: scope puzzle with menus
On Nov 16, 2005, at 1:39 AM, J. Landman Gay wrote: Well, if you open the message watcher and then press and release a key you'll see something like this: rawKeyDown keyDown rawKeyUp keyUp Each of those is a different system message and each carries as a parameter the key you have pressed and/or released. If you hold down the Command key while doing the same thing, you only get these messages: rawKeyDown rawKeyUp keyUp There is no keydown message sent when the Command key is down. You can take advantage of that to trap only plain keypresses. Let's say you've pressed Cmd-U. The reason the key is included in your script local when using a keyUp handler is because Rev is sending both rawKeyUp-U and keyUp-U. The menus act on the rawKeyDown/Up messages, but that's only half the set; your script is trapping the keyUp and storing the U. It is natural to think of a keypress as a single up or down event, but it's really two sets. No no, thank you, but I understand that (though I didn't know about the command key exception, which is a very handy fact). My question isn't about the keypresses or the messages, but about the variable. Scripture saith: The difference between a script local variable and a global variable is that a script local variable can only be used in the handlers of one script . . . I've always extrapolated that to mean that the value of a s.l.v. can be changed only by a handler within the script that declares the variable. But in this case it's being changed by something from outside the handler, isn't it? A keyUp message whose parameter is cmd-U is generated when I choose a menu item whose purpose is to open a substack. So it's generated before I have even opened the substack containing the card containing the field whose script contains the keyUp handler. That handler then calls a handler in the main stack, which reads and writes a variable there in the main stack script. So why does that cmd-U (or the 'u' part of it) end up in that variable? Charles Hartman ___ 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
Re: scope puzzle with menus
Charles Hartman wrote: A keyUp message whose parameter is cmd-U is generated when I choose a menu item whose purpose is to open a substack. So it's generated before I have even opened the substack containing the card containing the field whose script contains the keyUp handler. That handler then calls a handler in the main stack, which reads and writes a variable there in the main stack script. So why does that cmd-U (or the 'u' part of it) end up in that variable? I see. I didn't realize the keyUps were in an unopened substack. You'd need to do some investigating but it could be that after the command key triggers the menu item and opens the substack, the next keyUp message in the queue is then sent to the new top stack, which would be your substack. -- 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
Re: scope puzzle with menus
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
Re: scope puzzle with menus
Jacque, I would not have thought of that in 127 days. Thank you! (I'm still a little puzzled. I still don't see why my script local variable is getting tampered with by something outside the script at all. I fear I'm missing a General Concept here.) Charles Hartman On Nov 15, 2005, at 10:40 PM, J. Landman Gay wrote: 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 ___ 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
Re: scope puzzle with menus
Charles Hartman wrote: Jacque, I would not have thought of that in 127 days. Thank you! (I'm still a little puzzled. I still don't see why my script local variable is getting tampered with by something outside the script at all. I fear I'm missing a General Concept here.) Well, if you open the message watcher and then press and release a key you'll see something like this: rawKeyDown keyDown rawKeyUp keyUp Each of those is a different system message and each carries as a parameter the key you have pressed and/or released. If you hold down the Command key while doing the same thing, you only get these messages: rawKeyDown rawKeyUp keyUp There is no keydown message sent when the Command key is down. You can take advantage of that to trap only plain keypresses. Let's say you've pressed Cmd-U. The reason the key is included in your script local when using a keyUp handler is because Rev is sending both rawKeyUp-U and keyUp-U. The menus act on the rawKeyDown/Up messages, but that's only half the set; your script is trapping the keyUp and storing the U. It is natural to think of a keypress as a single up or down event, but it's really two sets. -- 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
