Sending Keystrokes

Vocola 2 offers three different methods of sending keystrokes: SendDragonKeys, SendSystemKeys, and SendInput. Each of these has its pros and cons. Here's a simple command demonstrating use of each of these plus the default method of sending keys:

Default method

By default prior to version 2.8.7, Vocola 2 uses SendDragonKeys. Thus the default text in the previous command would be sent by SendDragonKeys in those versions. Version 2.8.7 and later supply a Dragon proxy (see Extensions) that changes the default to SendInput on Vocola startup and extension reload but allows voice commands to switch the default between SendInput and SendDragonKeys at any time. If you do not like this behavior, you can either delete the proxy entirely (Vocola/extensions/vocola_ext_dragon_proxy.py) or change its startup default by changing the following line in the proxy:

use_send_input = True

use_send_input = False

SendDragonKeys

This is the traditional method used by Dragon to send keystrokes. It is what it uses to deliver dictation to Windows without full select-and-say support.

Any modifier keys (Shift, Ctrl, Alt) pressed while the SendDragonKeys command executes do not affect the command action. Low level hooks like hotkeys often do not see these keystrokes; for example, SendDragonKeys({alt+tab}) will not trigger the Windows shortcut. To trigger such hotkeys, you will need to use one of the other two methods.

SendDragonKeys suffers from a doubling/dropping bug: occasionally some keystrokes can be dropped or doubled. This used to be only true for the first keystroke sent, allowing a workaround where Vocola would send an extra shift key press/release at the start, but lately the bug has been striking anywhere in the sequence sent so this workaround no longer works.

Another known bug with SendDragonKeys is that it sends the @ key via {alt_hold}{numkey0}{numkey6}{numkey4}{alt_release}, which works for some Windows applications like Word but fails with Emacs and cannot handle things like {ctrl+@}. It is possible to work around this for English keyboards by changing @ to shift+@ -- see the Dragon proxy for sample code.

Because of the doubling/dropping bug, it is recommended to avoid this method whenever possible.

SendSystemKeys

The other method provided by Dragon; it is much slower than SendDragonKeys, but can trigger hotkeys. Dragon's advice is:

Sends keystrokes such as {ctrl+esc} to the Windows operating system. Only use this command for short system key sequences where the SendDragonKeys command does not work. It is particularly useful for sending the {Ctrl+Esc}, {Alt+Esc}, and {Alt+Tab} key sequences and hot keys (such as the key to bring up the Correction dialog box).

The keyboard Alt, Ctrl, and Shift keys affect this command. For example, if you press the Shift key and run SendSystemKeys({Alt+Esc}), Windows gets a Shift Alt Esc key sequence. The command sends keystrokes more slowly than the SendDragonKeys command. Also, if the system responds slowly, it is possible to overflow the system keyboard buffer by using a long string with this call.

It is also possible to control the speed at which keystroke events are sent by this method via an extra optional argument.

SendInput

This is a new method provided by a Vocola extension, Keys. It uses the Windows SendInput method to send keystrokes.

SendInput is immune to the doubling/dropping bug and has speed comparable to SendDragonKeys rather than the much slower SendSystemKeys while still being able to trigger hotkeys.

SendInput can also independently press and release keys and mouse buttons (e.g., {alt_hold}{ctrl_hold}ec{ctrl_release}{alt_release} to move to current comment in Google docs) as well as press many new keys available on modern keyboards like {VolumeMute} or {MediaNextTrack}.

The main drawback is that you cannot use SendInput to send events to elevated windows when User Account Control (UAC) is turned on. Lesser drawbacks are that, unlike SendDragonKeys, already pressed keys do modify the sent characters (e.g., held shift key makes a into A) and the keys are sent completely asynchronously so waits may be required when mixing SendInput and other actions.

Other drawbacks are that non-English key names are not currently supported and some characters on non-standard US keyboards do not work correctly (SendDragonKeys also fails here).

For documentation, including examples, see here.