Register keys to an ActiveX control

WTSupported in traditional Synergy on Windows




xcall AX_WANTSKEY(tk_container_id, key_code, mapping_flag[, key_code, 
&     mapping_flag, …])



The ID of the UI Toolkit ActiveX container window. (n)


The Toolkit key code for the desired key (defined in inpctl.def) or one of the following: (n)


All key codes (CTRL_A_KEY through CTL_SHFTTAB)


All keys that are currently mapped to shortcuts


One of the following values (defined in tools.def): (n)


Map as a control accelerator, then menu accelerator, then keystroke. (default)


Map only as a keystroke.


Map as a control accelerator, then keystroke.


Map only as a menu accelerator (shortcut).


AX_WANTSKEY allows function and control keys to be passed to the ActiveX control instead of being interpreted by Toolkit. (On UNIX and OpenVMS, this routine is ignored.)

The special key_code values enable you to allow only certain keys to be processed as shortcuts.

When a function or control key is pressed while in AX_INPUT, the default processing of that keystroke is as follows:

AX_WANTSKEY allows this behavior to be overridden in one of three ways for any control or function key when processing a specific ActiveX container window. (The mapping flag D_MAP_DEFAULT specifies the default processing and is only needed to reset a previously specified mapping flag for that key.)

The following table illustrates the types of key mapping that may occur for each option. Where more than one type of mapping is shown, the leftmost marked column has priority.



UI Toolkit shortcut

Keystroke to control











Because all key codes that can be passed to AX_WANTSKEY are available to Toolkit as shortcuts, a key will never be seen as a keystroke to the control when shortcut mapping is enabled for the key.


The application used to create the ActiveX control can affect whether or not you need to use AX_WANTSKEY. For instance, controls written using Visual Basic rarely need to use AX_WANTSKEY, because keystrokes like tab, shift+tab, and esc are already mapped as accelerators. However, controls written using Delphi usually require you to use AX_WANTSKEY, because Delphi doesn’t automatically translate keystrokes. Unless you developed the control, you won’t know if it is handling the keystrokes or not. Therefore, we recommend that at first you try not using AX_WANTSKEY. If a keystroke doesn’t get through to the control, you can add the key using AX_WANTSKEY.

See also


The default mapping works for most controls, but a more robust setting can be established by calling the following statement after you have placed and enabled all desired menu shortcuts:

xcall ax_wantskey(tk_container_id, D_KEY_ALL, D_MAP_CONTROL, D_KEY_MENU, D_MAP_MENU)

This statement first designates that all keys belong to the control (either as an accelerator or as a keystroke), and then it maps all enabled menu shortcuts to Toolkit. Therefore, if the key corresponds to an enabled menu shortcut it will be interpreted as such. Otherwise, it is left to the control to interpret.

Also see the Examples for AX_INPUT.