How to set custom color for window using CreateWindowEx

You are assigning redbru to ButClassStruct.hbrBackground while you are passing MyClassStruct to the CreateWindowEx call.

I know I am late to comment, however, I just ran across this problem and found a solution. I suspect there are many ways for this problem to occur; I found and fixed just one.

I created, a default GUI Window project using Code:: Blocks version 17.12 on Windows 7. I changed the background color, similar to what is presented in the OP's question. I built my project and voila, everything worked. I had my red window.

Then I decided to customize the program by adding handlers for the wm_paint and wm_erasebkgnd messages and this is where things got interesting.

I found that adding the wm_erasebkgnd handler caused the window screen to become white, no more red color. I tried three versions of wm_erasebkgnd and they all caused the program to break.

case WM_ERASEBKGND:{
break;//this broke the program (white window)
return 0;//this broke the program (break was commented out)
return 1;//this broke the program (break and return 0 were commented out)
}

It turned out that the default message handler was the problem. The default, created by code::blocks 17.12 looked like this:

LRESULT CALLBACK WindowProcedure (HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam)
{
    switch (message)                  /* handle the messages */
    {
        case WM_DESTROY:
            PostQuitMessage (0);       /* send a WM_QUIT to the message queue */
            break;
        default:                      /* for messages that we don't deal with */
            return DefWindowProc (hwnd, message, wParam, lParam);
    }

    return 0;
}

Notice that DefWindowProc is NOT called after a WM_DESTROY message is received, as the break statement takes the program to the first line of code after the switch statement.

I created the same circumstance for myself by handling the wm_erasebkgnd message. Regardless what I did (break, return 0 or return 1) I never called DefWindowProc.

According to Microsoft, it is the wm_erasebkgnd message that causes DefWindowProc to erase the screen with the color specified in the wndclassex structure (hbrbackground).

I fixed my problem by changing the message handler to look like this:

LRESULT CALLBACK WindowProcedure (HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam)
{
    switch (message)                  /* handle the messages */
    {
       case WM_PAINT:{
        //ok to paint something cool between beginpaint and endpaint
       return 0;//don't call defwindowproc
       }
       case WM_ERASEBKGND:{
       break;//return 0 or return 1 will break the program and a white window will display
/*normally when using wm_paint I return 1 from wm_erasebkgnd 
because I don't want windows to erase the screen with the color 
defined in my wndclassex structure.  that means I have to erase 
myself using the hdc sent with wparam when the wm_erasebkgnd message 
is sent OR handle screen erasing as part of my wm_paint processing. 
Why? screen flicker is often caused by failing to prevent an extra
erase command (and that is what happens if you don't handle the 
wm_erasebkgnd message)
*/
       }
        case WM_DESTROY:
            PostQuitMessage (0);       /* send a WM_QUIT to the message queue */
            break;
        default:                      /* for messages that we don't deal with */
            break; //return DefWindowProc (hwnd, message, wParam, lParam);
    }

    return DefWindowProc (hwnd, message, wParam, lParam); //return 0;
}

I hope this post helps someone else.