1, thread is divided into UI thread and worker thread, UI thread has a window, the window has built a message queue, the UI thread maintenance “message queue”, “message queue” is the biggest difference between the interface thread and worker thread. So the UI thread with a user interface is generally called the UI thread, and the worker thread without an interface is called the worker thread. Because the UI thread has an interface, the system will maintain a message queue for it, and the worker thread has no message queue. 2, The worker thread does not have a message queue, but you can force to add a message queue, usually as long as there is a GDI call in your thread will appear a message queue, if the thread called GetMessage(), can force to join a message loop, the system will add a message queue to the thread, also using PeekMess Age () can also force the system to join a message queue. Worker thread messaging is sent through the PostThreadMessage function. That is, if a worker thread function calls a message function, the operating system automatically creates a message queue for the worker line.
\
3. So-called UI threads have Windows that create their own message queues. The so-called worker thread initial state has no self-built message queue.
\
4. UI thread message processing
Only when using the MFC framework is there a distinction between UI threads and worker threads. The UI thread differs from the worker thread in that the operating system creates and maintains a message queue for the UI thread. Threads are actually worker threads when they are created (either API or MFC). The system creates a message queue and THREADINFO structure for a thread when it calls a function that sends or retrieves a message or is associated with a graphical user interface. The main thread of the CONSOLE program developed by VC is the working thread, and the main thread of other programs is the UI thread. _beginthreadex/CreateThread function creates a thread, such as the default for the worker thread, AfxBeginThread worker threads can be created according to the parameters and the UI thread. (1) From user input to system message queue The operating system will monitor the computer keyboard and mouse and other input devices, for each input event to generate a message, the message unified temporarily into the “system message queue”. The window handle of the message is calculated by the system according to the mouse or cursor area. (2) from the system message queue to the thread message queue the system has a special thread is responsible for taking out the message from the system message queue, according to the target object of the message (window handle), the message will be delivered to the UI thread that created it corresponding message queue. Each UI thread has one and only one message queue. (3) the UI thread to handle the Message UI thread start a Message Loop (Message Loop), each time from the corresponding Message queue in this thread to retrieve a Message, and then based on Message containing information, will forward it to the specific form, the form object that corresponds to the process of “form” of the function is called to process these messages. MSG msg; // represents a message BOOL bRet; While ((bRet = GetMessage(& MSG, NULL, 0, 0))! = 0) {if (bRet == -1) {} else {TranslateMessage(&msg); DispatchMessage(&msg); }} GetMessage() waits for a message to return, peekMessage () returns a message or null value immediately; GetMessage() gets the message and removes it from the queue (except for WM_PAINT), while PeekMessage () decides whether to remove it based on the PM_NOREMOVE or PM_REMOVE arguments. The TranslateMessage() function is mainly used to convert WM_KEYDOWN and WM_KEYUP messages into WM_CHAR messages. So if you want to intercept WM_KEYDOWN and WM_KEYUP messages, you need to override the PreTranslateMessage() function of the forms class for analysis. The DispatchMessage() function forwards the message to the window object referenced by the window handle contained in the retrieved message. The function responsible for responding to the message is called Window Procedure. If custom processing is required, override the DefWindowProc() function of the form class. A window procedure is a function, one per window, of the form: LRESULT CALLBACK MainWndProc(…) {/ /… Switch (uMsg) {case WM_CREATE: // Initializes the form. Return 0; Case WM_PAINT: // Return 0; // // Process other messages // default: // Go to the system default message processing function return DefWindowProc(HWND, uMsg, wParam, lParam); } / /… } \