Thoughts on messages from Timer control to Windows

The problem is first caused by the timer control of VB. We all know that VB does not support multithreading, but the timer control gives us the illusion that a timer control

Is a thread, and the timer control is parallel. At first, I thought so, but a simpleCodeEverything.

The Code is as follows:

 

 
Option explicitdim I as long, J as longprivate sub command1_click () dim X as doublefor I = 1 to 1000000 x = sin (2) /I doeventsnext IIF I = 1000001 then msgbox "AAA" End subprivate sub form_load () timer1.interval = 10timer1. enabled = trueend subprivate sub timer1_timer () If I <> 0 then print "clock event start:" & IFOR j = 1 to 1000 J = jnext Jif I <> 0 then print ", clock event ended: "& iend sub
 

 

The running result is as follows:

 

Next we will analyze the Code. In the Click Event of a button, it is a time-consuming loop (to delay the time, let us have enough time to test), in the loop doeventsIs to transfer control in each loop, used to detect whether there are other waiting messages. If I = 1000001 then msgbox "AAA"Indicates the completion of the loop (the loop has been completed after the sequential execution ). In TimerThe event also has a time-consuming cycle, with the detection I at the beginning and end of the loop respectively.Value Statement.

We found thatAfter the value of the IIs the same as before the loop:Clock eventsProgramThe execution starts and ends until the execution ends. The program that is originally in the loop will stop. That is, when the clock event program starts, the variable value of the originally executed loop will be equal to the value at the end of the clock event program, that is, the loop that is being executed does not continue.

If the doeventsComment out, then click the event (loop) will not hand over the control, thenAfter the entire click event endsTimer will be triggeredEvent, result

 

 

The above example proves that timerEvents are serialized rather than parallel events.CPU usage within a period of timeOnly one program can be processed,Time sliceFast switching between different programs,Form a "TimerMultithreading ".Just like a chess master who wants to play chess with ten people at the same time, ten boards are lined up, and the chess master goes down in front of ten boards like a horse lamp until the next ten board games are completed. The chess master is the CPUTen game board games are ten threads (Or process)Task.

If we continue to investigate the cause,WindowsMessage.

The message loop process is roughly(Message Details are not described)

1. The message loop calls getmessage () to find and process messages from the message queue. If the message queue is empty, the program stops running and waits (Program blocking ).

2. when an event occurs, a message is added to the Message Queue (for example, if the system registers a mouse click event). getmessage () returns a positive value, indicating that a message needs to be processed, the message has been filled in the input msg parameter; 0 is returned when the wm_quit message is passed in; if the returned value is negative, an error occurs.
3. Retrieve the message (in the MSG variable) and pass it to the translatemessage () function. This function performs some additional processing: converts the virtual key value information to the character information. This step is actually optional, but needs to be used in some places.
4. After the preceding steps are completed, the message is passed to the dispatchmessage () function. The dispatchmessage () function distributes messages to the target window of the message, finds the process function of the target window, transmits window handle, message, wparam, lparam, and other parameters to the window process function, and then calls this function.
5. Check the message and other parameters in the window procedure function. You can use it to implement the operation you want. If you do not want to process some special messages, you should always call the defwindowproc () function, and the system will process these messages in the default way (usually not doing any operation ).
6. Once a message is processed, the window process function returns, the dispatchmessage () function returns, and the next message continues to be processed cyclically.

With this foundation, we canA more essential view of this problem:

The loop in the click event is transferred to control (this process is very fast), so the getmessage () function can be called,This causes the getmessage () function to "always exist ". However, Timer the control is for every 10 Run Once in milliseconds (that is, enter the message queue every 10 once in milliseconds ), therefore, this message can be found every 10 milliseconds, and a message loop is successfully completed. This achieves the effect of "timer multithreading. After careful observation, we can find that any two adjacent timer I incremental values are roughly the same , it is even more powerful proof that the timing of timer is always ongoing, every 10 enter the queue once in milliseconds. this provides a good foundation for doevents when you click the Remove button in the event loop, at this time, the timer for timer is still in progress. However, the function cannot be called because the click event does not have control, at this time, the dispatchmessage () function cannot return (because message processing is not completed). timer when a message enters the queue, there is no response until the timer event is triggered after the event is processed.

Note: I suddenly found a problem. In the first case, why is the button loop willing to wait until the cycle in the timer is executed and then executed? Because doevents! There are doevents in the button loop, which can check whether there are other messages. If there is no doevents In the timer loop, it will occupy the CPU until the cycle is completed. That is to say, if one time slice is insufficient, the CPU will be given again.