Analyzes the reconnection behavior of system. Windows. Forms. timer and the other two timer

If you are not familiar with timer, You can first look at the description of msdn: Timer Server timer, Windows timer, and thread Timer .

To put it simply: System. Windows. Forms. Timer is triggered in Event Mode Based on Windows message loop and executed in the interface thread; System. Timers. Timer is more accurate, triggered in event mode, and executed in the thread pool; System. Threading. Timer is designed to be very lightweight and triggered by callback functions and executed in the thread pool. Concept: The second execution time is reached when an execution is not completed. If the second execution is executed immediately after the first execution, it is called Reimport . Because multithreading is used, system. Timers. timer and system. Threading. timer are re-imported. As you can imagine: 1. the thread that calculates the time should not be the thread that executes the user function; 2. The execution thread will not always be the same. The following focuses on system. Windows. Forms. Timer (wintimer ). Because wintimer is based on Windows message loop, it is obviously for winformProgramSo wintimer is triggered in the interface thread. Theoretically, if the interface thread is blocked, it is impossible to receive the wintimer event.
View Code :

Public   Class Form1: Form
{
Timer =   New Timer ();
Int Num =   0 ;

PublicForm1 ()
{
Timer. Interval= 100;
Timer. tick+ = NewEventhandler (timer_tick );
Timer. Start ();
}

Void Timer_tick ( Object Sender, eventargs E)
{
Num ++ ;
Switch (Num)
{
Case   1 : // First time
System. Threading. thread. Sleep ( 3000 );
Console. Write (Num );
Break ;

case 2 : // second
timer. stop ();
console. write (Num);
Break ;
}< BR >}

Yes, the output window ("debug"-> "window"-> "output") is displayed as: 12So how do you think the following code will be output?

Public   Class Form1: Form
{
Timer =   New Timer ();
Int Num =   0 ;

PublicForm1 ()
{
Timer. Interval= 100;
Timer. tick+ = NewEventhandler (timer_tick );
Timer. Start ();
}

Void Timer_tick ( Object Sender, eventargs E)
{
Num ++ ;
Int Temp = Num;
Switch (Num)
{
Case   1 : // First time
MessageBox. Show (Num. tostring ());
Console. Write (temp );
Break ;

Case 2://Second
Timer. Stop ();
Console. Write (temp );
Break;
}
}
}

Output: 12?No! Run it and you will find that when you see that the pop-up window has not been clicked, the output window has already output 2 When you click "OK" in the pop-up window, the output window will output 1. That is to say, the order is: 21! So we are surprised to find that thread. Sleep can prevent the wintimer event from being triggered again, but MessageBox. Show cannot! Everything has its own cause! This is especially true for programs.
Analysis: Thread. Sleep blocks wintimer because it blocks interface threads. What about MessageBox. Show? It also blocks the interface! From the program running process analysis, MessageBox. Show must wait until we click the "OK" button to execute the next line of code. By following the sentence, we find that the program is actually stopped here. Why can console. Write in Case 2 still run in the middle? Set the breakpoint for the console. Write line code in Case 2. Run. When a breakpoint is hit, open the call Stack window ("debug"-> "window"-> "call stack"). You will see two timer_tick methods. Double-click the timer_tick method below, you will see:
The second timer event was originally in the message. Show method! (If you are interested, open "option"-> "debug"-> enable "only my code" "and check the internal method) The truth is: Although message. Show blocks the code outside, there is still a message loop in it, so the timer event is triggered. Conclusion: when there is no message loop or blocking, The wintimer event cannot be triggered, but as long as there is a message loop in this thread, wintimer can be triggered normally. Thread. Sleep and any code without a message loop can block the message loop and wintimer; While message. Show, form. showdialog and so on, although they block the external message loop, but they also have a message loop, so it does not block wintimer.
Note: Since system. Windows. Forms. Timer is based on message loops, you can use system. Windows. Forms. timer as long as there is a message loop, You can also use system. Windows. Forms. timer to add a reference to webform:

Code
Public   Partial   Class _ Default: system. Web. UI. Page
{
Static System. Windows. Forms. Timer timer;
Static   Int X =   0 ;
Static _ Default ()
{
Thread thread =   New Thread ( Delegate ()
{
System. Windows. Forms. Form =   New System. Windows. Forms. Form ();
Form. Load + =   Delegate
{
Timer =   New System. Windows. Forms. Timer ();
Timer. Interval =   1000 ;
Timer. tick + =   Delegate
{
X ++ ;
};
Timer. Start ();
};
System. Windows. Forms. application. Run (form );
});
Thread. Start ();
}
Protected   Void Page_load ( Object Sender, eventargs E)
{
Label1.text = X. tostring ();
}

I did not recommend that you use it!