Hi Tom,
In honor of your clarity and helpfulness, and now that I've thought over
this thread myself for the past day or so, I recall that I solved the
problem Dave is having in my EggTimer app which I wrote for myself.
I wanted to start my egg timer, but I didn't want to accidentally turn it
off, and so I used this code to force me to do a double key press within one
second to stop the egg timer once it was started:
'Set up the TimeoutCheck hotkey.
Dim myHotkey : Set myHotkey = Keyboard.RegisterHotkey("Shift-F12",
"TimeoutCheck")
sub TimeoutCheck()
'Rodmark
'This routine fires StartStopEggTimer Routine
'but only if TimeoutCheck hot key pressed twice within one Second
'otherwise, timout occurs and KeyTimerRanOut is called
'which speaks the EggTimer elapsed time
Timeout = 0
If keyTimer > 0 Or globalTimer = 0 Then
stopTimer keyTimer
keyTimer = 0
StartStopEggTimer
End If 'keyTimer > 0
stopTimer keyTimer
keyTimer = 0
keyTimer = startTimer(1000, "KeyTimerRanOut")
End sub 'TimeoutCheck()
Sub keyTimerRanOut()
'Rodmark
stopTimer keyTimer
keyTimer = 0
Timeout = 1
'Next line speaks elapsed time
'Note that this only traps the TimeoutCheck hot key
If Not EggCount + 1 = EggStart And globalTimer > 1 Then SpeakEggTimerElapsed
End Sub 'KeyTimerRanOut()
Hth,
Rod
-----Original Message-----
From: Scripting
[mailto:[email protected]] On
Behalf Of Tom Kingston via Scripting
Sent: Friday, June 05, 2015 5:34 PM
To: David; Window-Eyes Scripting List
Subject: Re: Double Hotkey, and Hotkey Manager
I have been following this thread, somewhat. But it's been going in too
many directions for me to ponder at the moment. But after reading this
one I just wanted to toss in the fact that hot keys defined in a script
override those in Window-Eyes. So you can use obscure hot keys (or
whatever you want) in your script without having to think about the
default hot keys.
Here's a quick test done in the Immediate mode window to demonstrate
what I mean.
Sub HiDave() : Speak "Hi Dave" : End Sub
Set oKey = Keyboard.RegisterHotkey("Insert-T", "HiDave")
' Go roam around and hit Insert-T.
' Now unregister it.
oKey.Unregister
' Presto! Time and date has been resurrected.
Hth,
Tom
On 6/5/2015 4:22 PM, David via Scripting wrote:
> Although I can see where you are coming from, when saying there should
> be differences between the right- and left-window key, and similar
> differences between the two insert-keys on a keyboard - I don't know if
> that really will fix much of the issue. At least not all way through.
> Too many keyboards now aday comes with limited layout. On many laptops,
> you only will have one insert-key, only one win-key, and maybe not even
> an AltGR key. With these hardware limitations, you soon enough will be
> back to the same state as now, that it only gives one combo on each key.
>
> Shift-Insert problem? Yes, and that really does take away a line of
> hotkey combinations. So that one should definitely be fixed.
>
> And to you Chip:
> It is a good idea to use the App-menu, long as your app is more of a
> standalone feature. Worse it becomes, if your app is performing things
> that would rely directly to a certain window, or application, since you
> then cannot swap over to the app-menu, as the underlaying application
> then will loose focus. Or, in the event your app is performing a more
> trivial functionality. Not sure, for instance, if users would welcome to
> have to go through the app menu, every time they want to check the time
> of the day, or the battery-level of their laptop, or any other
> frequently used feature.
>
> Guess it all cooks down to the fact, that apps have become so multiple,
> and many of them have to base their activity on hotkeys. Or, at least,
> the developer and/or the user, expects it to base everything on
> hotkeys.Of course, a good rule-of-the-thumb would be:
> If a feature does not have a direct link to something on the
> screen, or if it is not meant for frequent usage, put it on the app menu.
> Easy for us as developers to tel, but users may have another feeling
> about it all. After all, forget about the apps for one second, and
> number the Built-In hotkeys of the screen reader itself. Basically, to
> me, 20% of them could easily have been removed, and freed up space for
> app-related hotkeys. Yet, I do realize, that is my view, and likely
> there is a reason for why they are there. And that is one of the
> delemmas I as a developper often find myself in. I could have put most -
> if not all - features on the app-menu. Still, not all users want to swap
> windows everytime they need a given small task done. So, what is left
> for me to do? Smile.
>
>
> David
>
> On 6/5/2015 9:57 PM, Jim Grimsby JR. via Scripting wrote:
>> This is why window-eyes needs to do a better job working with
>> prefixes. For
>> example the numpad insert should be a prefix as well as the standard
>> insert
>> and the caps lock and left and right windows. More prefixes gives users
>> more alternatives. Not only this but one shot commands. For example for
>> hot spots caps h then control a for add hot spot and control m for
>> manage
>> hot spots. Tab could be used to move threw the keyboard command to learn
>> the command or just find the one you want quickly. Once the command is
>> performed the command is exacuted and then you are returned to normal
>> functionality.
>> Window-eyes commands should be moved over to the numpad when ever
>> possible
>> to free up command space on the keyboard and to avoid conflicts with
>> normal
>> aplacation use. this is why the problem of shift insert need to be
>> fixed.
>> Double clicking of keys should also be supported. This is nothing new
>> chip
>> you may remember that many of these ideas were used in window bridge
>> 2000.
>> Another good idea is to be able to define the order in witch prefixes are
>> pressed. For example if you press shift control the program gets the
>> function where if you press control shift the window-eyes gets it.
>> Another
>> option would be that if you press the order in one way one thing
>> happens if
>> you press it in another something else happens.
>> Window-eyes should also allow for apps to add functionality to the
>> window-eyes user interface. Defining hot keys for apps should be done the
>> same way you do it for the internal command for window-eyes it self.
>> Verces
>> going in to a manager for each app. Thing like controlling progress bars
>> auto complete should be done from verbosity. This has always been a
>> weekness of window-eyes apps they don't feel like the program it
>> self. They
>> feel and look like external programs verces adding functionality to the
>> screen reader it self. I mean they do clearly add the functionality
>> but it
>> doesn't feel like you are working with the same program. For example you
>> work with ms word that feels like a part of window-eyes where if you
>> want to
>> do something with skype app you have to work with an external program.
>>
>>
>>
>> -----Original Message-----
>> From: Scripting
>> [mailto:[email protected]]
>> On
>> Behalf Of Chip Orange via Scripting
>> Sent: Friday, June 05, 2015 11:36 AM
>> To: David; Window-Eyes Scripting List
>> Subject: RE: Double Hotkey, and Hotkey Manager
>>
>> I know what you're saying David (I think) ... we're being swamped by too
>> many hotkeys for too many apps, it's hard to come up with unique ones,
>> and
>> with meaningful combinations which can easily be remembered.
>>
>> In my most recent app, I've tried to encourage the user away from hotkeys
>> and to try choosing app menu choices for those functions which aren't
>> obviously tied to whatever window and/or control the user is interacting
>> with. I've still defined hotkeys for all of my app menu choices, but
>> I am
>> counting on the user to decide what they should be if they really would
>> rather use hotkeys; I simply picked out a group I thought wasn't being
>> used
>> yet. I can no longer guess what combination will be meaningful, as
>> they all
>> it seems are already in use. My documentation suggests that they
>> undefine
>> the hotkeys which they aren't using, in order to prevent conflict.
>>
>> One other choice we have is a hotkey which brings up a primary window for
>> our app, which contains all of its functions as menus, buttons, whatever
>> (very similar to the WE main window). This lets the user only have to
>> remember one primary hotkey, and then all the others will only be active
>> hotkeys or shortcuts when the main window for your app is active.
>>
>> I think we'll have to all start to use the app menu choices or the main
>> control window in the future when we want to give users global access
>> to our
>> apps; it's just getting too crowded for every app to have its own
>> collection
>> of global hotkeys. Hotkeys which are program-specific however, they
>> shouldn't be as much of a problem; there's at least room for overlap.
>> It will still be difficult for the user to remember however that perhaps
>> control-shift-A does one thing in Outlook, and does another for the
>> app for
>> GoldWave for instance.
>>
>> Chip
>>
>>
>>
>>
>> Chip Orange
>> Florida Public Service Commission
>> Computer Systems Analyst
>> 850-413-6314
>>
>>
>> -----Original Message-----
>> From: Scripting
>> [mailto:[email protected]]
>> On
>> Behalf Of David via Scripting
>> Sent: Friday, June 05, 2015 12:45 PM
>> To: GWScripting
>> Subject: Re: Double Hotkey, and Hotkey Manager
>>
>> OK. Wish there was a chance for a user to define double-keys for any
>> feature
>> in the hotkey manager. As more and more apps become available, and a user
>> may want to have his apps intuitive, even when comes to hotkeys,
>> double-keys
>> will be a miss.
>>
>> Let me give you but one more example, in addition to the one Chip gave.
>> Say you want one hotkey for the Time, and another for Date. Other screen
>> readers have features split that way. It is no trouble in hard-coding
>> this
>> in Win-Eyes either. Yet, should the user want to redefine to a more
>> convenient hotkey - for him - it is impossible, the way things stands
>> today.
>> Or, what about an app that would perform a limited action when the
>> hotkey is
>> pressed once, but a more advanced version of the job when the hotkey is
>> doubled. To a user with several apps, it would be far more
>> comprehenble, if
>> the hotkeys could be grouped,according to somehow similar operation. And
>> with the hotkey manager in place, it really should have been possible
>> for an
>> app to have double-hotkeys, and let the user redefine them as he wanted.
>> Whether he wanted another double-hotkey, or even if he wanted an existing
>> double to be split into two totally separate single-hotkeys.
>>
>> Something for the developing team to put on the wishlist?
>>
>>
>> David
>>
>> On 6/4/2015 12:49 AM, Chip Orange wrote:
>>> Hi David,
>>>
>>> As I understood it, A I never meant for you to be able to define a
>>> single hotkey as being a double press of a certain key. That is,
>>> their only intent was that you could add additional functionality to
>>> your basic hotkey by allowing the user to press it twice (so, one
>>> press reads something, then two might spell it instead of reading it).
>>> Their intent however was that the spell function in this example, was
>>> always designed to be the second press of the basic hotkey. So, if
>>> the user changed the basic hotkey, then it should be made clear in the
>>> documentation that this secondary function would just be a second
>> immediate press of whatever this key was.
>>> If you have in mind two unrelated functions, which you may want the
>>> user to be able to assign to two unrelated hotkeys, then I think you
>>> cannot use the second press feature for either of them (or the user
>>> cannot); this can only be something you program in, and make clear in
>>> your docs, if you want the second press of a hotkey to do something.
>>>
>>> It may not be what you want, but I hope this at least clears it up a
>>> bit.
>>>
>>> Chip
>>>
>>>
>>> -----Original Message-----
>>> From: Scripting
>>> [mailto:[email protected]]
>>> On Behalf Of David via Scripting
>>> Sent: Wednesday, June 03, 2015 6:05 PM
>>> To: GWScripting
>>> Subject: Double Hotkey, and Hotkey Manager
>>>
>>> Listers,
>>> Sorry for the wrong term, but my memory fails me, as to the correct
>>> term. I am wondering if there has been any further develop on a lack I
>>> found earlier.
>>>
>>> Say your app has a hotkey that needs to be pressed twice within a
>>> second or so - Like Alt-F12, Alt-F12 - to perform a certain task. Last
>>> time I attempted to incoporate such a hotkey in my project, I found
>>> that it did not work well with the hotkey manager. You can make this
>>> work first hand, when releasing the app. But if the user wants to
>>> redefine the hotkey - say to Ctrl-F12, the hotkey manager will
>>> redefine it to only a SINGLE press of the hotkey - meaning that the
>>> app will react upon the first press of the hotkey.
>>>
>>> Thing is, I have an app here, where I want function1 to take place
>>> when the hotkey is pressed once, and only once. Function2 should kick
>>> in, when the user double-press the same key-combination. Hope this
>>> makes sense. But how can I work this out, so that the user can
>>> redefine to any other key-combo, even if he wants a
>>> Single-/Double-version of another key-combo. Like in the example above.
>>>
>>> Sorry for a messy message, but hope I came through clear enough that
>>> someone could please let me know, if there is any workaround here. Or,
>>> is this not possible to achieve the way things stands as of current?
>>>
>> _______________________________________________
>> Any views or opinions presented in this email are solely those of the
>> author
>> and do not necessarily represent those of Ai Squared.
>>
>> For membership options, visit
>>
http://lists.window-eyes.com/options.cgi/scripting-window-eyes.com/corange%4
>>
>> 0psc.state.fl.us.
>> For subscription options, visit
>> http://lists.window-eyes.com/listinfo.cgi/scripting-window-eyes.com
>> List archives can be found at
>> http://lists.window-eyes.com/private.cgi/scripting-window-eyes.com
>> _______________________________________________
>> Any views or opinions presented in this email are solely those of the
>> author
>> and do not necessarily represent those of Ai Squared.
>>
>> For membership options, visit
>>
http://lists.window-eyes.com/options.cgi/scripting-window-eyes.com/jgrimsby%
>>
>> 40roadrunner.com.
>> For subscription options, visit
>> http://lists.window-eyes.com/listinfo.cgi/scripting-window-eyes.com
>> List archives can be found at
>> http://lists.window-eyes.com/private.cgi/scripting-window-eyes.com
>>
>> _______________________________________________
>> Any views or opinions presented in this email are solely those of the
>> author and do not necessarily represent those of Ai Squared.
>>
>> For membership options, visit
>>
http://lists.window-eyes.com/options.cgi/scripting-window-eyes.com/trailerda
vid%40hotmail.com.
>>
>> For subscription options, visit
>> http://lists.window-eyes.com/listinfo.cgi/scripting-window-eyes.com
>> List archives can be found at
>> http://lists.window-eyes.com/private.cgi/scripting-window-eyes.com
>>
>>
>
> _______________________________________________
> Any views or opinions presented in this email are solely those of the
> author and do not necessarily represent those of Ai Squared.
>
> For membership options, visit
>
http://lists.window-eyes.com/options.cgi/scripting-window-eyes.com/tom.kings
ton%40charter.net.
>
> For subscription options, visit
> http://lists.window-eyes.com/listinfo.cgi/scripting-window-eyes.com
> List archives can be found at
> http://lists.window-eyes.com/private.cgi/scripting-window-eyes.com
>
_______________________________________________
Any views or opinions presented in this email are solely those of the author
and do not necessarily represent those of Ai Squared.
For membership options, visit
http://lists.window-eyes.com/options.cgi/scripting-window-eyes.com/rod_hutto
n%40hotmail.com.
For subscription options, visit
http://lists.window-eyes.com/listinfo.cgi/scripting-window-eyes.com
List archives can be found at
http://lists.window-eyes.com/private.cgi/scripting-window-eyes.com
_______________________________________________
Any views or opinions presented in this email are solely those of the author
and do not necessarily represent those of Ai Squared.
For membership options, visit
http://lists.window-eyes.com/options.cgi/scripting-window-eyes.com/archive%40mail-archive.com.
For subscription options, visit
http://lists.window-eyes.com/listinfo.cgi/scripting-window-eyes.com
List archives can be found at
http://lists.window-eyes.com/private.cgi/scripting-window-eyes.com
