Thread: The return value from WndProc

Mostly you return 0 to signal "I have handled this message" and 1 to indicate that the default windows process should handle the message (further).

If you are not processing a message, you need to pass it along by calling DefWindowProc() which will take the appropriate action, which is most often to simply delete the message from the queue, but not always.

However; you need to check the documentation for each message to know what the return value means... Sometimes it's nothing, sometimes it's a constant, a brush or a struct.

Here's a snippet of code...
Keep in mind this is a very simple MsgProc....

Code:

// Message Loop
LRESULT CALLBACK MsgProc(HWND wnd,UINT msg,WPARAM wparm,LPARAM lparm)
  { switch (msg)
      { // main window buttons
        case WM_COMMAND :
          switch(LOWORD(wparm))
            { case 100 :    // pick a start path
                SelectFolder();
                return 0;
              case 110 :    // toggle recursion
                SetRecurse();
                return 0;
              case 120 :    // kill a scan
                StopScan();
                return 0;
              case 130 :    // launch a scan
                DoScan();
                return 0;
              case 140 :    // write report file
                SaveReport();
                return 0;
              case 150 :     // show the help file 
                ShowHelp();
                return 0;
              case 160 :    // give up and go home
                SendMessage(WHandle[0],WM_CLOSE,0,0);
                return 0; 
              case 170 :    // Launch from pulldown
                HandlePulldown( HIWORD(wparm) );
                return 0;
              default :
                return DefWindowProc(wnd,msg,wparm,lparm); }
        // User messages           
        case UM_FINISH :
          CompleteTest();
          return 0;
        case UM_ADDERR :
          AddError(wparm,(PCHAR)lparm);
          return 0;
        case WM_TIMER :
        case UM_UPDATE :
          UpdateStatusBar(wparm);
          return 0;
        // misc. messages 
        case WM_CTLCOLORSTATIC :
           return SetColors((HDC)wparm,(HWND)lparm);
        case WM_SIZE :
          ResizeWindow();
          return 0; 
        case WM_GETMINMAXINFO :
          SetWindowMin((PMINMAXINFO) lparm); 
          return 0;
        case WM_CLOSE :
          StopScan();
          SaveSettings(); 
          DestroyWindow(WHandle[0]);
          return 0;
        case WM_DESTROY :
          PostQuitMessage(0);
          return 0; 
        default :
          return DefWindowProc(wnd,msg,wparm,lparm); } }

Thanks.

I missed that somehow, the DefWindowProc.

Big problem with example programs in tutorials.

I had a combination of a default case with DefWindowProc and a return 0; at the end.
Mixed together two different examples.

Originally Posted by megafiddle

So multiple returns are ok? Rather than setting a return value in each case and then
using one return statement at end?

Yes, multiple returns are common and sometimes required as the return type varies (ie WM_COLORSTATIC requires a handle to a brush IIRC).

[picky]
No professional software house I have worked at would allow the code in Common tater's example.

I would not accept it from any of my team (but we create mission critical asset protection software to ISO standards).

Clearly the 'return' negates the need for 'break' but it is not something I would show to, let alone teach, any novice coder. I think that a novice should be taught 'perfect' syntax, not short-cuts (even if they are functionally correct).

I also do not like the use of ID numbers instead of names (because the IDE sets the names not the coder and names are more descriptive than numbers). Also 2 windows can have the same control name/functionality, but with different ID numbers generated byt the IDE (causing confusion and cut and paste errors).

But these are my personal coding standards, not hard coding rules.
[/picky]

Originally Posted by CommonTater

I do things as I do them because 1) I find it far easier to debug my code when it's all nicely compartmentalized in separate functions

Agree on the functions. Callbacks are complicated enough with out msg processing code in them.

Originally Posted by CommonTater

and 2) using breaks is not always going to take you completely out of the switch... My way guarantees the function exits.

I was commenting on the missing 'break's (even though the return makes them redundant) the lack of breaks makes the code syntactically incorrect.

I would just add a 'break' under each of your returns (when using the code as an example).

Originally Posted by CommonTater

For the use of numbers instead of constants... I don't use any pansy arsed gui designers, I code the whole thing myself, so I have full control over what does what... thus, not an issue.

Unless your target audience uses a GUI / resource editor and they have an issue....

Originally Posted by CommonTater

Trust me... except for small snippets I post here, nobody else on this planet will ever see the complete source code for any of my projects... ever.

Next year, you might be a different person from who you are this year

Originally Posted by CommonTater

And I promise you... THAT person isn't going to share source code either!

You don't share source code with your future self? Time to make some backups

Originally Posted by CommonTater

Not syntactically incorrect... just not how most people think about switch statements....

Technically a 'switch' consists of 'case break' pairs and 'return' can not be subsituted for the 'break'.

If a novice forgets one of the returns their code will not act as aexpected and they will not know why.

To be super picky....you have hard coded your returns. So your msg handlers can not decide if the msg has been processed.

I use some thing more like;

Code:

case WM_SOMEMSG:
     return SomeMsgHandler(params); //allow the handler decide if the msg requires further processing by setting the return value.
break;
case .....