What exactly is the difference between WndProc and Defaultwndproc?

Control.defwndproc

Sends the specified message to the default window procedure.

Parameter description: M:the Windows Message to process.

protected virtual void Defwndproc (ref Message m)

Note:

For more information on processing Windows messages, see the WindowProc function.

Control.wndproc

Processes Windows messages.

Parameter description: M:the Windows Message to process.

protected virtual void WndProc (ref Message m)

Note:

All messages is sent to the WndProc method after getting filtered through the preProcessMessage method.

After the preProcessMessage method has filtered the message, all messages are sent to the WndProc method

The WndProc method corresponds exactly to the Windows WindowProc function. For more information on processing Windows messages, see the WindowProc function.

The WndProc method corresponds to the WindowProc function in the Windows system

Notes to Inheritors

Inheriting controls should call the base class's WndProc method to process any messages that they does not handle.

If you inherit from the control class and there are no messages processed in the override's WndProc method, you need to call base. WndProc method to process messages

Http://stackoverflow.com/questions/19529878/where-to-call-base-wndproc-or-base-defwndproc

What exactly is the difference between WndProc and Defaultwndproc?

There is no method named "Defaultwndproc", I'll assume you be talking about Defwndproc. This question are difficult to answer since there are very little difference between the. The Defwndproc () method corresponds to the the-the-the-the-language like C, the ability-to-call base. WndProc () is specific to. NET. They do the same thing, call the original window procedure of the windows but with a small difference. The base. WndProc () method is capable of altering the message completely, Defwndproc () can only alter the Message.result value. I can ' t think of a case where this matters.

The MSDN Library article for Control.wndproc () otherwise helps to remove the doubt, it stipulates so if you override the Method then you should always use base. WndProc ().

What's Defaultwndproc for, which I can call anytime?

Focusing on the ' anytime ' part of the phrase, this is very rarely the correct thing to do. You should almost all PInvoke SendMessage () to send a message to a window. Calling Defwndproc () should only ever is used if you intentionally want to bypass a custom WndProc () method. That's rare.

And where to call base. WndProc in my overridden method?

That's depends on what you want to accomplish. There is three basic strategies:

• look at the  m  argument and implement your own custom behavior, then call base. WndProc (). The most common, ought to be your default choice.
• call base. WndProc () First, then alter THE  m  argument or execute code to customize the default processing of T He message. This was appropriate for certain kind of messages, Wm_nchittest was the best example. Your WM_PAINT case are another one, if you need to PAINT on  top  of What was painted by the default Windo W procedure then we have the to do it the this.
• not call base. WndProc () at all. Appropriate if completely customize the message handling and don ' t want to use the default behavior. Very common for filtering message, this is how keypresseventargs.handled works for example.

Exactly which bullet is appropriate requires insight in the "the" message gets handled normally. This entirely depends in the specific control you derive from and the specific message so it impossible to give generic g Uidance. Getting it wrong however is almost always easy to diagnose.

Http://www.cnblogs.com/08shiyan/archive/2012/01/06/2313864.html

When it comes to WinForm message processing, most of the time it is done through an event handler, but when there is no corresponding event, the usual practice is to declare defwndproc or WndProc or IMessageFilter

All controls that have a user interface inherit from control, which requires the creation of a derived class of the corresponding control, which does not uniformly intercept the messages of each window, because they are essentially Windows window procedures and only receive messages for the window itself.

By reviewing the Windows message processing mechanism, the relationship between the three can be better understood.

The application's message is from the system message queue and is handled by the message loop in the application's main program.

This message loop takes the message out of the application's message queue, is preprocessed, and then distributes it to the window procedure that corresponds to the message, and the window procedure is processed according to the type of message after it is called, and some messages that can be processed by Windows by default call DefWindowProc of Windows.

The WndProc here is the window procedure for the corresponding control window, and Defwndproc is called by WndProc to handle messages that are not processed in WndProc (including WndProc), so defwndproc receives less messages than WndProc.

The invocation of imessagefilter occurs in the message loop of the application and is part of the message preprocessing, so the message it receives is more complete (except for those messages that are sent directly to the window procedure that do not enter the message queue).

All three have a common parameter type, message, which encapsulates Windows messages. It also includes a handy tostring method that converts the message object to a string that includes the name of the wm_xxx.

You can see through reflector that the implementation is through an internal class messagedecoder, using a very long switch statement to convert the message ID into a message name.

What exactly is the difference between WndProc and Defaultwndproc?