AutoHotkey Community

F10 in Windows = "Goes to the menu mode"

Can you change it in DNS? (I use a SR prog which as default used ` key, which was a pain as scripting in ahk uses that, so i changed it to #!` (ctrl-alt-`)

Having "IfWinNotActive,..." before "ImageSearch" means if you stay in PDF-XChange for a time, your mic-correcting script won't be working
Instead, use ControlSend

So if in PDF-XChange (or any other program/window) wont Send F10 to it, but only to DNS

PS: Current (set up by DNS)...

Thanks for the hint regarding ControlSend! I'll try that.

Actually, the PDFXChange issue is not that much of a problem anymore (since now there's already two ways how to get around it) -- rather, the main problem now is the one that had been dicussed in the more recent posts, regarding the question how to reliably find out (or better: how to reliably control) that dogged red/green microphone state (off/on) of Dragon NaturallySpeaking:




It doesn't work with

- WinMenuSelectItem (app has nonstandard menus)
- PostMessage (app uses the same message for mic on and mic off)
- Hotkeys (dito same hotkey for mic on and off)
- ControlSend (dito no different controls for mic off/on available)

So basically I'm stuck with ImageSearch (yuck) or PixelGetColor (hmm) on that microphone icon...

I'd much rather find a way to control that microphone state directly without having to use the stopgap solution of constantly watching certain pixels on the screen..............

Sorry if this has already been discussed. I haven't followed the thread fully.


Maybe you can get the current status. And use postmessage or hotkeys to do the toggling.
Have you tried ControGet or ControlGetText to "read" from the control ?

Hi Leef and thanks for coming back to the thread. Actually I haven't tried ControlGet/ControlGetText yet since WindowSpy revealed nothing that would indicate the microphone state (well apart from maybe that statusbar text).

Thus, is it possible that ControlGet or ControlGetText will reveal anything more than what can be seen from the AHK Window Spy already...?

[edit:] ...can't use that statusbar text either since there is cases where it shows the exact same text whether the mic is on or whether it is off

OK. I found out that at least there is an ADDITIONAL hotkey in the Dragon app that switches the microphone off ONLY.

Thus, using this "OFF"-hotkey, now at least I can be sure that the mic actually is OFF afterwards.

The only problem still is that the other hotkey (the one that switches the mic ON) actually TOGGLES between the ON and OFF states of the microphone, so you can't be sure wheter you actually switched the microphone ON or OFF after having sent that hotkey....

And always switching it OFF first and only then ON again takes too much time....

So still looking for a way to "look inside that application"...

Another way would be to monitor all F9 keypresses
Of course can't use F9:: as that hotkey would override the DNS's hotkey routine for F9
But could use GetKeyState or KeyWait

However looking in process memory would probably be a more elgant way
---> See this

Thank you for the two additional approaches.

For the moment, it seems as if I'd stick with ImageSearch because the process memory thing seems to go way over my head...

Thanks
David.P

OK I think I found the solution. It's actually very easy if I think about it.

The solution actually is NOT to use that Dragon microphone ON/OFF toggle function key at all in order to make sure that the microphone state is known at all times.

Luckily, the Dragon app has another hotkey called "press to talk". As long as this hotkey is held down, the mic is on, otherwise it is off.

So controlling the mic is really only a matter of making sure that this "press to talk" key is held down if the mic is supposed to be on. My script only has to check like every fraction of a second whether the mic is supposed to be on and if yes issue another "press to talk" key-down....

Switching the mic off and making sure it actually IS off is only a matter of sending a single "press to talk" keystroke...

Seems as if this solution has eradicated like a hundred lines of code that ineffectively had been trying to discover and if applicable correct the mic state...

But thanks anyway to all participants for helping to break the "thought barrier".

Cheers David.P