I have a single window created with the CS_OWNDC style for an engine I'm coding and it's showing properly, but when I'm closing the program and I call the ReleaseDC(hWnd, hDC) the function returns 0 always (and according to MSDN it means it couldn't be released).
The DestroyWindow(hWnd) is also returning 0.
I am calling GetDC(hWnd) during the window creation.
What is weird is that I only get this error if I pass through the messaging function, even if it has nothing coded inside.
My main code is looking like this:
WindowManager windowManager;
HWND mainWindow = windowManager.Initialize("Title", "ClassName", 1024, 768, 32, WindowProc);
MSG msg;
while(true)
{
if(PeekMessage(&msg, 0, 0, 0, PM_REMOVE))
{
if(msg.message == WM_QUIT) { break; }
else
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
}
}
windowManager.Clear(); //this calls ReleaseDC(hWnd, DC) and DestroyWindow(hWnd) among other release codes
What I don't understand is that if I comment the whole while loop, I don't get the release or destroy window errors.
Calling GetLastError() gives me a 0 too.
On MSDN it says the DestroyWindow must be called from the same thread, but I'm not coding any multi thread functions so I don't think that's the case.
What could be causing this?
Related
I've created a win32 C++ app that uses direct2d to plot stuff in a window. In a loop as shown below, I call render and update whilst also peeking at any messages. But when ever I have WM_COMMAND that lets WindowProc call a MessageBox() or DiaLogBox(), my update&render loop no longer gets executed and the plot window freezes. Is there a simple fix with another loop structure or do I need to enter the, for me, unknown world of multithreading?
while (message.message != WM_QUIT)
{
if (PeekMessage(&message, NULL, 0, 0, PM_REMOVE))
DispatchMessage(&message);
else
{
Update();
BeginDraw();
Render();
EndDraw();
}
}
EDIT: By popular demand I have changed above "ugly" mechanism in to another approach, yet with the same issue
bool runGame = true;
while (runGame)
{
while (PeekMessage(&message, NULL, 0, 0, PM_REMOVE))
{
DispatchMessage(&message);
if (message.message == WM_QUIT)
runGame = false;
}
Update();
BeginDraw();
Render();
EndDraw();
}
On GetMessage reference from microsoft we have the next example:
BOOL bRet;
while( (bRet = GetMessage( &msg, hWnd, 0, 0 )) != 0)
{
if (bRet == -1)
{
// handle the error and possibly exit
}
else
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
}
What if I just ignore unhandled messages in the main loop of my program and move on?
Is there any risk to it? Will Windows complain/leak memory/hold resources for longer than necessary if I don't translate+dispatch this message if I don't actually need/want to handle it?
According The Message Loop,
The TranslateMessage function is related to keyboard input. It
translates keystrokes (key down, key up) into characters. You do not
really have to know how this function works; just remember to call it
before DispatchMessage. The link to the MSDN documentation will give
you more information, if you are curious.
The DispatchMessage function tells the operating system to call the
window procedure of the window that is the target of the message. In
other words, the operating system looks up the window handle in its
table of windows, finds the function pointer associated with the
window, and invokes the function.
If I don't translate+dispatch, loop will not be able to handle keyboard input and window messages. For example, the window cannot be moved, cannot be redrawn or closed. This has nothing to do with memory leaks
Having said that, a standard Message loop should be:
while (GetMessage(&msg, NULL, 0, 0))
{
if (!TranslateAccelerator(msg.hwnd, hAccelTable, &msg))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
}
Accelerators are what matters here, otherwise known as "short-cut keys". Your program wants to respond to them regardless of which window has the focus. Like F1 shows the program's help file, regardless which control has the focus. You don't want to have to write code that subclasses every control window to recognize F1.
Refer: why exactly TranslateMessage
I have a weird problem over here. I created a DLL proxy for Spotify so I can "overlay" a button onto it. Basicially, thats how it works:
DllMain
-> Creates CMain class
-> Creates CToggleButton class
-> Hooks the button onto the Spotify window
It has two methods, one static one which I use for the thread since threads can't call member functions, and one non-static function which gets called by the member function.
With this, I create the thread and pass an instance of the CToggleButton class via lpParam:
CreateThread(0, NULL, WindowThreadStatic, (void*)this, NULL, NULL);
Then, the WindowThreadStatic function:
DWORD WINAPI CToggleButton::WindowThreadStatic(void* lpParam)
{
return ((CToggleButton*)lpParam)->WindowThread();
}
And the main window thread function inside the class:
DWORD CToggleButton::WindowThread()
{
MSG msg;
hButton = CreateWindowA("BUTTON", "Test", (WS_VISIBLE | WS_CHILD), 0, 0, 100, 20, parenthWnd, NULL, hInst, NULL);
bool bQueueRunning = true;
while (bQueueRunning)
{
if (PeekMessage(&msg, parenthWnd, 0, 0, PM_REMOVE))
{
switch (msg.message)
{
case WM_QUIT:
bQueueRunning = false;
break;
case WM_LBUTTONDOWN:
if (msg.hwnd == hButton)
{
MessageBoxA(parenthWnd, "Button!", "Button", MB_OK);
continue;
}
}
TranslateMessage(&msg);
DispatchMessage(&msg);
}
Sleep(10);
}
return 0;
}
As you can see, this also contains the message loop for the button (I didn't use GetMessage() here because it was very unresponsive so I decided to use PeekMessage() together with a 10ms delay, which works fine.)
Little picture to show how it looks like:
All great, but if I maximize the window, the button disappears. When I minimize and maximize the window a few times, the button can be seen again, but with very weird coordinates (not the original 0,0 I gave him).
So what is my problem here? Why do the coordinates get offset?
Thanks for reading my long post :)
I have a basic window program, the problem is when i try to create a window in a new thread after the message loop has already started the window displays for a second and disappears. does anyone no the reason for this? can a window be created in a separate thread?
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow)
{
::hInstance =hInstance; // initialize global variables
::nCmdShow =nCmdShow;
// start thread
HANDLE threadHandle = startThread(StartUp);
MSG msg;
while(GetMessage(&msg, 0, 0, 0))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
::CloseHandle(threadHandle);
return static_cast<int>(msg.wParam);
}
DWORD WINAPI StartUp(LPVOID lpParam) // new thread runs here
{
//code to create a new window...
}
what i figured out so far is that the GetMessage(&msg, 0, 0, 0) returns false if there are no windows in the current thread that it is in... is there a way to get a round this?
GetMessage() does not return FALSE if there are no windows. It is only looking for messages in the calling thread's message queue. You are specifying NULL for its hWnd parameter, so it will not care how messages get queued, whether by PostMessage() to a window, or by PostThreadMessage() to the thread's ID.
Each thread has its own local message queue and thus requires its own message loop. You can most certainly create a new window in a worker thread after the main thread has started its message loop. They are independent of each other. So whatever problem you are having in the main thread is not related to creating a window in a worker thread. Something else is going on.
With that said, keep in mind that GetMessage() returns a BOOL, which is actually an int, not a true bool. GetMessage() can return one of 3 different return values:
-1 if an error occurs
0 if a WM_QUIT message is retrieved
>0 if any other message is retrieved
You are only checking for 0 and != 0, so if GetMessage() returns -1 on error, you are treating it as a success instead of a failure. Even MSDN says not to do that:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms644936.aspx
Because the return value can be nonzero, zero, or -1, avoid code like this:
while (GetMessage( lpMsg, hWnd, 0, 0)) ...
The possibility of a -1 return value means that such code can lead to fatal application errors. Instead, use code like this:
BOOL bRet;
while( (bRet = GetMessage( &msg, hWnd, 0, 0 )) != 0)
{
if (bRet == -1)
{
// handle the error and possibly exit
}
else
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
}
I'm creating game mario like in win32 GDI . I've implemented the new loop for game :
PeekMessage(&msg,NULL,0,0,PM_NOREMOVE);
while (msg.message!=WM_QUIT)
{
if (PeekMessage(&msg,NULL,0,0,PM_REMOVE)) {
TranslateMessage(&msg);
DispatchMessage(&msg);
}
else // No message to do
{
gGameMain->GameLoop();
}
}
But my game just running until I press Ctrl + Alt + Del ( mouse cursor is rolling ).
I've always been using something like that:
MSG msg;
while (running){
if (PeekMessage(&msg, hWnd, 0, 0, PM_REMOVE)){
TranslateMessage(&msg);
DispatchMessage(&msg);
}
else
try{
onIdle();
}
catch(std::exception& e){
onError(e.what());
close();
}
}
onIdle is actual game lopp implementation, onError() is an error handler (takes error description as argument), and "running" is either a global bool variable or a class member. Setting "running" to false shuts down the game.
I think this really depends on your context. Windows will only send a WM_QUIT in response to your application calling PostQuitMessage. A common (if not great) solution here is to use a bool to exit the message loop when your program wants to end.
I guess the program may ask user for continue or exit, inside GameLoop function call. On exit Post WM_QUIT message to the window.
PostMessage(hWnd, WM_QUIT, 0, 0 );
hWnd-> The handle of the game window
else make a call to
DestroyWindow(hWnd);
This will send a WM_DESTROY to your window procedure. There you can call
PostQuitMessage(0);