The current behavior is that whoever registered the hotkey first gets it.
Given that that's not
(A) the best possible behavior in this circumstance (for example, it
might be nice if application-specific scripts got hotkeys before global
scripts) nor
(B) necessarily the most optimal way to handle the dispatching (some
sort of hashing container might turn out to have better performance
characteristics than whatever we're using now)
I think it's probably not a great idea to count on that remaining so in
the future.
Generally speaking, it's best if your script allows its hotkey
assignments to be configurable, so that the end user can choose keys
that work for them and that don't conflict with other scripts that they
use. Keep in mind that that approach has got some accessibility
arguments going for it, too: not everyone has the flexibility to hit
shift-ctrl-windows-insert-7.
Something else you might keep in mind if you're aiming for a truly
sparkling user experience from your global script is a feature akin to
the one in Progress Indicator that allows the end user to turn off your
script when certain windows or applications are active. You'd probably
want to unregister your hotkeys in such a situation (or, alternatively,
use the keyboard events instead of registered hotkeys. Just be mindful
of the caveats inherent in working with those low-level events.)
By the way, to answer the obvious next question: registered hotkeys
always take precedence over keyboard event listeners (with the same
caveats that Aaron mentioned - it's true now, but we reserve the right
to change it.) So if you want your global script to always be behind
someone else's local script that uses registered hotkeys, roll your own
hotkey processing with keyboard events. Just remember that Queue is your
friend, and you should use it liberally in any keyboard-event-based scheme.
On 9/1/2010 2:16 PM, Chip Orange wrote:
Aaron (or anyone),
I'm just curious, if you try to define a hotkey which is already
defined by another script, will it throw an error? if not, which
script will take precedence (the last, the one which is application
specific, any rules)?
thanks.
Chip
------------------------------------------------------------------------
*From:* Aaron Smith [mailto:[email protected]]
*Sent:* Wednesday, September 01, 2010 11:15 AM
*To:* [email protected]
*Subject:* Re: precedence of set file and script hotkeys
On 9/1/2010 10:12 AM, Cory Samaha wrote:
If I want to ship a script package, is it safe to assume that script hotkeys
will
always take precedence over set file hotkeys, or is it a better idea to ship
a set file with the script which will undefined these hotkeys?
For Window-Eyes 7.X (and probably 8.0), you're guaranteed that script
hot keys will take precedence over set file hot keys. That probably
won't change in future versions, but it could if we come up with a
good reason. So we don't want to commit to this always being the case
forever. But it is the case for now.
Aaron
--
Aaron Smith
Product Support Specialist * Web Development
GW Micro, Inc. * 725 Airport North Office Park, Fort Wayne, IN 46825
260-489-3671 * gwmicro.com
To insure that you receive proper support, please include all past
correspondence (where applicable), and any relevant information
pertinent to your situation when submitting a problem report to the GW
Micro Technical Support Team.
