Forms and threads a ramble on how a worker thread can display the results of data processing to a form

Objective

Originally the title of this blog is called "Form and Thread ramble", but it is not very appropriate to think about it. Since I did not write any theoretical knowledge about forms and threads, I simply explored how the work thread would display the results of the data processing to the form, so it changed the title again.

In addition, the relevant theoretical knowledge about forms and threads. I feel that one or two words are really unclear, and the book "Windows Core Programming" is also very good. Have a chance to write it again. Especially feel today many people are directly learning MFC, with MFC. Even the form process, the message loop is not very clear, it is very valuable to assume such a blog.

Why should we discuss this issue?

Discussion of this is still related to the previous project experience.

For the time being, the project is a project.

A project consists of a client and a server, and the client has a core network module. The network module is based on port development and has multiple worker threads. The network module is responsible for receiving data from the server, processing the data, and displaying the results of the last processing on the form. So the question is, how do the worker threads show the results of the data processing on the form? Being able to say this is not just a problem in Project A. Most Web applications will encounter this problem. The scenario in a project at that time was to use a form handle in a worker thread to directly invoke a corresponding function (such as SendMessage) to manipulate the form.

Although this did not occur at the time of failure? But is it really no problem? If there is a problem, what is the way to show the results of the last processing on the form?

Relationship of forms and threads

Theoretical knowledge is the basis for us to answer the above questions.

The only thing I've found in this area is the Windows Core programming chapter 26th form message.

To the less definite brother of this piece. can look first. We're not going to go into detail here.

Using a form handle in a worker thread to directly invoke a corresponding function to manipulate a form is there a problem

Most of the cases. There is really no failure. But only in the vast majority of cases. The following are the two scenarios in which the failure occurs.

1. This is a situation I personally experienced in project A.

   I called the SetFocus function in the worker thread, and the function did not return successfully, why? The following is a descriptive narrative in the SetFocus documentation.

   Sets the keyboard focus to the specified window. The window must is attached to the calling thread ' s message queue.

   The reason is very obvious. A form handle that is passed to the SetFocus function represents a form that must belong to the thread that called the SetFocus function. However, the worker thread does not own the form, nor does it have any forms. So why call the Setfoucs function to have this requirement? This can only be said I am not clear, but combined with "Windows core programming" in the 26th chapter of the relevant descriptive narrative. Each thread has its own keyboard focus and should answer this question to some extent.

2. In this case, the main interface security processing in multithreaded programming is mentioned in this article, and the general situation is that the thread that owns the form is waiting for the worker thread to exit. The work line is impersonating is blocked in the SendMessage call to the form. It should be said that such a situation is not impossible to happen.

Said so much that I was not recommended to use a form handle directly in a worker thread to invoke the related function on the form process operation, although such practices do not make mistakes in the vast majority of cases, but in the event of failure, it is more difficult to troubleshoot. But I do not completely deny this approach, provided that the program ape itself must be aware of the logic of the program itself, for example, in the worker thread will not invoke similar SetFocus of such functions, will not appear above the other case mentioned above.

How the worker thread will finally display the results of the processing to the form

Since it's not so good to call a related function directly from a form handle in a worker thread, what is the way to display the results of the last processing on the form? My approach is to call PostMessage and process the form procedure by giving the data to the form by defining the message itself. That is, the thread that owns the form is processed. In such cases, the only action that is related to the form in a worker thread is to invoke PostMessage through the form handle. Right now, I don't think there's anything wrong with this approach, assuming that someone thinks there's a problem and we can discuss it together.

Also, let's say that a brother knows better, and we can talk about it.

Feel and think

In the process of finding information about threads and forms. Find that very many people are asking questions about threads and forms, discussing some concepts about forms and threads, and making something very iffy. But actually get some basic knowledge and think about it independently. These questions are not difficult to answer. Perhaps MFC is more convenient than the traditional Win32 API. But the form process. Some basic concepts, such as message loops, are still to be understood.

Forms and threads a ramble on how a worker thread can display the results of data processing to a form