Note: For known issues related to product licensing, please see the known issues for LicenseControl.

N/A

Discussion: Apple made wholesale changes "underneath" OS X with 10.5 and some of the interfaces used by KMremoteControl no longer work.

Discussion: After an extensive investigation, we are only able to replicate this error once. After redefining the keybindings, we cannot get it to recur.

This appears to be an OS X bug. Furthermore, since we've seen different behaviors on different systems, it appears to be related to more than one factor. Unfortunately, we've not been able to identify a clear set of factors that would enable a repeatable test case to be created.

Workaround: Redefine your Expose keybindings and the problem will likely not recur. If your Expose keybindings do continue to disappear, turn off the "Suppress system keys while controlling" preference and define your Expose keybindings again. After using KMremoteControl with the "Suppress system keys while controlling" preference turned off and the Expose keybindings defined (and not disappearing), you might be able to turn the "Suppress system keys while controlling" preference back on and have the Expose keybindings continue to work. We've seen all these situations.

Behavior: When controlling a PC/Windows system that has multiple monitors attached, KMremoteControl may or may not function correctly.

Discussion: If you require multiple-monitor support, please verify that it works on your particular setup, prior to purchasing KMremoteControl.

This behavior will remain.

Discussion: We have not provided any special support for International keyboards.

Workaround: Some keyboard-mapping capabilities are provided in the Mac OS X version via the "Edit Key Substitutions..." button. Also, on Mac OS X, if you are energetic enough to attempt to change your keyboard behavior, you can look at the following resources:

• Ukelele
• Apple Developer Tech Note
• Wordherd

If you develop a solution you'd like to share with others, we'd be happy to publish the information or a link to the information.

This behavior will remain.

Behavior: When the system being controlled is a PC/Windows system, pressing Alt-Tab on the controlling system switches applications on the PC/Windows system being controlled, but the "switching icons window" is not presented on the controlled system.

Note: KMremoteControl uses "physical" meta-key mappings:
      PC      Mac
      Alt <=> Cmd
      Win <=> Opt

Discussion: Windows is treating this keystroke in a special way and there appears to be no interface to overcome this (and we avoid dangerous hacks).

Workaround: A workaround is to use the Win-Tab key, which shows the switching activity in the program bar, followed by a Return key, to select the entry.

Note that, if the controlling system is a Mac OS X system, Cmd-Tab (i.e., Alt-Tab) is also the built-in switcher hotkey in OS X so, in order to use it, you need to create a key substitution where the key(s) typed are Cmd-Tab and it's marked as a hotkey and the key(s) sent are Cmd-Tab.

This behavior will remain.

Behavior: The "caps lock" key(s) do not work the same on PC/Windows and Mac OS X systems.

Discussion: This issue is discussed in this FAQ entry.

This behavior will remain.

Behavior: The "num lock" key does not work the same on PC/Windows and Mac OS X systems.

Discussion: This issue is discussed in this FAQ entry.

This behavior will remain.

Behavior: The Ctrl-F14 and Ctrl-F15 keys do not work the same on PC/Windows and Mac OS X systems.

Discussion: This issue is discussed in this FAQ entry.

This behavior will remain.

Behavior: When controlling another PC/Windows system using Terminal Server or VMware, on the system being controlled, does not work.

Discussion: Generally, controlling a system that is, itself, controlling another system is not supported.

This behavior will likely remain.

Behavior: When controlling a Mac OS X system, pressing the "eject" key on the controlling system has no effect on the system being controlled.

Discussion: Unfortunately, OS X retains exclusive access to certain keystrokes, the "eject" key being one of those. KMremoteControl is currently unable to overcome this issue in all cases. This is a particular hardship when the system being controlled has an optical drive that does not have a physical eject button.

The good news is that OS X supplies a menu item that can be used to open/close the door. To activate this menu item, double-click/open the menu item:

/System/Library/Core Services/Menu Extras/Eject.menu

This will add an eject item to the right side of the menu.

This behavior will remain.

Behavior: When using a Mac OS X system to control another Mac OS X system, pressing certain keystroke combinations have no effect on the system being controlled (also see item regarding the "eject" key, above and this FAQ entry regarding application-switcher keys).

Discussion: Unfortunately, OS X retains exclusive access to certain keystrokes (e.g., the "force quit" combination of Cmd-Opt-Esc).

To help overcome this behavior, KMremoteControl provides the "Key Substitution" capability. For example, to be able to issue a "force quit" keystroke on the controlled system, you can create a Key Substitution as follows:

• open the "Edit -> Key Substitutions..." menu
• press the "Add" button
• check the "This key-combination is also defined as a hotkey
• press the "ctrl" then "cmd/apple" then "esc" keys
• press the "Next" button
• press the "opt" then "cmd/apple" then "esc" keys
• press the "Done" button

Now pressing "Ctrl-Cmd-Esc" on the controlling system will be equivalent to pressing "Opt-Cmd-Esc" (i.e., "force quit") on the controlled system.

See the documentation for complete information on the Key Substitution capability.

This behavior will remain.

Behavior: Can't control a system after the controlling system's screen saver activates if a password is required and Ctrl-Alt-Delete is required to enter a password.

Discussion: If the PC/Windows system's screen saver is configured to require a password and the system is configured to require users to enter Ctrl-Alt-Delete when logging in and you are controlling another system when the screen saver activates, you may be unable to control the system that was being controlled before the screen saver activated after you supply your password to deactivate the screen saver.

There are two workarounds for this issue:

• disconnect from a system being controlled before the screen saver activates
  
  
• after logging in to deactivate the screen saver, immediately deactivate remote controlling then reactivate remote controlling and control will be re-established

This behavior will remain.