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;
}

---

Quote:

---

Originally Posted by Ducky

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.

Thanks a lot CommonTater!

That helped me a great deal.

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.

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)

Quote:

---

Originally Posted by Shakti

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...

Yes good idea to give it another name than WM_ just to differentiate between user defined and
Win32 defined variables.

Quote:

---

Originally Posted by Ducky

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.

Hehe, its funny :)