message pump variant X64

[tenkey]

The main thing is that TranslateMessage processes keyboard messages, and generates new keyboard messages. The edit boxes expect specific messages for keyboard input, and it's not EN_CHANGE. That notification comes from the edit box after it has updated its display, so the parent window can retrieve the edit box text. My recollection is that it was a pain to use, because it was also sent each time a keyboard character was accepted.

I don't know how much non-numerical keyboarding you expect to be doing. Will you be using '.' or '-'? Are you using a US keyboard? The raw WM_KEYUP and WM_KEYDOWN messages don't send ASCII codes. The ASCII codes are what you need in those edit boxes.

If the digit keys are the only keys you use, then you might get away with just PostMessage WM_CHAR when you get a digit key press. Otherwise, your TranslateMessage replacement will need to monitor for shift key presses and releases to know when the shift keys are up or down. And then you will need to make a translation from virtual key code to (ASCII/Unicode) character code depending on whether the shift keys are up or down. You can probably ignore IME messages if your computer is using a language that doesn't need IME (a special keyboard input procedure).

[daydreamer]

If the digit keys are the only keys you use, then you might get away with just PostMessage WM_CHAR when you get a digit key press. Otherwise, your TranslateMessage replacement will need to monitor for shift key presses and releases to know when the shift keys are up or down. And then you will need to make a translation from virtual key code to (ASCII/Unicode) character code depending on whether the shift keys are up or down. You can probably ignore IME messages if your computer is using a language that doesn't need IME (a special keyboard input procedure).

I have some code that uses unicode richedit control,using exotic languages,one of the languages is japanese,so now the IME is a helper interface to easily write asian languages,but you go must go in setup the usual text editors with desired language in control panel,before it starts to work,japanese you write on the usual western keyboard and first it turns your text to hiragana/katakana unicode chars (consonant/vocal combos )and also translates words into right kanji character(whole word)
but is interesting if possible to call some api,to get your own richedit control prepared to IME,is it the right .dll file with its own IME api you can invoke this translation instead of write your own ?

[hutch--]

IME is usually determined by the country/language version of the OS Right to left scripts (Arabic, Hebrew). The documentation for IME messaging appears to depend on if you have an Asian language OS version. It may be possible for a European language OS version but I have not seen it done.

[daydreamer]

Hutch
Easy part usage of Japanese language pack and IME with simplistic hiragana and katakana, can be made with code that does that without IME, replacing "sayonara", to exchange SA,yo,na,ra with hiragana unicode characters is possible

But when you want the words to be translated to Chinese /japanese /Korean unicodes about 30k of them,I can't, need to be some expert on Chinese characters, to be able to create that
So that it would be interesting todo it with help of call  IME functions if there is such a library

[mikeburr]

i posted about the EN_CHANGE because i noticed it was set and thought this may be M$ way of internally inhibiting input  .. turns out not so its just an indicator .. though is absent from button / listbox  messages etc ...hence was interested to see if anyone knew anything about the actual workings of TRANSLATE ...and what happened if i moded it ..

the IME messages are evident on cursor over edit box because it looks like everything is translated internally to wide char regardless [which is why i said i was surprised to see it as in the past ive explicitly declared the API's xxxxA ...

erm yes .  numerics as well  as . and - [   6A 6B 6D 6E 6F  prob] 
regards mikeb

[jj2007]

M$ way of internally inhibiting input

The M$ way is to intercept the WM_KEYDOWN, WM_KEYUP and WM_CHAR messages in a subclass WndProc.

[daydreamer]

I have tried some simple increment counters,running simultanously while a TIMER shows end result after 60 seconds
I was curious ,so I race a message pump x86 equipped with the very old trick peekmessage vs a workerthread:

peekmessage version =ca 1 million/per second,workerthread ca billions,close to clock freqency

[tenkey]

was interested to see if anyone knew anything about the actual workings of TRANSLATE ...and what happened if i moded it ..

I don't know the exact way that TranslateMessage works. But I took it out and replaced it with a call to this 32-bit PROC:

Code Select Expand


FilterKeyboard PROC pMsg: dword
    mov edx, pMsg
    mov eax, [edx].MSG.message
    .if eax == WM_KEYDOWN
        mov ecx, [edx].MSG.wParam
        .if ecx >= '0' && ecx <= '9'
            invoke PostMessage, [edx].MSG.hwnd,WM_CHAR,ecx,[edx].MSG.lParam
        .elseif ecx >= 'A' && ecx <= 'Z'
            add ecx,20h    ; translate to lower case letter
            invoke PostMessage, [edx].MSG.hwnd,WM_CHAR,ecx,[edx].MSG.lParam
        .elseif ecx == VK_BACK
            invoke PostMessage, [edx].MSG.hwnd,WM_CHAR,ecx,[edx].MSG.lParam
        .elseif ecx == VK_OEM_PERIOD
            invoke PostMessage, [edx].MSG.hwnd,WM_CHAR,'.',[edx].MSG.lParam
        .elseif ecx == VK_OEM_MINUS
            invoke PostMessage, [edx].MSG.hwnd,WM_CHAR,'-',[edx].MSG.lParam
        .endif
    .endif
    ret
FilterKeyboard ENDP


The result is an edit box that will accept numbers and the basic Latin letters, and activates the backspace key. A little more work is needed to get the shifted and other characters.

Edit: Added period and minus.

[mikeburr]

tenkey
thanks very much for your time and trouble ... ive done something  sort of similar to your suggestion ... there are prob a lot of other people out there thinking of trying something similar .. [GDI'ers etc] so im sure that its been a very useful discussion  ... ive just been looking at Paul Watts Clip Region stuff [ which in turn i think is derived from "window graphics programming ...and direct draw" by Feng Yuan and am looking to use your method in this connection
many thanks
mike b

[daydreamer]

thanks tenkey,great work
I think I make a swedish version that means let you type in swedish floating point notation:
3,14159 is our usual way to use comma instead of 3.14159

[tenkey]

I recently saw an article on the French keyboard. It gave details of the traditional and new layouts. And it led me to http://norme-azerty.fr

I pretty much expected symbols to be in different places. So the US ,< key would probably be a French ,? key in the traditional, and a ,! key in the new layout.
There was also an AltGr shift for getting a third character when pressing a key. The new layout adds a fourth character by combining Maj. and AltGr. The decimal digits are typed using the Maj. shift key. And I'm guessing there may be an extra key for VK_OEM_MINUS on Windows compatible keyboards. If not, then there is Maj. key monitoring to do. There is also dead key processing. Lots of fun decoding the French keyboard.

So if you're expecting to distribute programs to anywhere else in the world, then it's not a good idea to replace TranslateMessage. It handles multiple keyboard layouts, and activates IME in the EDIT box.

[daydreamer]

Comma instead of dot,is just a minor changes for input /output floating point numbers in many languages
Keyboard layout is to type fast many words the way secretary was taught using many fingers,so 3 extra letters in our alphabet has replaced symbols
So asm syntax can be fast typed if you have skill in type words fast
The drawback is c style syntax,most []{}|; () needs altgr, shift and 3 of them have been moved from keys using the extra 3 letters

Its fun exercise with hiragana /katakana, and Chinese numbers, but you need been brought up in Japan, China,Korea, to be able to write. IME handler for 30k unicode characters