Wm_keydown-> call translatemessage-> wm_char-> wm_keyup to analyze wm_char

There are so many keyboard messages in the application from wm_keyfirst to wm_keylast, but we know the most primitive keyboard messages.
There are only two messages: wm_keydown and wm_keyup. we can intercept these two messages in the keyboard hook. Then, where do other messages come from and how do they work? Next we will
Analyze the wm_char message.

After a key is pressed, one or more wm_keydown messages are generated. These messages are sent from the system message queue to the Message Queue of the thread in the target window, in this way, when the corresponding thread processes the message, it will process the message and generate a series of other keyboard messages, including wm_char.

The following is a part of the processing process of entering 'A' in the edit box of the dialog box (it is obtained through the source code debugging and sorting)

Cgetinputdlg: domodal () // create a dialog box

Press 'A' in the edit box'

001 cgetinputdlg: runmodalloop // message loop. Here, peek to wm_keydown

002 cgetinputdlg: pumpmessage // message pump, which obtains, translates, and processes messages.

003 cgetinputdlg: pretranslatemessage // The thread starts message preprocessing.

004 cgetinputdlg: Repeated pretranslatetree // calendar from the target window to the Main Window

005 cmyedit: pretranslatemessage // target window, not processed (false is returned ).

006 cgetinputdlg: pretranslatemessage // The Child window is not processed, so it is routed to the parent window.

007 cdialogdlg: pretranslatemessage // processed by the base class

...

008 cmyedit: windowproc

009 cmyedit: onwndmsg

010 cmyedit: onkeydown

011 cmyedit: defwindowproc

012 cgetinputdlg: runmodalloop // here peek to wm_char, but there are usually several wm_kickidle

...

Some people will say that this does not indicate that wm_char is generated during wm_keydown message processing. This only indicates that wm_char is generated after wm_keydown. Well, let's take a look at the following.

These are the debugging output information in the source code ~~ Indicates the entry of the corresponding function ~~ Indicates the return point of a function. The value after MSG is the hexadecimal value of the message.
(Wm_keydown = 0x100, wm_keyup = 0x101,
Wm_char = 0x102). havecharmsg indicates whether wm_char messages exist in the Message Queue (implemented by peekmessage)

Enter 'A' in English. The debugging information is as follows:

Corresponding to 005

101 cmyedit: pretranslatemessage MSG = 100, havecharmsg = 0

102 ~~ Cmyedit: pretranslatemessage MSG = 100, havecharmsg = 0, ret = 0

Corresponding to 006

103 cgetinputdlg: pretranslatemessage MSG = 100, havecharmsg = 0

105 cmyedit: onkeydown havecharmsg = 1

106 cmyedit: defwindowproc MSG = 100, havecharmsg = 1

107 ~~ Cmyedit: defwindowproc MSG = 100, havecharmsg = 1, ret = 1

108 ~~ Cmyedit: onkeydown havecharmsg = 1

109 ~~ Cgetinputdlg: pretranslatemessage MSG = 100, havecharmsg = 1, ret = 1

110 cmyedit: pretranslatemessage MSG = 102, havecharmsg = 0

111 ~~ Cmyedit: pretranslatemessage MSG = 102, havecharmsg = 0, ret = 0

112 cgetinputdlg: pretranslatemessage MSG = 102, havecharmsg = 0

113 cmyedit: onchar 61

114 cmyedit: defwindowproc MSG = 102, havecharmsg = 0

115 ~~ Cmyedit: defwindowproc MSG = 102, havecharmsg = 0, ret = 1

116 ~~ Cmyedit: onchar 61

117 ~~ Cgetinputdlg: pretranslatemessage MSG = 102, havecharmsg = 0, ret = 1

118 cmyedit: pretranslatemessage MSG = 101, havecharmsg = 0

119 ~~ Cmyedit: pretranslatemessage MSG = 101, havecharmsg = 0, ret = 0

120 cgetinputdlg: pretranslatemessage MSG = 101, havecharmsg = 0

121 cmyedit: onkeyup

122 cmyedit: defwindowproc MSG = 101, havecharmsg = 0

123 ~~ Cmyedit: defwindowproc MSG = 101, havecharmsg = 0, ret = 0

124 ~~ Cmyedit: onkeyup

125 ~~ Cgetinputdlg: pretranslatemessage MSG = 101, havecharmsg = 0, ret = 1

Have you seen it? Wm_char elimination is generated in cgetinputdlg: pretranslatemessage of section 103 (corresponding to processing process 006)
And put it in the message queue. It can be seen that the message is indeed generated during the wm_keydown process. After wm_keydown is processed, the message loop detects it and
Get it in pumpmessage and enter the corresponding processing of 110. In this case, no wm_char message exists in the queue.

Yeah, no. In many cases, doesn't translatemessage generate wm_char messages? They mean that

: Translatemessage (& m_msgcur), which is simplified as follows:

200 bool cwinthread: pumpmessage () (cgetinputdlg: pumpmessage)

201 {

202 assert_valid (this );

203 If (! : Getmessage (& m_msgcur, null ))

204 return false;

205 // process this message

206 if (m_msgcur.message! = Wm_kickidle &&! Pretranslatemessage (& m_msgcur ))

207 {

208: translatemessage (& m_msgcur );

209: dispatchmessage (& m_msgcur );

210}

211 return true;

212}

It can be seen that only when pretranslatemessage (cgetinputdlg: :) returns false will the corresponding function at location 208 be executed.
We can see from 103 that cgetinputdlg: pretranslatemessage has not returned, and wm_char message is available, and
From ~~ Cgetinputdlg: pretranslatemessage it can be seen that pretranslatemessage returns 1 and does not execute 208,
209. Are those statements wrong?

Not necessarily. If he is referring to the dialog box program, I think he is indeed wrong, but it is correct for non-dialog programs. I created an SDI job
In pretranslatemessage, if the non-accelerated key is added as FALs, 208,
209. : Translatemessage (& m_msgcur) to translate keyboard messages. Of course, if I want to pretranslatemessage
By default, the system finally calls the translatemessage to complete the translation, but it does not correspond to the code at 208.

This is almost the case now, but I would like to remind you that if you set breakpoints (such as onkeydown) in some functions during verification, and then press the key to enter, at this time, it will stop at the breakpoint, and then you run it again, then some different results will be obtained. The message wm_keyup is missing because the form for receiving the message wm_keyup is the debugger.