Shulou(Shulou.com)06/02 Report--

This article introduces you how to explore the implementation of different WinForm code, the content is very detailed, interested friends can refer to, hope to be helpful to you.

Before entering the text, I would like you to enjoy the following two pieces of code:

/ / this is a console program. Please add the reference using System.Windows.Form; public class ConsoleApplicationShowDialog {static void Main () {Form frm = new Form (); frm.ShowDialog ();}} of System.Windows.Form.dll first.

Both code snippets are console programs (select the ConsoleApplication type to compile when compiling). The difference between these two programs is that the first one uses ShowDialog (the so-called modal form) and the second uses Show (the so-called modeless form).

After testing, we found that the form displayed with Show died there as soon as it was displayed, and did not respond to the user's input. If you put a button on the form, you even found that the button could not be displayed, and there was no response when clicked. However, the form displayed in ShowDialog is different and can respond to the user's input. What is the reason for this?

To get to the root of the problem, let's look at the difference between the Show method and the ShowDialog method implementation. The Show method is defined in Control, and Form is indirectly derived from the Control class (it seems to be a composite pattern here), the Show method code:

Public void Show () {this.Visible = true;}

The code for the Show method is quite simple, and all you have to do is display the form, so the previous second code should have the same effect as the following code:

/ / this is a console program. Please add the reference using System.Windows.Form; public class ConsoleApplicationShow {static void Main () {Form frm = new Form (); frm.Visible = true;}} of System.Windows.Form.dll first.

Now let's take a look at the ShowDialog method. The ShowDialog method is a little complicated, but there should be one of these hundred lines of code that you are familiar with:

Public DialogResult ShowDialog (IWin32Window owner) {/ /... Omit Application.RunDialog (this); / /. Omit}

Oh, this line of code is quite similar to the startup part of our thousands of WinForm programs:

Public class Program {static void Main () {Form frm = new Form (); Application.Run (frm);}}

MSDN's description of Application.Run is:

Begins running a standard application message loop on the current thread, and makes the specified form visible. Start a standard application "message loop" on the current thread and display the specified form. Here is the code for Application.Run:

Public static void Run (Form mainForm) {ThreadContext.FromCurrent () .RunMessageLoop (- 1, new ApplicationContext (mainForm));}

Oh? What is a message loop? If you are directly into. Net development, without the baptism of the Win32 era, it may not be very clear about this message loop, in your eyes only register events, handle events. Although .net simplifies the programming model of message loops that handle events such as user clicks through encapsulation, it is still Win32 under .net, and sometimes we have to understand it, which may be helpful to understand some problems (mentioned later).

Message Loop (Message Loop)

Say that Application.Run starts a message loop, so what is a message loop? Look at the following code:

MSG msg; while (GetMessage (& msg,NULL,0,0)) {TranslateMessage (& msg); DispatchMessage (& msg);}

This is the code found in almost all programs that use Win32 API to write Windows Application. This is a message loop. You don't need to understand the above code thoroughly, you just need to understand this one meaning:

Windows maintains a message queue for each Windows program. When an event is entered by a user, Windows converts the event into something called a "message" (that is, the MSG structure in the above code), which contains some information, such as the click of the mouse, the type of message, and so on. The GetMessage method in the while loop above is to constantly take messages out of the message queue and process them so that the form responds to the user's input.

Through the above discussion, we now probably understand why Show and ShowDialog are so different, the original ShowDialog started a message loop, so that the form displayed with ShowDialog can respond to the user's input events, while Show just set the Visible properties of the form, and did not start a message loop, the form displayed with Show will not be able to respond to the user's input events, that is, died there.

It says, GetMessage takes out the message and processes it. Where can I handle it? We can also see snippets like this in the Win32 program:

LRESULT CALLBACK WndProc (HWND hwnd,UINT message,WPARAM wParam,LPARAM lParam) {switch (message) {case WM_CREATE: / / handle form creation event return 0; case WM_PAINT: / / handle form drawing event return 0; / / more events, such as button clicks}}

Ah, what an ugly way to deal with it. It turns out that different treatments are made according to the type of message, and Windows defines a lot of things that start with WM_. But our lovely .net, WinForm in the beautiful event handling model is based on this, through the above code, and your experience of using events in .net, can you imagine how .net encapsulates this process?

Message processing in WinForm

In fact, in the WinForm of .net, the shadow of message processing still exists and does not disappear without a trace, and there is also a method of protected in Form:

Protected override void WndProc (ref Message m) {switch (m.Msg) {case 0x10 bank. Case 0x11: / /.... } base.WndProc (ref m);}

Oh, it's exactly the same as the one in Win32. In fact, by rewriting this method, we can achieve something that is difficult to achieve in normal practice.

Why are time-consuming operations asynchronous?

After talking so much, let's talk a little bit about the things around us. You should have come across a scenario in which you write a program and click a button to do a time-consuming operation, such as updating a large amount of data to the database, when the program, like the one at the beginning of this article, dies. No matter how much the user clicked, the program turned gray, and a "no response" was displayed on the title bar, and some programs did not even give a hint. The user thought they were really dead and snapped off the program angrily. In the middle of the time-consuming operation, it was mercilessly terminated. Why is that?

From the previous discussion, we know that responding to the user's input depends on the message loop, and the message loop is on the current thread, which is what we call the UI thread. If a time-consuming operation is also on the UI thread, then the message loop is "stuck" and cannot process subsequent messages, and the program is faked.

So how do we deal with this time-consuming operation? Of course, this time-consuming operation is put into another thread, do not occupy the UI thread, so that the message loop can continue.

On how to explore the implementation of different WinForm code to share here, I hope that the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.