switch loop in WndProc

This is a discussion on switch loop in WndProc within the Windows Programming forums, part of the Platform Specific Boards category; I would like to check if i'm getting WM_SERVER WM_CLIENT messages too in WndProc(). But im confused if i should ...

  1. #1
    Registered User
    Join Date
    Dec 2007
    Posts
    764

    switch loop in WndProc

    I would like to check if i'm getting WM_SERVER WM_CLIENT messages too in WndProc().

    But im confused if i should put it in the switch(msg) loop or outside of it?
    Its for a chat program that could be server or client as the user wishes.

    Code:
    LRESULT CALLBACK WndProc(HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
    {
        switch(msg)
        {
        case WM_CREATE:
            hWin_1  = CreateWindowEx(WS_EX_CLIENTEDGE,"ListBox", 0,
                                     WS_CHILD | WS_VISIBLE | WS_BORDER | ES_WANTRETURN |
                                     LBS_NOTIFY | WS_VSCROLL,
                                     20, 20, 550, 460, hwnd, (HMENU)IDB_TEXT1, 0, NULL);
    
            break;
        case WM_CLOSE:
            DestroyWindow(hwnd);
            break;
        case WM_DESTROY:
            PostQuitMessage(0);
            break;
        default:
            return DefWindowProc(hwnd,msg,wParam,lParam);
        }
        if (msg == WM_SERVER)
        {
            switch(WSAGETSELECTEVENT(lParam))
            {
              case FD_READ: // recv
    
                  break;
              case FD_WRITE:
    
                  break;
            }
            break;
        }
        if (msg == WM_CLIENT)
        {
            switch(WSAGETSELECTEVENT(lParam))
            {
              case FD_READ: // recv
    
                  break;
              case FD_WRITE:
    
                  break;
            }
            break;
        }
    
        return 0;
    }
    Compiler MSVC++ 2010 with Code::Blocks.

  2. #2
    Banned
    Join Date
    Aug 2010
    Location
    Ontario Canada
    Posts
    9,547
    Quote Originally Posted by Ducky View Post
    I would like to check if i'm getting WM_SERVER WM_CLIENT messages too in WndProc().

    But im confused if i should put it in the switch(msg) loop or outside of it?
    Its for a chat program that could be server or client as the user wishes.
    WM_SERVER and WM_CLIENT are not standard windows messages, they will have to be defined in some way as an integer value similar to other windows messages. It is likely they will be defined at their point of origin but if they are not you can use
    Code:
    #define WM_SERVER  WM_APP + 1000  
    #define WM_CLIENT   WM_APP + 1001
    The actual values you give are not important so long as they are offset from WM_APP and thus not likely to collide with system messages.

    Now you can incorporate them directly into your switch statement...
    Code:
    LRESULT CALLBACK WndProc(HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
    {
        switch(msg)
        {
        case WM_CREATE:
            hWin_1  = CreateWindowEx(WS_EX_CLIENTEDGE,"ListBox", 0,
                                     WS_CHILD | WS_VISIBLE | WS_BORDER | ES_WANTRETURN |
                                     LBS_NOTIFY | WS_VSCROLL,
                                     20, 20, 550, 460, hwnd, (HMENU)IDB_TEXT1, 0, NULL);
    
            return 0;
        case WM_CLOSE:
            DestroyWindow(hwnd);
            return 0;
        case WM_DESTROY:
            PostQuitMessage(0);
            return 0;
        case WM_SERVER :
            HandleServerMessage();
            return 0;
        case WM_CLIENT :
           HandleClientMessage();
           return 0; 
        default:
            return DefWindowProc(hwnd,msg,wParam,lParam);
        }
    }
    Also, in Windows, where switch statements can become horridly complex, it's generally a bad idea to put code directly in cases. Instead, make everything a function call. This compartmentalizes your code and makes debugging a whole lot simpler.

    Finally... don't use break in a windows switch statement... If you look up each message in the Windows SDK, you will discover they expect certain return values to be sent to the DefWindowProc... Generally if you use return 0; you are saying the default process should not do further work on the message, return 1; means you want it to handle the message (more), some messages even want returned values from variables.

  3. #3
    Registered User
    Join Date
    Dec 2007
    Posts
    764
    Thanks a lot CommonTater!

    That helped me a great deal.
    Compiler MSVC++ 2010 with Code::Blocks.

  4. #4
    Banned
    Join Date
    Aug 2010
    Location
    Ontario Canada
    Posts
    9,547
    No worries...

    Although in hind sight... I should have offered one more little suggestion...
    I usually use UM_????? (as in UM_SERVER) instead of WM_?????? (WM_SERVER) when defining my own messages. Same rules, same usage, just easier to keep track of.
    Last edited by CommonTater; 03-13-2011 at 12:22 PM.

  5. #5
    Registered User
    Join Date
    Aug 2003
    Posts
    1,198
    There is also the WM_USER constant available. I am not 100% sure about when one is better to use than the other but the little information i could gather was that WM_USER should be used when defining messages for a single class (as in window class?). For more information about WM_USER and WM_APP here is the msdn page: WM_USER (Windows)

  6. #6
    Banned
    Join Date
    Aug 2010
    Location
    Ontario Canada
    Posts
    9,547
    Quote Originally Posted by Shakti View Post
    There is also the WM_USER constant available. I am not 100% sure about when one is better to use than the other but the little information i could gather was that WM_USER should be used when defining messages for a single class (as in window class?). For more information about WM_USER and WM_APP here is the msdn page: WM_USER (Windows)
    WM_USER is defined as the first value for "private window classes" which I'm taking to mean custom windows controls and user registered winclasses.

    WM_APP is defined for application signalling. Which I take to mean things like our friend is doing.

    I'm sure either is a safe enough starting point, but I would not recommend actually using those values for messages... One should pick something randomly higher to lessen the odds of collisions...
    Last edited by CommonTater; 03-13-2011 at 12:21 PM.

  7. #7
    Registered User
    Join Date
    Dec 2007
    Posts
    764
    Yes good idea to give it another name than WM_ just to differentiate between user defined and
    Win32 defined variables.
    Compiler MSVC++ 2010 with Code::Blocks.

  8. #8
    Banned
    Join Date
    Aug 2010
    Location
    Ontario Canada
    Posts
    9,547
    Quote Originally Posted by Ducky View Post
    Yes good idea to give it another name than WM_ just to differentiate between user defined and
    Win32 defined variables.
    LOL... back in my wild and mispeant youth...

    UM_BKCERROR "Between Keyboard and Chair Error"
    UM_PLOTZRED I didn't even think about this one till a friend of mine pointed it out
    UM_PLASTERED
    UM_NUKEDUSER
    UM_SHIELDSUP
    UM_FAILBALEMAIL

    I'm sure there were others, too... but I'm not going looking for them.

  9. #9
    Registered User
    Join Date
    Dec 2007
    Posts
    764
    Hehe, its funny
    Compiler MSVC++ 2010 with Code::Blocks.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Homework Help C Program Loop & Switch
    By 123456tacos in forum C Programming
    Replies: 7
    Last Post: 03-11-2011, 07:11 PM
  2. Turning off While loop in realtime
    By baikal_m in forum C Programming
    Replies: 13
    Last Post: 04-22-2010, 01:56 PM
  3. how to loop in switch??
    By pczafer in forum C++ Programming
    Replies: 6
    Last Post: 05-04-2009, 01:53 AM
  4. nested loop, simple but i'm missing it
    By big_brother in forum C Programming
    Replies: 19
    Last Post: 10-23-2006, 10:21 PM
  5. Infinte loop with switch, Why??
    By Kate in forum C Programming
    Replies: 8
    Last Post: 06-16-2005, 02:15 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21