I was able to associate the set file with the nulled out keypad keys to the class of the app's main document window. A second set file isn't associated based on the window class, and so WE switches to that when in the app's dialogs.
This works pretty well. The keypad is ignored in the main window, but still is available in dialogs. Thanks everyone. I have a lot of programming experience, and have read the WE manual and scripting manual. However, I'm coming from a long history of Jaws and Jaws scripting, and WE is very differently structured. Bryan -----Original Message----- From: Jim Grimsby JR. [mailto:jgrim...@roadrunner.com] Sent: Tuesday, September 29, 2009 10:51 AM To: gw-scripting@gwmicro.com Subject: RE: Automatically by-passing WE hotkeys No because the we file uses the window to load set files. For example let's take gold wave. When you are in the main window it uses one set file but when you switch to the control window another file is used etc. if that doesn't work a hyper active window could be created to check to see what window is active and load a set file based on the information provided. Hth Jim Grimsby Junior. Please feel free to contact me at anytime using one of the below methods. Skype: Jim.Grimsby 909-498-4711. E-mail: jgrim...@roadrunner.com Windows live messenger: jim.grim...@att.net -----Original Message----- From: Chip Orange [mailto:lists3...@comcast.net] Sent: Tuesday, September 29, 2009 5:38 AM To: gw-scripting@gwmicro.com Subject: RE: Automatically by-passing WE hotkeys Brian, I don't see how the .set file suggestion could easily be made to work, since you only want these keys to be intercepted, or to work normally, based on where the user is, in the application, at the moment. maybe it's easier than it sounds to me, but that sounds like you'd be loading and unloading set files on the fly to do this? anyway, an alternative is to use event handlers for the key's up and down events, and connect them or not based on where the user is. I do this in one of my scripts, and in the event handler, you can decide if the key should be passed to the app, bypassing window eyes altogether (which is what I needed to do). anyway, here's an example of what I mean for setting up the handler for a key, which I'm sure you could specify as a numeric keypad key: ' trap up/down arrow keys with ... set DownArrow = keyboard.key("down arrow") if downArrow is nothing then speak "failed to get down arrow" else ' now can trap the key down and up events for the arrows to prevent window eyes from speaking anything; otherwise, WE will repeat the line of code. ' ' down arrow downArrowEvent1 = ConnectEvent ( downArrow, "onKeyDown", "downArrowOnKeyDown") downArrowEvent2 = connectEvent ( downArrow, "onKeyUp", "downArrowOnKeyUp") end if ' downArrow is nothing ' hth, Chip -----Original Message----- From: Bryan Smart [mailto:bryansm...@bryansmart.com] Sent: Monday, September 28, 2009 12:01 PM To: gw-scripting@gwmicro.com Subject: Automatically by-passing WE hotkeys I'm scripting for an application that requires the use of the keypad in its main window. The app expects to receive keys such as home, end, page up, page down, and the arrows when the keypad keys are pressed. I can voice everything in the main window, so not being able to use the WE cursor there isn't a big loss. However, I'd like the WE cursor to be available in this app's dialogs and other parts of the user interface. What is the best way for me to temporarily suspend just the keypad hotkeys? I can use a ConnectEvent call to watch for an Activate event in the overlap area to detect when the foreground window has changed, and I can evaluate if I'm now in the main window or not. However, the only way to fix the keypad keys seems to be to unregister all of those WE hotkeys when the main app window gains focus, and then to reregister them when the main window loses focus. This can't be the best way, though, as, when I reregister the hotkeys, I can only register them back to what I think they should be, and, I believe, the user can redefine these. I'll have, therefore, potentially messed up the user's default assignments. Any suggestions are welcome. Bryan
