Handle thread to do arguments and postmessage usage

We should do this when we start a thread, and the parameter to pass to the thread function is the window handle:

HWND Hhwnd = GetSafeHwnd ();

HANDLE Hthread;

DWORd dwThreadID;

Hthread =:: CreateThread (NULL, 0, (Lpthread_start_routine) Deviceonline, (LPVOID) hhwnd, 0, &dwthreadid);

Deviceonline is a thread function, the prototype static UINT deviceonline (LPVOID pparam);

Note: The form of the parameter is such (LPVOID) Hhwnd, no address symbol, note ah! Why should the argument be passed a handle? (yes, why?) Should be for us to make the threading function and the main thread communicate, to use the PostMessage (...) function, so to talk about The message mechanism for Windows.

----------------------- The following is the Windows messaging mechanism

The Windows system is a message-driven OS, what is a message? I can hardly understand, it is difficult to define the next (who is peeing me), I would like to explain the following from a few different aspects, I hope you see a little understanding.

1, the composition of the message: A message consists of a message name (UINT), and two parameters (WPARAM,LPARAM). The system sends a message to a window when the user enters or changes the state of the window. For example, when a menu is transferred, a wm_command message is sent, andWPARAM (hiword (WPARAM)) is the command's ID number, which is the menu ID for the menu . Of course, users can also define their own message names, or they can use custom messages to send notifications and transfer data.

2. Who will receive the message: A message must be received by a window. In the process of the window (WNDPROC), the message can be parsed, and the messages that are of interest to you are processed. For example, if you want to process the menu selection, you can define the code to process the WM_COMMAND, and if you want to do the graphics output in the window, you must process the WM_PAINT .

3. Theunhandled message went there:m$ has written the default window procedure for Windows, and this window process will be responsible for handling messages that you do not process. It is because of this default window procedure that we can exploit windows to develop without paying too much attention to the processing of various messages in the window. For example, when a window is being dragged, a lot of messages are sent, and we can ignore it and let the system handle it on its own.

4, Window handle: When it comes to the message, you can not say the window handle, the system through the window handle to uniquely identify a window throughout the system, send a message must specify a window handle indicating that the message is received by that window. Each window will have its own window process, so the user's input will be handled correctly. For example, there are two windows that share a window procedure code, and when you press the mouse on one of the windows, the message is sent through a handle to window one instead of window two.

5. Example: There is a pseudo-code below that shows how to process messages in a window procedure

LONG Yourwndproc (HWND hwnd,uint umessagetype,wparam Wp,lparam)

{

Switch (umessagetype)

{//Use a switch statement to separate various messages

Case (WM_PAINT):

Doyourwindow (...); /output when the window needs to be redrawn

Break

Case (WM_LBUTTONDOWN):

Doyourwork (...); /processing when the left mouse button is pressed

Break

Default

Calldefaultwndproc (...); /For other situations, let the system handle itself

Break

}

}

next talk about what a message mechanism is: the system will maintain one or more message queues, and all the resulting messages will be put back into or inserted into the queue. Each message is taken out of the queue, and the message is sent to the message loop of the program that owns the window, based on the receive handle to the message. Each running program has its own message loop, gets its own message in the loop, and invokes the corresponding window procedure based on the handle of the receive window. In the absence of a message, the message loop gives control to the system so Windows can do multiple tasks at the same time. The following pseudo-code demonstrates the use of a message loop:

while (1)

{

Id=getmessage (...);

if (id = = quit)

Break

TranslateMessage (...);

}

When the program does not have a message notification, GetMessage does not return, and it does not consume the CPU time of the system. For message delivery mode

 

In a 16-bit system, there is only one message queue in the system, so the system must wait for the current task to process the message before it can send the next message to the program, and if a program is stuck in a dead loop or a time-consuming operation, the system will not get control. This multi-tasking system is also known as a collaborative multitasking system. Windows3.x is the system.

and Each program running in the system has a message queue, so the system can be converted in multiple message queues without having to wait for the current program to complete the message processing to gain control. This multi-tasking system is called preemptive multi-tasking system. windows95/nt is the system.

// -------------------------------------------

I don't know, do you remember that thread function? Here is the definition

UINT deviceonline (LPVOID pparam)
{
HWND Hhwnd = (hwnd) Pparam; Conversion Parameters

...

CString str;

Str. Format ("test");

::P ostmessage (Hhwnd, Wm_my_message, (WPARAM) str, NULL); PostMessage to Hhwnd handle

in the case of static type, remember how the static function is used: A version that simply talks to the class without the this pointer.

...

}

If you want to use PostMessage Many times, we can separate a function as follows (because we are using the static thread function, the declaration is also static):

static int AddMessage (HWND hwnd, CString str)
{
if (str. GetLength () <= 0)
return 0;
Char *newmess = new Char[str. GetLength () + 1];
strcpy (NEWMESS,STR);
::P Ostmessage (Hwnd,wm_my_message, (WPARAM) newmess,0);
return 0;
}

Now, we have sent out the information we need, then we have to deal with it, or we still send them why, hehe (nonsense, say it quickly)!

First: Declare the handler function in the class, such as afx_msg LRESULT Addmessageex (WPARAM wpapam, Lpapam lpapam);

Second: in A map is added to the Message map, such as:

Begin_message_map (Ctestdlg, CDialog)

On_message (Wm_my_message, Addmessageex)

End_message_map

Finally, implement the handler function:

LRESULT Ctestdlg::addmessageex (WPARAM WPARAM, LPARAM LPARAM)
{
char* newmsg = (char*) WParam;
if (newmsg = = NULL)
return-1;
.../// Here you can use the message we received, haha! Purpose to complete.

Delete newmsg;
return 0;
}

By the way, there is one thing that is less than the stdafx.h file, add your own defined message

#define Wm_my_message (wm_user+123)

Original address: http://blog.chinaunix.net/uid-20680966-id-1896390.html

The above is reprinted content ************************************** to continue editing ************************** ************************

Handle thread to do arguments and postmessage usage