Key combos like Ctrl-Alt-x not passed unless Scroll-Lock on

[badpens]

When I recently upgraded ultravnc from 1.0.2 to 1.0.6.4, I started having trouble using some of my xemacs key combinations when connecting to my linux VNC server.

For example, Ctrl-Alt-X (which I use all the time as repeat-complex-command in xemacs) is always passed by the 1.0.2 vncviewer, but is only passed by 1.0.6.4 vncviewer when scroll-lock is on.

I understand that in the "scroll-lock off" state, the hotkeys are processed locally, but Ctrl-Alt-X is not a local hotkey, is it? It seems that 1.0.2 handled it properly (passing it to the server), but not the most recent versions.

(In fact, I tried downloading and trying a few older revs and found the 1.0.4rc13 vncviewer has the same behavior as 1.0.6.4 -- swallowing the C-A-x keystroke when scroll-lock is OFF.)

I also tried using nohotkeys=1 in the .vnc file to see if I could eliminate the need to have scroll-lock ON, but that didn't work.

This change since 1.0.2 affects many of my oft-used Ctrl-Alt keystrokes in xemacs.

1) Has any one else seen this?
2) Anyone know why this changed?
3) Could the old 1.0.2 behavior please be restored?

Thanks.

[jwildstr]

When I recently upgraded ultravnc from 1.0.2 to 1.0.6.4, I started having trouble using some of my xemacs key combinations when connecting to my linux VNC server.

For example, Ctrl-Alt-X (which I use all the time as repeat-complex-command in xemacs) is always passed by the 1.0.2 vncviewer, but is only passed by 1.0.6.4 vncviewer when scroll-lock is on.

I understand that in the "scroll-lock off" state, the hotkeys are processed locally, but Ctrl-Alt-X is not a local hotkey, is it? It seems that 1.0.2 handled it properly (passing it to the server), but not the most recent versions.

(In fact, I tried downloading and trying a few older revs and found the 1.0.4rc13 vncviewer has the same behavior as 1.0.6.4 -- swallowing the C-A-x keystroke when scroll-lock is OFF.)

I also tried using nohotkeys=1 in the .vnc file to see if I could eliminate the need to have scroll-lock ON, but that didn't work.

This change since 1.0.2 affects many of my oft-used Ctrl-Alt keystrokes in xemacs.

1) Has any one else seen this?
2) Anyone know why this changed?
3) Could the old 1.0.2 behavior please be restored?

Thanks.

Oh good! Someone else is seeing this problem too! Did you find a workaround? For me, it's C-A-f and C-A-b that are problems. One other workaround is to hit escape (Meta) then Control-key, but that's no more fun.

[badpens]

I've no workaround for this in UltraVNC, other than using the ScrollLock. (Using ScrollLock is a pain since that messes me up when I go back to using something like MS-Excel and try to move from cell to cell with the arrow keys.)

Does anyone know if there are plans to fix this?

[effgee]

Same question here.

I cant get it to pass ctrl-alt-[anything], even with scroll lock on (even with scroll lock on the host and local machines).
I'm using UltraVNC X64 viewer 1.0.9.6.2

Can anyone shed any light on why it doesn't pass ctrl-alt key combos, especially since it used to ?

[Rudi De Vos]

Only thing you can try is to select the alternate keyboard method. " japanese keyboard"
This handle keyboard with the older method
( viewer option )

[tanki]

I updated windows and got the same problem. Short of disabling hotkeys in windows, I was not able to send hotkeys to vnc.

The next best solution was to change the hotkeys in vnc (System -> Preferences -> Keyboard Shortcuts), and I was able create a new shortcut. Was ctrl-alt-left, to just ctrl-left. etc.