Getting started from VC, I believe everyone is familiar with PretranslateMessage and WindowProc, the former is a message for the pre-processing Windows sent to the control, and the latter is the residual control message. For the PretranslateMessage function, in general, we handle control messages like this:
BOOL TEST :: PretranslateMessage (MSG * PMSG) {IF (PMSG-> hwnd == getsafehwnd ()) {
IF (PMSG-> Message == WM_Mousemove) {m_tooltip.relayeverEvent (PMSG);}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}}
It is divided into two layers, first determined that the message belongs to the control window, and then determines the type of message.
For WindowProc functions, we usually handle control messages such as: LResult Test :: WindowProc (Uint Message, WParam WPARAM, LPARAM LPARAM) {if (Message == WM_SYSCOMMAND) IF (WPARAM == SC_RESTORE) WPARAM = SC_MAXIMIZE;
Return CDialog :: WindowProc (MSSAGE, WPARAM, LPARAM);} This function The processing method for the control message is to send the message to the current control. If not processed, send it to his parent window, if its parent window does not process, It is sent to the current program processing.
In C #, the message processing function changes. For PreProcessMessage functions: We must override this function in the control you need to preprocess messages, and cannot be overloaded only on the parent window. Public override Bool PreprocessMessage (Ref Message MSG) {if (msg.msg == 0x101) {messagebox.show (msg.hwnd.toString ());}
Return Base.PreProcessMessage (REF MSG); Retreat the message mechanism in the VC, allowing other classes to deal with it before a message is sent to a class.
For WndProc (a slight change in VC), it is a slight change) function:
Protected Override Void WndProc (REF MSSAGE MSG) {IF (msg.msg == 0x101) {MessageBox.show (msg.hwnd.tostring ());} Base.WndProc (Ref Msg);}
There is no change in the form of WindowProc in the VC, but only substantially, C # no longer uses a mechanism for message transmission order, as long as the current control does not have a corresponding message processing entry, the message is discarded.
If we want to implement it in the listbox control in C #, click Right-click to pop the menu, you can't use Bool Test :: PretranslateMessage (MSG * PMSG) {if (PMSG-> hwnd == getdlgitem (idc_listbox1) -> getsafehwnd () ) {Switch (pmsg-> message) {copy wm_lbuttonup: ......
}}} Oh, what should I do, ^ _ ^ actually C #, no longer provide only a few events, C # in the rich event, no longer often need a message processing function for some event. , As long as the left and right keys are distinguished in the MouseDown response function of the ListBox control, then different menus are popped up!
But if you want to customize an edit box, you want to intercept some specific keys (such as delete), then the C # rich event is no longer useful, you must first customize a box from TextBox to edit Control, then preprocess it in its preProcessMessage function!
Public override Bool PreprocessMessage (Ref Message MSG) {Keys Keycode = (tent) (int) msg.wparam & keys.keycode; if (msg.msg == 0x101 && keycode == keys.delete) {...}
Return Base.PreProcessMessage (Ref Msg);
The remaining point, I haven't figured out now: the message of the preProcessMessage function is limited: WM_KEYUP, WM_KEYDOWN's messages can be handled, but WM_Close, WM_LButtondown, etc. Unable to process. But WndProc functions can handle them! I don't know if Microsoft deliberately masked the pretreatment of those messages, or there is any other embarrassment!
