Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

Keyboard switching does not work in Take Command (TCMD)

May
80
0
I think I've written about this before (but probably before the forums were created), but I don't see it here, so I'll ask for support again:

In several countries (e.g. Greece, Russia), the default (and sane) setup is installing more than one keyboard layouts in Windows: A US-English layout, to write all latin characters, and a Greek/Russian/whatever layout to write characters in your native language. You usually switch keyboards by pressing together Alt+Shift. This works in both GUI programs (e.g. Notepad) and Console programs (e.g. cmd.exe, tcc.exe).

Unfortunately, this keyboard shortcut does not work at all in TCMD. The keyboard indicator does change, but the typed letters in the console window that is under TCMD do not. So, even if I really type "αβγ", the underlying TCC only understands "abg". TCMD, and not TCC is to blame here, because if you detach the TCC and type Greek characters in the same TCC, it works ok.

To be fair, I've seen the same problem in various open source TCMD-like projects, so I'm guessing this is somewhat Windows related. Also, so far (partly because of that problem) I didn't really use TCMD, I just opened standard TCC windows. Recently I had to use a *lot* of TCC windows, so it came in handy, but again the Alt-Shift problem reared it ugly head.

Can anything be done for this? This is really a very big problem, it makes TCMD unusable in all countries with no Latin alphabet!

Code:
TCC  11,00,51 x64   Windows 7 [Version 6,1,7600]
TCC Build 51   Windows 7 Build 7600

BTW, you should remove the "PHP" button from the editor - or better yet, replace it with a "BTM" button (that would highlight the code as TCC code :))
 
Keyboard switching does not work in Take Command (TCMD)

In Options / Configure Take Command / Tabs, I have the Left Alt Key and Left
Ctrl Key checked, and the two Right keys unchecked. With this setup, using
the left alt, left ctrl combination switches keyboards while I am in TCMD.

On Wed, Aug 4, 2010 at 3:22 AM, gschizas <> wrote:


> I think I've written about this before (but probably before the forums were
> created), but I don't see it here, so I'll ask for support again:
>
> In several countries (e.g. Greece, Russia), the default (and sane) setup is
> installing more than one keyboard layouts in Windows: A US-English layout,
> to write all latin characters, and a Greek/Russian/whatever layout to write
> characters in your native language. You usually switch keyboards by pressing
> together Alt+Shift. This works in both GUI programs (e.g. Notepad) and
> Console programs (e.g. cmd.exe, tcc.exe).
>
> Unfortunately, this keyboard shortcut does not work at all in TCMD. The
> keyboard indicator does change, but the typed letters in the console window
> that is under TCMD do not. So, even if I really type "áâã", the underlying
> TCC only understands "abg". TCMD, and not TCC is to blame here, because if
> you detach the TCC and type Greek characters in the same TCC, it works ok.
>
> To be fair, I've seen the same problem in various open source TCMD-like
> projects, so I'm guessing this is somewhat Windows related. Also, so far
> (partly because of that problem) I didn't really use TCMD, I just opened
> standard TCC windows. Recently I had to use a *lot* of TCC windows, so it
> came in handy, but again the Alt-Shift problem reared it ugly head.
>
> Can anything be done for this? This is really a very big problem, it makes
> TCMD unusable in all countries with no Latin alphabet!
>
>
> Code:
> ---------
> TCC 11,00,51 x64 Windows 7 [Version 6,1,7600]
> TCC Build 51 Windows 7 Build 7600
> ---------
> BTW, you should remove the "PHP" button from the editor - or better yet,
> replace it with a "BTM" button (that would highlight the code as TCC code
> :))
>
>
>
>
>



--
Jim Cook
2010 Sundays: 4/4, 6/6, 8/8, 10/10, 12/12 and 5/9, 9/5, 7/11, 11/7.
Next year they're Monday.
 
Re: Keyboard switching does not work in Take Command (TCMD)

In Options / Configure Take Command / Tabs, I have the Left Alt Key and Left
Ctrl Key checked, and the two Right keys unchecked. With this setup, using
the left alt, left ctrl combination switches keyboards while I am in TCMD.

What kind of windows / keyboard layouts are you using? Because Ctrl+Alt is not an option in Windows 7, Windows Vista or Windows XP. Actually I believe it was never an option in any Windows after 3.x.

In any case, I tried all possible combinations (which are just Ctrl+Shift, Left Alt+Shift and "`"), but none worked.
 
Re: Keyboard switching does not work in Take Command (TCMD)

I don't use the Ctrl+Alt combination. It is just how I have the four
checkboxes set up. With that setup, using Windows 7 here, my system tray
icon changes between EN and DE and the keyboard also changes when I touch
left alt and left shift.


On Wed, Aug 4, 2010 at 9:35 AM, gschizas <> wrote:


> ---Quote (Originally by Jim Cook)---
> In Options / Configure Take Command / Tabs, I have the Left Alt Key and
> Left
> Ctrl Key checked, and the two Right keys unchecked. With this setup, using
> the left alt, left ctrl combination switches keyboards while I am in TCMD.
> ---End Quote---
> What kind of windows / keyboard layouts are you using? Because I Ctrl+Alt
> is not an option in Windows 7, Windows Vista or Windows XP. Actually
> Ibelieve it was never an option in any Windows after 3.x.
>
> In any case, I tried all po
>
>
>
>
>



--
Jim Cook
2010 Sundays: 4/4, 6/6, 8/8, 10/10, 12/12 and 5/9, 9/5, 7/11, 11/7.
Next year they're Monday.
 
Re: Keyboard switching does not work in Take Command (TCMD)

I don't use the Ctrl+Alt combination. It is just how I have the four
checkboxes set up. With that setup, using Windows 7 here, my system tray
icon changes between EN and DE and the keyboard also changes when I touch
left alt and left shift.

It would seem to work with DE keyboard, but in reality it doesn't. Only the ASCII letters (7-bit) work correctly, whenever there is some high-bit character (e.g. "Ä"), TCMD fails to pass the correct key to the underlying TCC (or CMD, or whatever). I'm not sure exactly what passes back, it's not DE or US keyboard:

TCC standalone, DE keyboard, unshifted:
Code:
[COLOR="Red"]^[/COLOR]1234567890ß[COLOR="red"]´[/COLOR]
qwertzuiopü+#
asdfghjklöä
yxcvbnm,.-
TCC standalone, DE keyboard, shifted:
Code:
°!"§$%&/()=?[COLOR="red"]`[/COLOR]
QWERTZUIOPÜ*'
ASDFGHJKLÖÄ
YXCVBNM;:_
(red characters are dead keys)

TCMD with TCC, DE keyboard, unshifted
Code:
\1234567890[]
qwertzuiop;=/
asdfghjkl`'
yxcvbnm,.-
TCMD with TCC, DE keybaord, shifted
Code:
|!@#$%^&*(){}
QWERTZUIOP:+?
ASDFGHJKL~"
YXCVBNM<>_

The standalone TCC is the proper DE keyboard. I really have no idea what the TCMD keyboard is!
 
French keyboard is even more inconsistent:

TCC standalone, unshifted (yes, in French keyboard, you need to press Shift to get numbers...)
Code:
²&é"'(-è_çà)=
azertyuiop[COLOR="Red"]^[/COLOR]$*
qsdfghjklmù
wxcvbn,;:!

TCC standalone, shifted
Code:
[COLOR="Red"]▓[/COLOR]1234567890°+
AZERTYUIOP[COLOR="Red"]¨[/COLOR]£µ
QSDFGHJKLM%
WXCVBN?./§

TCMD with TCC, unshifted
Code:
'1234567890[=
azertyuiop];\
qsdfghjklm`
wxcvbn,./[COLOR="Red"]▓[/COLOR]

TCMD with TCC, shifted
Code:
"!@#$%^&*(){+
AZERTYUIOP}:|
qsdfghjklm`
WXCVBN<>?[COLOR="Red"]▓[/COLOR]

red characters are dead keys, character "" is disabled (it's a dead key, but it isn't used as a combination)
 
Re: Keyboard switching does not work in Take Command (TCMD)

I suppose this may be related to the Sticky Keys issue I reported a great
long time ago.

I admit, since I do not actually know anything but the US keyboard, I only
really tested the German(DE) keyboard with the y and z keys, which I know
reverse. There were some other differences, but I don't know if they were
proper or not. I did not see any 8-bit codes.

On Wed, Aug 4, 2010 at 1:03 PM, gschizas <> wrote:


> French keyboard is even more inconsistent:
>
> TCC standalone, unshifted (yes, in French keyboard, you need to press Shift
> to get numbers...)
>
> Code:
> ---------
> ²&é"'(-è_çÃ*)> azertyuiop^$*
> qsdfghjklmù
> wxcvbn,;:!
> ---------
> TCC standalone, shifted
>
> Code:
> ---------
> ▓1234567890°+
> AZERTYUIOP¨£µ
> QSDFGHJKLM%
> WXCVBN?./§
> ---------
> TCMD with TCC, unshifted
>
> Code:
> ---------
> '1234567890[> azertyuiop];\
> qsdfghjklm`
> wxcvbn,./â–“
> ---------
> TCMD with TCC, shifted
>
> Code:
> ---------
> "!@#$%^&*(){+
> AZERTYUIOP}:|
> qsdfghjklm`
> WXCVBN<>?â–“
> ---------
> red characters are dead keys, character "â–“" is disabled (it's a dead key,
> but it isn't used as a combination)
>
>
>
>
>



--
Jim Cook
2010 Sundays: 4/4, 6/6, 8/8, 10/10, 12/12 and 5/9, 9/5, 7/11, 11/7.
Next year they're Monday.
 
Note that in the both DE and FR keyboard, there are only ASCII characters, there isn't any high-bit or even unicode character. By high-bit I mean characters that should normally appear in places 0x80-0xFF in codepage 1252, which is the US-English codepage (even though this is not my system codepage). By unicode I mean characters that appear in even higher places, such as Greek (U+340—U+3FF), Cyrillic (U+400—U+4FF) etc.

In the case of the Greek keyboard, since it is almost identical to the US keyboard (in the punctuation of course, not in the actual letters), the TCMD with TCC layout is identical to US layout. The same happens with the Russian keyboard as well: Even though the Russian keyboard is very different from the US one (see below), TCMD completely ignores it and uses the US layout, even for the ASCII characters.

Proper Russian keyboard (TCC standalone, notepad etc):
Code:
[COLOR="Green"]Unshifted[/COLOR]
ё1234567890-=
йцукенгшщзхъ\
фывапролджэ
ячсмитьбю.
[COLOR="Green"]Shifted[/COLOR]
Ё!"№;%:?*()_+
ЙЦУКЕНГШЩЗХЪ/
ФЫВАПРОЛДЖЭ
ЯЧСМИТЬБЮ,
 
> In several countries (e.g. Greece, Russia), the default (and sane)
> setup is installing more than one keyboard layouts in Windows: A US-
> English layout, to write all latin characters, and a
> Greek/Russian/whatever layout to write characters in your native
> language. You usually switch keyboards by pressing together Alt+Shift.
> This works in both GUI programs (e.g. Notepad) and Console programs
> (e.g. cmd.exe, tcc.exe).

This is not supported in Take Command, for two reasons:

1) The keystrokes are intercepted by Windows, and the Windows keyboard
driver switches Take Command to the new layout. However, TCMD doesn't know
this happened, and the console windows never get the keystrokes, so they're
not switched (by Windows or TCMD).

2) The way Windows is designed wouldn't let this work anyway, as the
keyboard switching is per app, not (as in the case of TCMD), per app with
possibly different keyboard layouts for a dozen different apps that the
first app is running.


> Can anything be done for this? This is really a very big problem, it
> makes TCMD unusable in all countries with no Latin alphabet!

Since we have no support in Windows to do this, no translations for any of
those alphabets, non-existent sales to any of those countries, and no
ability to support them anyway, I don't see any viable means of doing this.

Rex Conn
JP Software
 
This is not supported in Take Command, for two reasons:

1) The keystrokes are intercepted by Windows, and the Windows keyboard
driver switches Take Command to the new layout. However, TCMD doesn't know
this happened, and the console windows never get the keystrokes, so they're
not switched (by Windows or TCMD).

Are you sure? I'm logging at least these messages:
1. WM_IME_SELECT, with lParam=0x04080408 for English (US) keyboard and a lParam=0x04090409 for a Greek keyboard. You will notice that 0x0408 is the language code for en-US (US English) and 0x0409 is the language code for el-GR (Greek).
2. WM_IME_NOTIFY message with wparam=1 for US keyboard (first keyboard in my setup) and wparam=2 for Greek (second keyboard).

2) The way Windows is designed wouldn't let this work anyway, as the
keyboard switching is per app, not (as in the case of TCMD), per app with
possibly different keyboard layouts for a dozen different apps that the
first app is running.
I'm not sure I understood this correctly, but I guess you're saying that keyboard is changed per TCMD instance, so, it would be diffucult to do that per not per TCMD Tab (e.g. per TCC)?
There's an easy (and ugly, of course) solution to that: Switch keyboards on each TCC, each time you get the "switch keyboard" message from windows on TCMD.

Since we have no support in Windows to do this, no translations for any of
those alphabets, non-existent sales to any of those countries, and no
ability to support them anyway, I don't see any viable means of doing this.

If it was just Greece and Russia, I would agree (after all, I've lived without TCMD for a long time :)), but, as I demonstrated, this doesn't work for German or French keyboards either.

I would also like to point out that this is allegedly being fixed on Console2, an open source equivalent (well, not really, but the basic premise is the same), as shown in the bug tracker and in the actual code change

(the workaround mentioned in the SF forum didn't work for me)
 
More information:

This is probably Windows 7 related (although not exclusively). Console2 is working 100% ok in Windows XP (it's not working in Windows 7, but I guess that's the bug they're fixing).

TCMD still doesn't work, but it is more hopeful in Windows XP than in Windows 7. In XP it seems to stay in the language you have when you first open it. There is no switching, but there is also none of the weirdness of mangled keyboard layout that is on 7.
 
> Are you sure? I'm logging at least these messages:
> 1. WM_IME_SELECT, with lParam=0x04080408 for English (US) keyboard
> (seems like a no-brainer to me) and a lParam=0x04090409 for a Greek
> keyboard. You will notice that 0x0408 is the language code for en-US
> (US English) and 0x0409 is the language code for el-GR (Greek).
> 2. WM_IME_NOTIFY message with wparam=1 for US keyboard (first keyboard
> in my setup) and wparam=2 for Greek (second keyboard).

I'm quite sure -- you're probably seeing those messages going to TCMD, which
does indeed receive them and handle them appropriately. (As you can see if
you type in one of the TCMD edit controls.)

The problem is that the messages cannot be forwarded on to the (hidden and
unknowable) conhost.exe window, so they don't get set for the console app
(TCC in this case).

This is one of the reasons I created the "Command Input" window in TCMD,
which works fine with keyboard switching. Is there some reason you won't
use Command Input?


> If it was just Greece and Russia, I would agree (after all, I've lived
> without TCMD for a long time :)), but, as I demonstrated, this doesn't
> work for German or French keyboards either.

But the German and French keyboards don't require switching to English to
enter characters.

Rex Conn
JP Software
 
On Sat, 07 Aug 2010 12:39:38 -0400, rconn <>
wrote:

|I'm quite sure -- you're probably seeing those messages going to TCMD, which
|does indeed receive them and handle them appropriately. (As you can see if
|you type in one of the TCMD edit controls.)
|
|The problem is that the messages cannot be forwarded on to the (hidden and
|unknowable) conhost.exe window, so they don't get set for the console app
|(TCC in this case).

Just curious about Win7 and kb switching in general ...

Have things changed drastically in Win7? Isn't there still
ConsoleWindowClass? Upon starting a new tab, can't TCMD
EnumerateWindows, looking for ConsoleWindowClass match windows with
newly-created PIDs (GetWindowThreadProcessId), remember console
windows for each tab, and later forward such messages to the
appropriate console? ... or just send to the console whatever
keystroke would ordinarily cause it to switch keyboards?

Could a plugin command be used to do keyboard switching in a TCC
running (hidden) in a TCMD tab (by sending a message to
GetConsoleWindow())?
 
> Just curious about Win7 and kb switching in general ...
>
> Have things changed drastically in Win7?

Things have changed drastically in Win7.


> Isn't there still ConsoleWindowClass? Upon starting a new tab, can't TCMD
> EnumerateWindows, looking for ConsoleWindowClass match windows with
> newly-created PIDs (GetWindowThreadProcessId), remember console
> windows for each tab, and later forward such messages to the
> appropriate console?

It can, and it does. (If it didn't, you wouldn't be able to enter any
characters in a TCMD tab window!)

But it doesn't work with keyboard language switching in Win7, because the
conhost.exe (hidden) window is *not* the console window.

Rex Conn
JP Software
 
I'm quite sure -- you're probably seeing those messages going to TCMD, which
does indeed receive them and handle them appropriately. (As you can see if
you type in one of the TCMD edit controls.)

The problem is that the messages cannot be forwarded on to the (hidden and
unknowable) conhost.exe window, so they don't get set for the console app
(TCC in this case).

Well, I have to ask, how is Console2 doing it? Even worse, how are you sending the keys from Command Input? You can just send an "Alt-Shift" (yes, this is a dirty hack) when you receive a message to switch keyboards.

This is one of the reasons I created the "Command Input" window in TCMD,
which works fine with keyboard switching. Is there some reason you won't
use Command Input?

Well, first of all it's a very awkward way to enter characters. Second, it doesn't always produce the intended response. For example, if I enter "abcαβγ" (note that they are all lower case), I get "abcΑΒΓ" in the actual window. Other times (I think it's related to which keyboard is selected), I get "ABCαβγ". Also, I can't find a way to change the command window font.

But the German and French keyboards don't require switching to English to
enter characters.

Hmmm... That explains a bit of the problem. The problem is only on switching. At least now it makes sense! I tried with Greek as "default" keyboard, and I could write Greek (but only Greek) and German with the proper keyboard layout. At least I won't go crazy finding out why those weird layouts existed :)
 
> Well, I have to ask, how is Console2 doing it? Even worse, how are you
> sending the keys from Command Input? You can just send an "Alt-Shift"
> (yes, this is a dirty hack) when you receive a message to switch
> keyboards.

I poked around in conhost.exe and found the bug (Win7 & Win2008R2). The
keyboard language change message is WM_INPUTLANGCHANGE, which TCMD duly
forwards on to the console sessions. However, conhost is ignoring this
message and is only doing the keyboard change on a
WM_INPUTLANGCHANGEREQUEST, which TCMD never sees (it's eaten by Windows), so
it cannot pass it on to the console app. I made a change for build 52 to
send a WM_INPUTLANGCHANGEREQUEST followed by a WM_INPUTLANGCHANGE to the
console window, which seems to solve the problem.

Rex Conn
JP Software
 
I made a change for build 52 [..], which seems to solve the problem.

I can confirm it works! It works even with Russian keyboard, which I added after I opened TCMD. It even works with Arabic and Japanese keyboard (although the results are strange, to say the least :))

Thank you for the speedy fix! :)
 
I have the opposite problem. After five minutes of typing commands into a TCC/LE console window, keyboard suddenly switches into katakana input from the US keyboard layout. Even more confusing is that the applet controlling the MS IME keyboard driver shows NO change.

The good news is that the applet provides a solution (for five minutes anyway): Change its control to katakana and back to roman input. Alas, this is a major PITA when I have to do this every five minutes.

Aside: The Alt+` combination controlling automatic conversion from letters to hiragana (for subsequent semi-automatic conversion to real Japanese) works inside the console window (thanks to Unicode?) should I ever feel the need to enter Japanese in commands. Maybe later.

Finally, I suspect that the problem is in Windows Vista, not JPS products. I say this because the very same effects occur in (shudder) CMD.EXE windows.
 

Similar threads

Back
Top