SendInput and Unicode
in [Visual Basic]
|
Prev: Unicode Labels
Next: EM_CHARFROMPOS in RichEdit
From: Karl E. Peterson on 3 Feb 2009 13:49 Thorsten Albers wrote: > Karl E. Peterson <karl(a)mvps.org> schrieb... >> First I've ever heard of them! Remember, I'm USian, and therefore *highly* >> unicode-impaired. :-/ > > We all hope that this will change under a coloured president with a semitic > name who came from Indonesia... (feel free to replace 'coloured' by > whatever currently is the political correct word in the USA) We all have a *lot* of hopes these days! I'm personally very ready for change myself! :-) -- ..NET: It's About Trust! http://vfred.mvps.org
From: expvb on 3 Feb 2009 14:10 "Karl E. Peterson" <karl(a)mvps.org> wrote in message news:eJy79YahJHA.3708(a)TK2MSFTNGP04.phx.gbl... > expvb wrote: >> ' Windows 2000+ Only >> Public Function SendUnicodeChar(ByVal hWnd As Long, _ >> ByVal lKey As Long) As Long >> SendUnicodeChar = SendMessageW(hWnd, WM_CHAR, lKey, ByVal 1&) >> End Function > > That would prevent the mixing of character sets (to allow for stuff like > navigation keys, etc), that I was trying to support. So the question is, > what advantage does that confer over stuffing the SendInput buffer with > the Unicode character? The way you are doing it is the preferable way. You don't even need to worry about ANSI<->Unicode conversion because you are using KEYEVENTF_UNICODE. However, a while ago someone posted in a thread titled "user32.dll function fails without any error. I am afraid it kills my business." that KEYEVENTF_UNICODE does not work. My guess is that is due to "IME_PROP_ACCEPT_WIDE_VKEY" flag, which effect how KEYEVENTF_UNICODE works. In these cases sending WM_CHAR directly could solve that problem, but it would introduce other complications because the sender need to synchronize when the characters or control keys need to be inserted(The calls to SendInput and SendMessageW must not interfere with each other). But this issue seems less likely and you don't need to worry about it. If someone says to you it doesn't work, tell them to lookup "IME_PROP_ACCEPT_WIDE_VKEY" flag.
From: Karl E. Peterson on 3 Feb 2009 14:31 expvb wrote: > "Karl E. Peterson" <karl(a)mvps.org> wrote ... >> expvb wrote: >>> ' Windows 2000+ Only >>> Public Function SendUnicodeChar(ByVal hWnd As Long, _ >>> ByVal lKey As Long) As Long >>> SendUnicodeChar = SendMessageW(hWnd, WM_CHAR, lKey, ByVal 1&) >>> End Function >> >> That would prevent the mixing of character sets (to allow for stuff like >> navigation keys, etc), that I was trying to support. So the question is, >> what advantage does that confer over stuffing the SendInput buffer with >> the Unicode character? > > The way you are doing it is the preferable way. You don't even need to worry > about ANSI<->Unicode conversion because you are using KEYEVENTF_UNICODE. > > However, a while ago someone posted in a thread titled "user32.dll function > fails without any error. I am afraid it kills my business." that > KEYEVENTF_UNICODE does not work. My guess is that is due to > "IME_PROP_ACCEPT_WIDE_VKEY" flag, which effect how KEYEVENTF_UNICODE works. > In these cases sending WM_CHAR directly could solve that problem, but it > would introduce other complications because the sender need to synchronize > when the characters or control keys need to be inserted(The calls to > SendInput and SendMessageW must not interfere with each other). But this > issue seems less likely and you don't need to worry about it. If someone > says to you it doesn't work, tell them to lookup "IME_PROP_ACCEPT_WIDE_VKEY" > flag. Heh, wow... So, there doesn't appear to be a corresponding ImmSetProperty call, does there? <g> I think I oughta link to this thread from the source! Thanks... Karl -- ..NET: It's About Trust! http://vfred.mvps.org
From: Thorsten Albers on 3 Feb 2009 19:08 Karl E. Peterson <karl(a)mvps.org> schrieb im Beitrag <uirpy$ihJHA.4028(a)TK2MSFTNGP03.phx.gbl>... > So, assuming I were to create another parallel routine that's specifically intended > for Unicode... Would it also matter to the users of this routine that it support > the navigation keys as well? Or would it be sufficient to let them do navkeys with > the standard routine, then send Unicode chars with the dedicated routine? I would use Unicode only for characters (and, of course, Unicode specific control codes). All keys not producing a character I would send as ANSI and with their virtual VK_* key codes. -- Thorsten Albers albers (a) uni-freiburg.de
From: Karl E. Peterson on 3 Feb 2009 19:19
Thorsten Albers wrote: > Karl E. Peterson <karl(a)mvps.org> schrieb... >> So, assuming I were to create another parallel routine that's specifically >> intended for Unicode... Would it also matter to the users of this routine that >> it support the navigation keys as well? Or would it be sufficient to let them do >> navkeys with the standard routine, then send Unicode chars with the dedicated >> routine? > > I would use Unicode only for characters (and, of course, Unicode specific > control codes). Unicode specific control codes? (Victim of my nationality... <sigh>) > All keys not producing a character I would send as ANSI and > with their virtual VK_* key codes. What's the test? -- ..NET: It's About Trust! http://vfred.mvps.org |