ML64 message pump using a jump table ....................
i thought id try a variation of the message loop inspired by an example program [not this example didnt have editable fields ]
the edit fields are provided with defaults and every thing works fine .. except [detailed later ]
im interested to know if anyone has tried anything like this and can provide some insight
i tried setting up a version of a simple GCD program with a slightly different message pump which i think derived from a 64 bit example
[though im not sure where this came from)
sketch of message pump
????????????????????? initialisation ???????????????????????
; ---------------------------------------------------------------
; fill array with address of default processing label in WndProc
; ---------------------------------------------------------------
mov rdi_save, rdi
mov rdi, OFFSET wMsgs ; array address
mov rax, OFFSET DEF_MSG_HANDLER ; default processing label in WndProc
mov rcx, 800h ; WM messages up to WM_USER
rep stosq
mov rdi, rdi_save
; ----------------------------------------------
; write address of each procedure
; associated with a message to process
; ----------------------------------------------
mov rax, OFFSET wMsgs
; SetAddress WM_COMMAND
lea rbx,WM_COMMAND_EVENT ; these being procs
mov [rax+WM_COMMAND*8], rbx
lea rbx,WM_CLEAR_EVENT ; these being procs
mov [rax+WM_CLEAR*8], rbx
lea ......
..................
and so on for each event you wish to track
????????????????????????????????????????????????????????????
message loop
.....
xor rsi, rsi
lea rdi, msg
jmp @F
align 10h
StartLoop:
mov rcx,rdi
call DispatchMessage ; equivalent invoke DispatchMessage,rdi
@@:
mov rcx,rdi
mov rdx, rsi
mov r8, rsi
mov r9, rsi
call GetMessage ; equivalent invoke GetMessage,rdi,rsi,rsi,rsi
cmp rax, rsi ; exit on zero
jne StartLoop
......
?????????????????????????????????????????????????????????????????????????????????????
******************************************************************************************
*for comparison a traditional message loop [i think this is one of your examples Hutch ]
*
* mov pmsg, ptr$(msg) ; get the msg structure address
* jmp gmsg ; jump directly to GetMessage()
*align 10h
* mloop:
* invoke TranslateMessage,pmsg
* invoke DispatchMessage,pmsg
*align 10h
* gmsg:
* test rax, rv(GetMessage,pmsg,0,0,0) ; loop until GetMessage returns zero
* jnz mloop
********************************************************************************************
rest of modified pump
????????????????????????????????????????????????
WndProc proc hWin :QWORD,
uMsg :QWORD,
wParam :QWORD,
lParam :QWORD
cmp uMsg, 1023 ; don't process messages about 1023
jg @F
mov rax, uMsg
mov rcx, hWin
mov rdx, uMsg
mov r8, wParam
mov r9, lParam
call QWORD PTR [wMsgs+rax*8] ;use array as jump table .. there are only 1K messages although a couple of WM_USER messages prob fall outside this]
@@
.....................
???????????????????????????????????????????????
example procs
WM_COMMAND_EVENT proc hWin:QWORD,uMsg:QWORD,wParam:QWORD,lParam:QWORD
.switch wParam
.case 300 ; reset list box
mov rcx, hList[0]
mov rdx, LB_RESETCONTENT
mov r8, 0
mov r9, 0
call SendMessage
mov rcx, hList[0]
mov rdx,LB_SETHORIZONTALEXTENT
mov r8, 14000
mov r9, 0
call SendMessage
.case 301 ; calculate gcd
call MakeEuclid demonstrate gcd
..............
.....
mov rcx,hWin
mov rdx,uMsg
mov r8 , wParam
mov r9,lParam
call DefWindowProc
WM_COMMAND_EVENT_end:
ret
WM_COMMAND_EVENT endp
align 10h
DEF_MSG_HANDLER proc hWin:QWORD,uMsg:QWORD,wParam:QWORD,lParam:QWORD
mov rcx,hWin
mov rdx,uMsg
mov r8 , wParam
mov r9,lParam
call DefWindowProc
DEF_MSG_HANDLER_end:
ret
DEF_MSG_HANDLER endp
WM_SETFOCUS_EVENT proc hWin:QWORD,uMsg:QWORD,wParam:QWORD,lParam:QWORD
invoke MessageBox,hWin,ADDR szMessSetfocus,ADDR szMessTitle,MB_OK
; mov rcx,hWin
; mov rdx,HWND_TOP
; mov r8 , 0
; mov r9,0
; mov rax,sWid
; mov [rsp+20h],rax
; mov rax,sHgt
; mov [rsp+28h],rax
; mov rax,SWP_SHOWWINDOW
; mov [rsp+30h],rax
; xor rax, rax ; not sure about this but think it has to be 16 aligned
; mov [rsp+38h],rax
; call SetWindowPos ; this would be equivalent to invoke SetWindowPos,hWin,hWin_TOP,0,0,sWid,sHgt,SWP_SHOWWINDOW
but i took it out and just let the window follow a standard path
mov rcx,hWin
mov rdx,uMsg
mov r8 , wParam
mov r9,lParam
call DefWindowProc
xor rax, rax
WM_SETFOCUS_EVENT_end:
ret
WM_SETFOCUS_EVENT endp
and so on
???????????????????????????????????????????????????????????????????????????????????????????????????
end of snippets of program
???????????????????????????????????????????????????????????????????????????????????????????????????
now the traditional message pump works fine
with the jump table look up version ....
i can no longer edit details in edit boxes ..[the cursor on placement throws a WM_COMMAND message .. as per note below ]
obviously tracing exactly what TranslateMessage is doing in this instance is not easy due to
1) the volume of paint, sizing, etc etc messages which it is handling unseen for the most part
2) i only know that the entry into the edit box is entering the pump with a WM_COMMAND [111]
which sort of surprised me a little but dont really know why the edit fields are now uneditable
[ not entirely true as you can paste into them !! a bit like on cmd.exe] unless translate message
is doing the something i want to know about ... i also have a sneaky feeling that i might get into
trouble with threading but thats for another time
if you havent tried this DONT RESPOND with a load of questions as its pointless
i only want to know if anyones done it
i could post the whole program if no one has any idea but then i might as well sort it myself
... but im sure someone already knows the answer
regards
Mike B
Mike,
I did one somewhere over 20 years ago for a WndProc() which was simple enough as almost all messages are under 1000 and it was done with a lookup table. Every message in the WndProc() was pointed at the correct location in about 3 instructions and while it did work OK, you could not tell the difference.
Quote from: hutch-- on December 23, 2020, 12:19:08 PMyou could not tell the difference
We had several threads about Switch ... Case ... Endswitch implemented as if else endif vs jump tables. The latter rarely have an advantage. Practically all Windows messages are very slow, so a few cycles more
in if else endif are not significant.
great answers thanks ....
yes thanks Hutch
everything works as it should EXCEPT the edit where its as though id set ES_READONLY [which i havent ] and it was annoying me
the odd thing is that you can amend them by pasting into them .. delete chars using the delete on the keyboard so i was a bit bemused by it
all the other controls work as they shd .. ive got a list box which you can fill beyong the scroll limit and the scroll bars work ok etc etc .. all the buttons [which go through WM_COMMAND obviously are ok .. its so odd
but
i must say it doesnt seem quicker
which bears out what youve said JJ ...
.. ill not bother then ..
i was hoping to somehow speed up the loop so if anyones got any ideas [peek message cant be any quicker i wouldnt have thought either ????]
regards mike b
If you look at the architecture of a Windows UI, either 32 or 64 bit does not matter, the speed limit from a message loop feeding messages to a WndProc is determined by the OS which in turn is dependent on what the window is doing, moved, resized or receiving messages from another source and about the only way you can "hot it up" is by getting the WndProc processing of messages sent by the OS in the lowest number of instructions.
I see such endeavours as virtuous as you learn a lot about efficiency but with a normal UI app, you won't see any difference. There are other tasks where a lookup table of labels with the instruction count for branching to each label is only a few instructions will give some very good performance gains if done properly so no research work is ever wasted.
Quote from: hutch-- on December 23, 2020, 03:05:45 PM... so no research work is ever wasted.
Amen, that's exactly the right spirit for an Assembly forum :bgrin:
Besides, Mike, it is important to realise what the message pump really does: most of the time
nothing. If there is no user input, it just waits for some action. No need to speed up the waiting :cool:
thanks to you both and i can thoroughly endorse the WISDOM with which youve replied .. i put a series of displays in the program .. and was thus able to sort of see events and gradually filter and count aspects of the window activity .. the bulk of it is in maintaining an accurate notion of the position of the cursor and similar relative to the client window area .. some surprises were that the WM_IME_.. messages figure at all !! theyre quite important
[ i dont know why but i hadnt expected it] ..
in fact if you think its a good idea ill post the code [im not using quite the sytem everybodys prob using in that ive gone for a mash up of the stuff MIKL VERY KINDLY SENT ME AGES AGO [massive thanks MIKL ] and yours HUTCH [ so massive thanks to you and your great work on this site enabling us to enjoy assembler ]
and the exe as its quite illuminating ..
also
the command messages come through with the handle of the window /child window in the low part of wParam and the "action" in the high part ... why this isnt being effected for the edit boxes ive yet to discover at the time of writing ..
but thanks for all your help
regards mike b
correction .. NOT handle in the low part of wParam .. the id ..
i didnt reply very well but basically the "action" in the case of the edit child windows is EN_CHANGE and isnt being set except when i paste etc into it .. hope that makes more sense
regards mike b
Quote from: hutch-- on December 23, 2020, 03:05:45 PM
If you look at the architecture of a Windows UI, either 32 or 64 bit does not matter, the speed limit from a message loop feeding messages to a WndProc is determined by the OS which in turn is dependent on what the window is doing, moved, resized or receiving messages from another source and about the only way you can "hot it up" is by getting the WndProc proc
subclassing WM_PAINT and mostly used messages faster?
subclassing uses a pointer to PROC that takes care of WM_PAINT,faster to change pointer to right PROC seldom(area changes) than to different drawing PROC's compared to WM_PAINT(ca 30 fps) with switch/case lvl -1 to 4 different invokes + checking a flag if to draw intro text?
but doesnt it becomes more .COM interface than jumptable?,having indirect jump and adress is changing to right PROC only when needed?
subclass WM_TIMER better when much code?
much mouse control message,I think I going to try mov lParam to X(word) and Y(word) simultanously,because I want to try SIMD moving coding
Magnus,
You don't subclass Windows messages, a subclass is a technique to access the messages sent to a window that does not have a message loop of its own that can be directly accessed. A subclass is a trick to intercept the messages to a window of that type, (mainly a control), process what you need within the subclass then pass the procedure's address back to the OS for default processing.
If you want a particular message to have priority over ordinary default messages, you put it up near the top of your WndProc.
A timer is an OS provided technique that runs in its own thread that sends messages to your Wndproc at user defined intervals. They work OK for ordinary things but are too slow for high frame rate code and this is where you need to use a multi-media timer that can have a resolution down to 1ms but if you need faster again you start using spinlocks and high precision timers and this stuff starts to get complicated.
Quote from: hutch-- on December 24, 2020, 07:03:56 PM
A timer is an OS provided technique that runs in its own thread that sends messages to your Wndproc
I had never thought about it that way, but it sounds very logical - thanks :thumbsup:
You can actually make your own timer, create a thread, run a loop in it that uses intervals of your choice, slow stuff can use GetTickCount() while much faster stuff can use much higher speed techniques but you will probably run into a boundary of how fast you can send messages as they get passed through the OS.
Quote from: hutch-- on December 24, 2020, 07:03:56 PM
You don't subclass Windows messages, a subclass is a technique to access the messages sent to a window that does not have a message loop of its own that can be directly accessed. A subclass is a trick to intercept the messages to a window of that type, (mainly a control), process what you need within the subclass then pass the procedure's address back to the OS for default processing.
I want to try a third way,used .COM interface alot earlier with ddraw,d3d,so replacing lots of switch/case to call different area drawing PROC's in WM_PAINT,with a single indirect jmp to current PROC and seldom decision change code of areas moved elsewhere and only changes pointer to different PROC,so is all you need some LOCK prefix for mov that changes jmp adresses,to not crash?
look at current code and its adding new areas all the time
.IF introflag==0
switch lvl
case -1
call road ;on the road to different places
case 0
; call paint2
call labdraw0 ;ground lvl
case 1
;call paint2
call labdraw
case 2
call labdraw2
case 4
call queen
endsw
.ENDIF
.IF introflag!=0
call intro
Quote from: mikeburr on December 23, 2020, 01:56:00 PM
everything works as it should EXCEPT the edit where its as though id set ES_READONLY [which i havent ] and it was annoying me
Your message pump doesn't call TranslateMessage. That's needed to create the WM_CHAR messages needed by EDIT controls for character input.
thats correct ..... we know that ...and ????
ok maybe i shd point out whats happening ... WM_CHAR isnt going to trap anything ...the messages come through WM_COMMAND ..high part of wParam set to 100 EN_PLEASE_DONT CHANGE ME what i tried and this did indeed set it for update .. was to intercept and change the param with EN_UPDATE [400] .. which will reset it .. [its all going throughthe default handler but despite now coming back with wParam high word 0
BUT i still couldnt update [ ive got traps on various things including mouse tracking and key tracking as sections ..just in case which was very unlikely as i put a comprehensive filter which writes to a list box of all relevant messages .] .. there are several things to remeber here .. the Edit is a sub class of the main window in this case and prob in most cases ...[hence Hutchs reply earier ie the message for an edit box come through with hWnd as per main thread / window [hence my earlier comment about maybe running into threading problems ] there were several things of interest .. when i entered the edit box the system issued some _IME_ messages .. these are associated with wide char usually which arent set on here ... my includes etc are asci only as its only me thats running the stuff [although i did deliberately load and call messagebox wide as an experiment once and found that i could instantly speak Chinese or similar which was quite funny...].
The Real Point is that its no faster there were no obvious gains as the program still worked if you pasted stuff into the edit boxes but as pointed out previously [hence the request to people that had tried something similar ] you cant escape a long wait at the station because there arent any trains .....
regards mike b
Mike,
tenkey's point is a good one, make you message loop according to Windows specification and everything that should end up being pointed at the WndProc will get there. The message loop for an application is actually a blocking loop and if there are no messages waiting to be processed for that application process, it just sits there waiting for the next message to come.
; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
msgloop proc
LOCAL msg :MSG
LOCAL pmsg :QWORD
mov pmsg, ptr$(msg) ; get the msg structure address
jmp gmsg ; jump directly to GetMessage()
mloop:
rcall TranslateMessage,pmsg
rcall DispatchMessage,pmsg
gmsg:
test rax, rvcall(GetMessage,pmsg,0,0,0) ; loop until GetMessage returns zero
jnz mloop
ret
msgloop endp
; ¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤¤
You can directly process key strokes in the message loop as you get them when they come in with no 1 character lag.
old advice was to replace getmessage with peekmessage and run code if no messages,but if too much processing here,delayed wndproc message handling,thats one reason I want to change to use secondary thread for that code,instead,for modern multicore cpus
but with new knowledge,switch/case of the most important control keys to get fast response ,place call to keyboard handler PROC directly after detecting some keyboard message after translatemessage?
example code
;how do I 64bit version?
invoke TranslateMessage, ADDR msg
mov eax, hWnd
.if msg.hwnd == eax
.if msg.message == WM_KEYUP
.if msg.wParam == VK_F1
invoke MessageBox,hWnd,
chr$(34,"now we change to fullscreen",34),
ADDR szDisplayName,MB_OK
invoke ChangeScreenResolution,screenw,screenh,32
.endif
Quote from: daydreamer on December 31, 2020, 06:03:56 PM
old advice was to replace getmessage with peekmessage
With 100% cpu use? Who gave that advice?
:biggrin:
You can forget that one Magnus, its a terrible technique from people who did not have a clue. If you really want to do "smarties", process key and mouse directly in the message loop, either before or after TranslateMessage() and/or DispatchMessage() depending on what you need to do.
hutch
i have several examples i wrote where i did exactly that .. ie process the key messages in the loop ... what i was trying to do was find out if i got rid of Translate message if this was slowing the process considerably .. but it doesnt seem to be .. so im still none the wiser as to Exactly what it does .. i was hoping that some body would post the Logic i guess .. as youll see in the original post i contrasted it with exactly the standard loop youve posted ... it prob doesnt matter now anyway
regards mike b
Quote from: mikeburr on January 01, 2021, 12:47:28 PMso im still none the wiser as to Exactly what it does .. i was hoping that some body would post the Logic
Quote from: tenkey on December 31, 2020, 02:34:50 AM
Quote from: mikeburr on December 23, 2020, 01:56:00 PM
everything works as it should EXCEPT the edit where its as though id set ES_READONLY [which i havent ] and it was annoying me
Your message pump doesn't call TranslateMessage. That's needed to create the WM_CHAR messages needed by EDIT controls for character input.
Quote from: mikeburr
why this isnt being effected for the edit boxes ive yet to discover at the time of writing ..
The edit box is a window that has it's own WndProc (called by DispatchMessage) that traps and processes WM_CHAR messages for character keypresses. When the edit box WndProc receives this message, it redraws the edit box to show the new character. You need to call TranslateMessage to make the edit box accept characters from the keyboard.
At https://docs.microsoft.com/en-us/windows/win32/inputdev/keyboard-input there is a description of the WM_CHAR message.
yes thanks ... i know this ...what im trying to find out is how translate message does this ...ie ...what is the logic ...and therefore could i obviate it easily .. [as you can do by trapping the char controls in the message pump ].. i tried to reset the the EN_change in wParam [and effectively repaint the screen] sending the output via default message as a fix ... im not sure if im getting what i was trying out very well ....
regards mike b
Mike,
The main basic functions of getting a working window onto the screen is tied directly to the mechanics of Windows. What you have at this very basic level is boilerplate code, the bare bones of what needs to be done to create a window that will display on the screen. Once you have done this you can add menus, toolbars, any of a whole host of controls to do whatever you like.
Now tenkey has made a point that is important for you to understand, every window has its own message loop, some are easily accessed while others need a subclass to get access at the messages being passed to it by the operating system. Most messages are handled by the DEFAULT windows technique but you have access at these subclasses so you can interact with or alter messages sent to any specific window.
Something I have always done with either a new language OR a new OS version is to create a template that is the bare bones of a working window. This way you know the basics of how the window works and you can then add to it in whatever way you like, as long as you can get it to work. Start from the bottom and you will know why you do certain things.
Quote from: mikeburr on January 01, 2021, 03:31:22 PM
what im trying to find out is how translate message does this ...ie ...what is the logic ...and therefore could i obviate it easily
I don't know how much of TranslateMessage you want to replicate. A list of available keyboard information is in
https://docs.microsoft.com/en-us/windows/win32/inputdev/about-keyboard-input
There are links to other info such as the WM_KEYDOWN message and the virtual key codes.
Quote from: tenkey on January 02, 2021, 12:29:57 PM
Quote from: mikeburr on January 01, 2021, 03:31:22 PM
what im trying to find out is how translate message does this ...ie ...what is the logic ...and therefore could i obviate it easily
I don't know how much of TranslateMessage you want to replicate. A list of available keyboard information is in
https://docs.microsoft.com/en-us/windows/win32/inputdev/about-keyboard-input
There are links to other info such as the WM_KEYDOWN message and the virtual key codes.
I have a proc that takes care of all vk codes, don't think it's much difference call it in wm_keydown in wndproc switch/case or directly insert invoke keyboard handler after translatemessage
But I take advantage of make alternative mouse control , like
vm_rbuttondown :
Invoke keyb,vk_enter
Do you use TranslateMessage with your vk handler? The edit boxes won't work properly without the new message generated by TranslateMessage. The equivalent code (to TranslateMessage) will need to track the shift keys and then PostMessage the new message to the window handle retrieved from GetMessage's lpMsg. Other considerations include keyboard layout of non-letters and non-Latin keyboards.
yes thanks tenkey et al .. i couls either just declare the Edit boxes as UNEDIT class ..or whatever name i chose ... or superclass the lot which is easier
it happens
i prob havent explained the objectives but i have very limited input data [ onlt numbers in edit boxes ...
and about 6 windows on my skeleton program each of which runs in its own thread and is largely menu driven .. the menus are built from a CSV file
im creating the windows using a CSV file so create file is totaly generic .. each window is held as a template in heap allocated storage and the edit boex for each
[ there are about 30 - 40 functions on some windows so potentialy a lot of "boxes" ] the boxes are doubly linked to the window definitions in separate heaps
storage
im just working on relocation of the boxes [ and thus restructuring of the windows now i have some spare time so think of a resource definition program except its embedded in the program and redifned by merely changing theheap definitions and reshowing [i dont physically delete just mark btw but the need to deete is fairly rare
its very good for building the windowing side quickly as you can experiment with things like cursors etc quicky so i can tell you for instance that about 10 cursors are missing from your windows includes [32652 - 32661 ?? the last one displays a cd .. etc
the reason i asked the translate message is because i might use the NTDLL & GDI primitives [some GUI functions] as i want to make one of the screens a sort of graphic implementation a bit like euclidean geometry resulting from the calculations etc etc .. so while i was at it i thought id look through translate dispatch
what a can of worms .. every bloody syscall changes with virtually every new variant of the OP SYS .. i think MS must have gone nuts thinking that this would stop IDIOTS hacking things like the OEM keyboard functions etc etc
it involved a long and tedious search through the obscurities of "translate message ... USER32" and ... NTDLL etc etc and im still not sure yet what im going to do
but thanks for your help // i was just hoping for something a little more "in depth" // .. i ought to point out that the system makes considerable use of FS and the 0x18 TEB .. i can understand why as i pointed out in my first post theres threading issues need to be thought through .. but this cant help the system as its a bottleneck for sure .. there are quite a lot of other things going on that considerably slow the raw machine ... there good but sometimes you want to chuck the bodywork of a car away or take the tank and wife off the back of your motor bike to make it go a lot faster #
regards mike b
ps i havent read this through to check it so im afraid its prob a bit scrambled
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).
Quote from: tenkey on January 12, 2021, 02:19:13 PM
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 ?
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.
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
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
Quote from: mikeburr on January 21, 2021, 05:08:44 AMM$ way of internally inhibiting input
The M$ way is to intercept the WM_KEYDOWN, WM_KEYUP and WM_CHAR messages in a subclass WndProc.
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
Quote from: mikeburr on January 21, 2021, 05:08:44 AM
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:
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.
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
thanks tenkey,great work :thumbsup:
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
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.
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