Using Createwindowex to Make a Message-Only Window

Using CreateWindowEx to Make a Message-Only Window

lpClassName shouldn't be NULL. Register class using RegisterClassEx function and pass it to CreateWindowEx.

static const char* class_name = "DUMMY_CLASS";
WNDCLASSEX wx = {};
wx.cbSize = sizeof(WNDCLASSEX);
wx.lpfnWndProc = pWndProc;        // function which will handle messages
wx.hInstance = current_instance;
wx.lpszClassName = class_name;
if ( RegisterClassEx(&wx) ) {
  CreateWindowEx( 0, class_name, "dummy_name", 0, 0, 0, 0, 0, HWND_MESSAGE, NULL, NULL, NULL );
}

How to receive messages using a message-only window in a console application?

Your messages may be blocked by User Interface Privilege Isolation. In that case you can use the ChangeWindowMessageFilterEx() function to allow the WM_COPYDATA message through.

Old school Win32 Message Only Window cannot receive messages

Processes on Windows do not really have a "MainWindow". Process.MainWindowHandle is C# making a guess, and it guesses by looking to see if the process in question has a window with focus - which will only find visible windows. Use FindWindowEx to find the window handle you want to close.

Next, when a window closes, it does not automatically try to exit the current threads message loop. You need to handle WM_DESTROY to call PostQuitMessage.

In your message loop use GetMessage rather than PeekMessage if you are not doing any other work as PeekMessage returns immediately if there are no messages meaning the application thread will never have an opportunity to sleep.

With these changes in place you should be fine to simply post a WM_CLOSE to the valid window handle as it will be destroyed, post itself a WM-QUIT message to exit the message loop, and terminate the calc process properly.

Can a message-only window receive WM_QUERYENDSESSION?

MSDN gives a decent definition of a "message-only window":

A message-only window enables you to send and receive messages. It is not visible, has no z-order, cannot be enumerated, and does not receive broadcast messages. The window simply dispatches messages.

Relevant detail highlighted.

You use them to take advantage of the message dispatch mechanism in your own code. Most typically to get a worker thread to talk to the UI thread in a thread-safe way. A message loop is the universal solution to the producer-consumer problem. Apartment marshaling in COM is implemented with a message-only window for example. Clearly such a window should be hidden and only get the messages that are defined by the app.

Don't use HWND_MESSAGE as hWndParent when calling CreateWindowEx.

Does a Message-Only Window consume fewer resources?

It's hard to answer definitively. One would imagine that a message only window would be less heavy on resources than a hidden window. But who's to say that it's not the other way around? And perhaps the answer differs with OS version. You can only tell for sure by profiling.

However, you tend not to have large numbers of message only windows in a process. And so even if there's a difference, will it ever be significant? Not likely.

More important differences are to be found in behaviour. The big one is that message only windows don't receive broadcast messages.

Make a window Static as well as allow adding text using CreateWIndowEx()

Thanks for your help. Ok So far I've done this to handle WM_WINDOWPOSCHANGING message

BOOL OnWindowPosChanging(HWND hwnd, WINDOWPOS *pwp)
{

    return 0;
}

LRESULT CALLBACK
WndProc(HWND hwnd, UINT uiMsg, WPARAM wParam, LPARAM lParam)
{
    switch (uiMsg) {

        HANDLE_MSG(hwnd, WM_WINDOWPOSCHANGING, OnWindowPosChanging);
    }

    return DefWindowProc(hwnd, uiMsg, wParam, lParam);
}

and when I create my window, I do this:

g_hwndMain =  CreateWindowEx(0,
                            TEXT("EDIT"),
                            NULL, 
                            WS_BORDER,
                            0, 0, 400, 200,
                            phwnd, NULL, 
                            g_hInstance, NULL);

                    if (!g_hwndMain) {
                        RemoveImages(spHTMLDoc);//Just so I know that the window has been created properly
                    }
                    else{                           

                        SetWindowPos(g_hwndMain, HWND_TOP, 500, 500, 300, 300,  SWP_NOSENDCHANGING | SWP_SHOWWINDOW );
                    }

The SWP_NOMOVE flag does not let the code change the position of the window, but the user is still able to change the window's position by moving it using a mouse. But this is exactly what I want to prevent. The window should be static. Any thing missing in my code, or any more suggestions?

Can a message-only window receive WM_QUERYENDSESSION?

MSDN gives a decent definition of a "message-only window":

A message-only window enables you to send and receive messages. It is not visible, has no z-order, cannot be enumerated, and does not receive broadcast messages. The window simply dispatches messages.

Relevant detail highlighted.

You use them to take advantage of the message dispatch mechanism in your own code. Most typically to get a worker thread to talk to the UI thread in a thread-safe way. A message loop is the universal solution to the producer-consumer problem. Apartment marshaling in COM is implemented with a message-only window for example. Clearly such a window should be hidden and only get the messages that are defined by the app.

Don't use HWND_MESSAGE as hWndParent when calling CreateWindowEx.

Windows: Message-only window appears when I call back from native to managed code

The window you create is not related to the console window you see. Something that you call creates a console window (or you program is marked as a console application in which case the console is created when your application is launched).

Put a breakpoint at AllocConsole() to find who is creating the console.

---

Related Topics