DefWindowProc

[kidburla]

Hi,

What does DefWindowProc actually do? I mean, is it just a function which returns 0 for WM_QUIT and 1 for all other messages, or does it actually do some processing?

Is there somewhere where we could find out what DefWindowProc does for each individual message? For example if we had the source code for DefWindowProc, we could look and see:

LRESULT CALLBACK DefWindowProc(HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
 switch(uMsg)
 {
...
  case(WM_PAINT):
  //WHAT DOES MICROSOFT PUT HERE??
  break;
...
 }
 return 0;
}

I would just like to know so that when I write my own WndProc, I don't miss out on doing things which would have been done had I called DefWindowProc. Or should I be calling DefWindowProc in addition to my custom message handling I do in my WndProc procedure?

Thanks in advance.

[maxorator]

DefWindowProc should be called in addition to your message handling, because it does tons of things for you. It does everything. Activates the window when you click on it in the taskbar, minimizes when the minimize button is pressed, lets you change the window size etc. It is something you should keep, because trying to handle all those things by yourself would be useless.

[kidburla]

DefWindowProc should be called in addition to your message handling, because it does tons of things for you. It does everything. Activates the window when you click on it in the taskbar, minimizes when the minimize button is pressed, lets you change the window size etc. It is something you should keep, because trying to handle all those things by yourself would be useless.

Hi,

I am just looking at Microsoft's Window Procedure example from

Platform SDK
+ User Interface Services
+ Windows User Interface
+ Windowing
+ Window Procedures
+ Window Procedures Overview
+ Using Window Procedures

This is it:

LRESULT CALLBACK MainWndProc(
    HWND hwnd,        // handle to window
    UINT uMsg,        // message identifier
    WPARAM wParam,    // first message parameter
    LPARAM lParam)    // second message parameter
{ 
 
    switch (uMsg) 
    { 
        case WM_CREATE: 
            // Initialize the window. 
            return 0; 
 
        case WM_PAINT: 
            // Paint the window's client area. 
            return 0; 
 
        case WM_SIZE: 
            // Set the size and position of the window. 
            return 0; 
 
        case WM_DESTROY: 
            // Clean up window-specific data objects. 
            return 0; 
 
        // 
        // Process other messages. 
        // 
 
        default: 
            return DefWindowProc(hwnd, uMsg, wParam, lParam); 
    } 
    return 0; 
}

So in Microsoft's example, they only call DefWindowProc if the message has not been processed by the Window Procedure. Is this incorrect? Should that "return 0" read "return DefWindowProc(hwnd, uMsg, wParam, lParam)"?

[maxorator]

This is correct. Return at the end maybe never gets executed but this is the correct window message handler. Why should you doubt in MSDN examples anyway?

[itsme86]

Why should you doubt in MSDN examples anyway?

Let me give you an example of why. Take the example code at the bottom of this link: http://msdn.microsoft.com/library/de...ialogboxes.asp

I'm talking about this function specifically:

LPWORD lpwAlign(LPWORD lpIn)
{
    ULONG ul;

    ul = (ULONG)lpIn;
    ul ++;
    ul >>=1;
    ul <<=1;
    return (LPWORD)ul;
}

The structures need to be DWORD-aligned in memory. Not WORD-aligned. The calls to this function contain comments that even mention that it needs to be aligned on a DWORD boundary. So why does their alignment function work on WORD boundaries instead? It happens to work with their example program, but try, for instance, to change their "My Dialog" title to something containing an even number of characters.

Just above the code they even have this (which is flat out wrong):

this example uses a helper routine that takes an input pointer and returns the closest pointer that is aligned on a DWORD boundary.

It's always good to question things. Don't take anything for granted. Especially if it comes from Microsoft.

[kidburla]

Why should you doubt in MSDN examples anyway?

Because you just told me:

DefWindowProc should be called in addition to your message handling

but the example I just pasted in doesn't do that, for the reasons I outlined!

So in Microsoft's example, they only call DefWindowProc if the message has not been processed by the Window Procedure. Is this incorrect?

This is correct.

Which is it?

[Queatrix]

The ladder.

However, when you return your proc with 0, I think there is some kind of automatic "refresh" call to the def proc.

[Kennedy]

What does DefWindowProc actually do? I mean, is it just a function which returns 0 for WM_QUIT and 1 for all other messages, or does it actually do some processing?

Whatever it needs to do for a particular message. For example, if you allow D to answer the call for WM_MOVE and WM_SIZE it will set all the window position vars for you.

Is there somewhere where we could find out what DefWindowProc does for each individual message?

I have not found a location on the MSDN that gives what D does for EACH message, but then again, I haven't found a location that lists EVERY message either. . . I do know, however, that there is quite a bit of information spread throughout the MSDN about DefWindowProc. Mostly, if my memory serves me correctly, I think it is where each message is discussed.

[Queatrix]

>> I haven't found a location that lists EVERY message either.

Try your compiler includes, right under you nose.

[Ken Fitlike]

The structures need to be DWORD-aligned in memory.

Actually, I found the control structures needed to be WORD aligned for memory dialogs. But I agree entirely with your general point; there's some msdn sample code and documentation that's very wrong and your advice on taking nothing for granted is most prudent.

[maxorator]

I haven't found a location that lists EVERY message either.

winuser.h? Maybe search MSDN or something...

Double-checking a message is not needed, if you don't handle messages you are not meant to handle.

Yes, MSDN often give some compiler-specific code (THEIR compiler specific) and some things that are not quite following the standards (like void main).

[kidburla]

I do know, however, that there is quite a bit of information spread throughout the MSDN about DefWindowProc. Mostly, if my memory serves me correctly, I think it is where each message is discussed.

Thanks very much. I looked there, and found all the info I need.

[CornedBee]

There are two common WndProc structures.

1) This one is used most often in sample code.

int CALLBACK WndProc(...)
{
  switch(msg)
  {
  case WM_xxx:
    break;

  case WM_yyy:
    break;

  default:
    return DefWindowProc(...);
  }
  return 0;
}

2) This is the one I prefer, because it allows you to choose whether to call DefWindowProc or not for each message, so you can do additional processing as well as instead-of processing of messages.

int CALLBACK WndProc(...)
{
  switch(msg)
  {
    case WM_xxx:
      return 0; // Don't call DefWindowProc.

    case WM_yyy:
      break; // Do call DefWindowProc.
  }
  return DefWindowProc(...);
}

There are some rare cases where this is useful.