Small bug// on quick searching russian file name

[Baptist]

File in folder: "русский файл".
Alt+'р' -> Opens EMPTY search window.
another 'р' -> Ok. Cursor jump to the file.

[ghisler(Author)]

There are two types of "p", a Russian one and a Latin one. You probably typed the English one while the file contains the Russian one - could this be the case?

[Baptist]

No. I have tested it with various file names and Configuration/Operation/Quick Searc settings and find:

If the setting is "letter only" or "letters - with search dialog" -> all works fine.
If the setting is "ctrl+alt+letters" or "alt_letters" -> there is bug. In detail:

Files in folder: "приложение.doc", "gп_1.doc", "gw_2.doc".
English 'G' and russian 'П' are located on the same button.
Keyboard is in russian layout.
I press Alt+'п' -> TC finds file "gw_2.doc"
I press 'п' again -> TC finds file "gп_1.doc"
In other words TC finds first letter (that I press with Alt) always in english independent of active keyboard layout. In the example I have to press Alt+'п', Backspace, 'п' to find "приложение.doc".

I use fully english WinXP sp2. And english TC. Try to repeat my actions!

[Leshiy]

I confirm this bug.
It happens only when "Alt" used for search.
And doesn't matter what language of interface set..first letter always in english.

[minarik]

When you press any letter-key while holding down ALT or CONTROL the only generated message is WM_KEYDOWN. This message contains a virtual key code (not char!). Therefore, a virtual key code must be translated to a char code manually using ToAsciiEx function (After calling GetKeyboardState, VK_CONTROL must be zeroed in received array before passing it to ToAsciiEx).

[ghisler(Author)]

2minarik
Can you give me more details on this, please? I'm currently using MapVirtualKey(uCode,2);

According to the help, this should do the following:
"uCode is a virtual-key code and is translated into an unshifted character value in the low-order word of the return value."

I wonder why that doesn't work with Russian...

[minarik]

2ghisler(Author)

I checked MapVirtualKey myself - yes, it always returns a latin char regardless of active keyboard layout (at least on my Win2kSP4).

The following works ok for me. But msdn is quite unclear about size of destination buffer (lpChar).

Code: Select all

  BYTE KeyState[256];
  WORD Char;
  GetKeyboardState((LPBYTE)&KeyState);
  KeyState[VK_CONTROL] = NULL;
  if(ToAsciiEx(LOWORD(wParam), MapVirtualKey(LOWORD(wParam), 0), (LPBYTE)&KeyState, &Char, NULL, GetKeyboardLayout(GetCurrentThreadId()))>=1) {
  // All fine - low order byte of Char now contains ANSI char code.
  }

[ghisler(Author)]

2minarik
Thanks for the code, I will try it with that!

[air]

Hmm.. It seems like this problem still not resolved in 6.51. I'm right?

[ghisler(Author)]

I have added it for testing purposes, and it worked very well. However, it didn't work with Chinese or Japanese locales, so I removed it from 6.51. I will re-add it in a later version when I find a workaround for these languages.