GDI+ drawing with multithreading - c++

Disclaimer: I'm somewhat of a noob when it comes to multi-threading. I've read stuff online, have done some simple multi-threading examples.
I've got a Win32 app that wants to draw the stuff in one thread and handle the Win32 messages in another thread. However, after the windows is created and the threads start, it hangs. I have a hunch that it may have to do with WaitForMultipleObjects(), but I don't know how to make it right. Does anyone have any idea why this is happening? Should I suspend and resume threads?
Here's my code:
WinAPI:
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR szCmdLine, int nCmdShow)
{
/* initialization blah blah */
zgE->startThreads(); // <--- starts the 2 threads
WaitForMultipleObjects(zgE->getThreadsNo(), zgE->getThreads(), TRUE, INFINITE);
return TRUE;
}
This is how I start the threads:
void zgEngine::startThreads()
{
/* allocation and stuff, blah blah blah */
m_arrThreads[m_nThreads++] = CreateThread(NULL, 0, &zgEngine::handleMsg, (void*)this, NULL, NULL);
m_arrThreads[m_nThreads++] = CreateThread(NULL, 0, &zgEngine::drawObjects, (void*)this, NULL, NULL);
assert(m_nThreads <= THREADS_NO);
}
And the 2 functions that draw & handle messages are quite simplist. A while loop in each of them.
// draw function
DWORD WINAPI zgEngine::drawObjects(LPVOID lpParam)
{
while (true)
{
/* draw stuff - valid code that if called outside this function
works as intended */
}
return TRUE;
}
// message handler function
DWORD WINAPI zgEngine::handleMsg(LPVOID lpParam)
{
MSG msg;
while (true)
{
if (PeekMessage(&msg, NULL, 0, 0, PM_REMOVE))
{
// Process the message
if (msg.message == WM_QUIT)
break;
TranslateMessage(&msg);
DispatchMessage(&msg);
}
}
return TRUE;
}
When I don't use threads and remove the "while (true)" in drawObjects(), but leave the code (to be executed only once), don't call handleMsg() and make WinMain like in the example below, it works like a charm.
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR szCmdLine, int nCmdShow)
{
/* initialization blah blah */
MSG msg;
while (true)
{
if (PeekMessage(&msg, NULL, 0, 0, PM_REMOVE))
{
// Process the message
if (msg.message == WM_QUIT)
break;
TranslateMessage(&msg);
DispatchMessage(&msg);
} else {
zgEngine::DrawObjects(zgE);
}
}
return TRUE;
}
Later edit: from what I've seen, PeekMessage() always returns 0 :(

Quote from PeekMessage on Microsofts website:
A handle to the window whose messages are to be retrieved. The window
must belong to the current thread.
If hWnd is NULL, PeekMessage retrieves messages for any window that
belongs to the current thread, and any messages on the current
thread's message queue whose hwnd value is NULL (see the MSG
structure). Therefore if hWnd is NULL, both window messages and thread
messages are processed.
If hWnd is -1, PeekMessage retrieves only messages on the current
thread's message queue whose hwnd value is NULL, that is, thread
messages as posted by PostMessage (when the hWnd parameter is NULL) or
PostThreadMessage.
I suspect the thread doesn't have a "current window", and the "current threads message queue" isn't the one that Windows actually posts the messages onto as the default thread. This is only an assumption, since it is entirely possible that there are other problems (as well?) with your approach. But I believe this is a main portion of where the problem lies.

Related

How do I handle win32 events from another thread? [duplicate]

Using the Win32 APIs, is it possible to create a Window or Dialog in one thread then collect events for it from another thread?
Are HWNDs tied to threads?
Trying the contrived example below I never see GetMessage() fire.
HWND g_hWnd;
DWORD WINAPI myThreadProc(LPVOID lpParam)
{
while(GetMessage(&msg, hWnd, 0, 0) > 0)
{
...
}
}
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nShowCmd)
{
hWnd = CreateDialog(hInstance, MAKEINTRESOURCE(IDD_MYDIALOG), 0, myDlgProc);
CreateThread(NULL, 0 myThreadProc, NULL, 0, NULL);
...
}
But here, I do.
HWND g_hWnd;
HINSTANCE g_hInstance;
DWORD WINAPI myThreadProc(LPVOID lpParam)
{
hWnd = CreateDialog(hInstance, MAKEINTRESOURCE(IDD_MYDIALOG), 0, myDlgProc);
while(GetMessage(&msg, hWnd, 0, 0) > 0)
{
...
}
}
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nShowCmd)
{
g_hInstance = hInstance;
CreateThread(NULL, 0 myThreadProc, NULL, 0, NULL);
...
}
Can somebody explain what I'm seeing?
No.
GetMessage returns messages on the current thread's input queue. The HWND parameter is a filter, so that GetMessage only returns messages in the current thread's input queue intended for that window.
Windows have thread affinity - messages intended for a window get handled on the thread that created and therefore owns the window.
From the MSDN:
The GetMessage function retrieves a
message from the calling thread's
message queue
So no, what you describe is not directly possible.
In your first example the Dialog and GetMessage are in separate threads. And the documentation says:
The GetMessage function retrieves a message from the calling thread's message queue.
The second example works since the calling thread (for GetMessage) also owns the Dialog.
Use AttachThreadInput.
In your example programm finish after create window.
But anyway in win32 all threads have own message queue.
And all message queues get messages for windows created in this thread.
see:
http://msdn.microsoft.com/en-us/library/ms644928(VS.85).aspx (Using Messages and Message Queues)
http://msdn.microsoft.com/en-us/library/ms644936(VS.85).aspx (GetMessage Function)
You can of course change the window procedure that handles messages for any window. Check the SetWindowLong function - http://msdn.microsoft.com/en-us/library/ms633591(VS.85).aspx - there are some rules as to what address space the new proc is. I suggest using a dll. Another way is to sub class the window message queue.
Of course you can !
Just use remote code injection ! (very classic !)

Old school Win32 Message Only Window cannot receive messages

I'm realize the console win32 app does not quit cleanly so I'm trying to switch to message only windows instead. I'm starting the app from another process and trying to kill it cleanly.
This is the win32 app, it spawns a calc.exe on startup and on clean shutdown, it should kill the calc.exe
LRESULT CALLBACK WindowProc (HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
{
switch (message)
{
case WM_USER: PostQuitMessage (0); break;
default: return DefWindowProc (hWnd, message, wParam, lParam);break;
}
return 0;
}
int CALLBACK WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int show)
{
WNDCLASSEX wc = { 0 };
wc.cbSize = sizeof (WNDCLASSEX);
wc.lpfnWndProc = WindowProc;
wc.hInstance = hInstance;
wc.lpszClassName = L"WindowClass1";
RegisterClassEx (&wc);
HWND hWnd = CreateWindowEx (NULL,
L"WindowClass1", // name of the window class
L"Our First Windowed Program", // title of the window
0,
//WS_OVERLAPPEDWINDOW, // window style
300,300,500,400,
HWND_MESSAGE,
//NULL, // parent window, NULL
NULL, hInstance, NULL);
//ShowWindow (hWnd, SW_HIDE);
PROCESS_INFORMATION pi;
CreateWindowProcess (L"calc.exe", pi); // helper class to createprocess
MSG msg = { 0 };
while (true)
{
if (PeekMessage (&msg, 0, 0, 0, PM_REMOVE))
{
if (WM_QUIT == msg.message)
break;
TranslateMessage (&msg);
DispatchMessage (&msg);
}
}
// terminate the spawn process, this is not called cleanly
TerminateProcess (pi.hProcess, 0);
return (int)msg.wParam;
}
I made a c# program to start/kill the app cleanly (the calc.exe gets destroyed) by sending a WM_QUIT/WM_CLOSE/WM_USER message . The Win32 App does not receive messages unless the window is visible (WS_OVERLAPPED and ShowWindow true). PostMessage WM_QUIT is received but the calc.exe does not get destroyed, meaning it is not a clean exit.
How should I kill it cleanly from C# app?
class Program
{
[DllImport ("user32.dll")]
public static extern bool PostMessage (IntPtr hwnd, uint msg, int wparam, int lparam);
[DllImport ("User32.dll")]
public static extern int SendMessage (IntPtr hWnd, uint uMsg, int wParam, int lParam);
static void Main (string [] args)
{
try
{
Process myProcess;
myProcess = Process.Start ("My.exe");
// Display physical memory usage 5 times at intervals of 2 seconds.
for (int i = 0; i < 3; i++)
{
if (myProcess.HasExited) break;
else
{
// Discard cached information about the process.
myProcess.Refresh ();
Thread.Sleep (4000);
Console.WriteLine ("Sending Message");
const int WM_USER = 0x0400;
const int WM_CLOSE = 0xF060; // Command code for close window
const int WM_QUIT = 0x0012;
// Received only when windows is visible
//int result = SendMessage (myProcess.MainWindowHandle, WM_USER, 0, 0);
// not clean exit
PostMessage (myProcess.MainWindowHandle, WM_QUIT, 0, 0);
// doesn't receive
SendMessage (myProcess.MainWindowHandle, WM_QUIT, 0, 0);
}
}
}
}
}
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.

Windows API wont quit

For some reason after I close this window my program wont exit and goes into an infinite loop. The solution to this problem seems to be changing GetMessage(&message, handel, 0, 0) to GetMessage(&message, NULL, 0, 0). However I don't understand why this is. Can somebody please explain. Also I don't see why I call UpdateWindow(handel) since the window will show without it.
#include <iostream>
#include <Windows.h>
using namespace std;
LRESULT CALLBACK EventHandler(HWND, UINT, WPARAM, LPARAM);
int WINAPI WinMain(HINSTANCE inst, HINSTANCE prev, PSTR args, int cmd)
{
MSG message;
HWND handel;
WNDCLASS win_class;
win_class.style = CS_HREDRAW | CS_VREDRAW;
win_class.cbClsExtra = 0;
win_class.cbWndExtra = 0;
win_class.lpszClassName = "Window";
win_class.hInstance = inst;
win_class.hbrBackground = GetSysColorBrush(COLOR_3DDKSHADOW);
win_class.lpszMenuName = NULL;
win_class.lpfnWndProc = EventHandler;
win_class.hCursor = LoadCursor(NULL, IDC_ARROW);
win_class.hIcon = LoadIcon(NULL, IDI_APPLICATION);
RegisterClass(&win_class);
handel = CreateWindow(win_class.lpszClassName, "Window", WS_OVERLAPPEDWINDOW | WS_VISIBLE, 100, 100, 350, 250, NULL, NULL, inst, NULL);
ShowWindow(handel, cmd);
UpdateWindow(handel);
//Loop does not end.
while(GetMessage(&message, handel, 0, 0))
{
cout << "LOOP" << endl;
DispatchMessage(&message);
}
return WM_QUIT;
}
LRESULT CALLBACK EventHandler(HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
static long long count = 0;
count++;
cout << "CALL #" << count << endl;
if(msg == WM_DESTROY)
{
PostQuitMessage(0);
return 0;
}
return DefWindowProc(hwnd, msg, wParam, lParam);
}
WM_QUIT is not sent to any window, just placed in the thread's message queue with no HWND, that's why it doesn't match your filter.
Take a look at GetMessage and PostQuitMessage in MSDN
If the parameter hWnd of GetMessage function is NULL, GetMessage retrieves messages for any window that belongs to the current thread, and any messages on the current thread's message queue whose hwnd value is NULL.
The PostQuitMessage function posts a WM_QUIT message to the thread's message queue, not to the current window.
Here's a good opportunity to exercise your "search-the-MSDN-documentation" abilities:
First, let's look up the documentation for WM_QUIT:
Indicates a request to terminate an application, and is generated when
the application calls the PostQuitMessage function. This message
causes the GetMessage function to return zero.
...
The WM_QUIT message is not associated with a window and therefore will
never be received through a window's window procedure. It is retrieved
only by the GetMessage or PeekMessage functions.
Then, let's look up the documentation for GetMessage():
Retrieves a message from the calling thread's message queue. The
function dispatches incoming sent messages until a posted message is
available for retrieval.
...
hWnd [in, optional] Type: HWND
A handle to the window whose messages are to be retrieved. The window
must belong to the current thread.
If hWnd is NULL, GetMessage retrieves messages for any window that
belongs to the current thread, and any messages on the current
thread's message queue whose hwnd value is NULL (see the MSG
structure). Therefore if hWnd is NULL, both window messages and thread
messages are processed.
Therefore, you want to use NULL as the window handle for GetMessage(), not handel, since WM_QUIT is not associated with any window.
There's plenty more information about how Windows programs typically handle messages also from MSDN.
As the side note, the message for window close events is WM_CLOSE, which in turn causes your window to be destroyed by default. WM_DESTROY means your window is already on it's way to being destroyed. So if you want to intercept the close event (say to ask your user to save any changes), you would handle the WM_CLOSE event.
Also, as shown in the GetMessage() documentation, you should actually have your GetMessage() loop look 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);
}
}
Because GetMessage() can actually return 1, 0, or -1 (despite it returning a BOOL).

Get Notified about Windows is Going to Sleep/Waking up in C++

I am working on an App which has Multiple Threads waiting for different inputs from DLLs and Serial Ports.
I want to add a functionality that before machine going to Sleep, I have to unload certain DLL and On waking up have to Re-load the DLL.
For this, I need to get notified on Sleep and Wake up.
I found many files about doing in C# but I want to do this in C++.
I tried using this code Project but could not capture any event. I removed everything related to Window Paint and All that as I do not need it's GUI and kept only main message loop (The While loop in the main)
EDIT:-
I am using this as my main loop:-
// Start the message loop.
while( (bRet = GetMessage( &msg, NULL, 0, 0 )) != 0)
{
if (bRet == -1)
{
// handle the error and possibly exit
}
else
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
}
To be frank I have copied this from CodeProject, and Made only one Modification i.e. Checked GetMessage(..) != 0 from a MSDN Article.
Am I missing something?
Or anyother Solution??
I am using VS2010 and programming in C++
Thanks in Advance!
Try handling the WM_POWERBROADCAST message
Here's sample code that should work. Apparently you do need to create a window otherwise you don't receive the messages. The sample creates a hidden window to achieve this.
static long FAR PASCAL WindowProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
{
if(message == WM_POWERBROADCAST)
{
//Do something
return TRUE;
}
else
return DefWindowProc(hWnd, message, wParam, lParam);
}
int _tmain(int argc, _TCHAR* argv[])
{
WNDCLASS wc = {0};
// Set up and register window class
wc.lpfnWndProc = WindowProc;
wc.lpszClassName = _T("SomeNameYouInvented");
RegisterClass(&wc);
HWND hWin = CreateWindow(_T("SomeNameYouInvented"), _T(""), 0, 0, 0, 0, 0, NULL, NULL, NULL, 0);
BOOL bRet;
MSG msg;
while( (bRet = GetMessage( &msg, hWin, 0, 0 )) != 0)
{
if (bRet == -1)
{
// handle the error and possibly exit
}
else
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
}
return 0;
}

Can the HWND from CreateWindow/CreateDialog be GetMessage'd from another thread?

Using the Win32 APIs, is it possible to create a Window or Dialog in one thread then collect events for it from another thread?
Are HWNDs tied to threads?
Trying the contrived example below I never see GetMessage() fire.
HWND g_hWnd;
DWORD WINAPI myThreadProc(LPVOID lpParam)
{
while(GetMessage(&msg, hWnd, 0, 0) > 0)
{
...
}
}
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nShowCmd)
{
hWnd = CreateDialog(hInstance, MAKEINTRESOURCE(IDD_MYDIALOG), 0, myDlgProc);
CreateThread(NULL, 0 myThreadProc, NULL, 0, NULL);
...
}
But here, I do.
HWND g_hWnd;
HINSTANCE g_hInstance;
DWORD WINAPI myThreadProc(LPVOID lpParam)
{
hWnd = CreateDialog(hInstance, MAKEINTRESOURCE(IDD_MYDIALOG), 0, myDlgProc);
while(GetMessage(&msg, hWnd, 0, 0) > 0)
{
...
}
}
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nShowCmd)
{
g_hInstance = hInstance;
CreateThread(NULL, 0 myThreadProc, NULL, 0, NULL);
...
}
Can somebody explain what I'm seeing?
No.
GetMessage returns messages on the current thread's input queue. The HWND parameter is a filter, so that GetMessage only returns messages in the current thread's input queue intended for that window.
Windows have thread affinity - messages intended for a window get handled on the thread that created and therefore owns the window.
From the MSDN:
The GetMessage function retrieves a
message from the calling thread's
message queue
So no, what you describe is not directly possible.
In your first example the Dialog and GetMessage are in separate threads. And the documentation says:
The GetMessage function retrieves a message from the calling thread's message queue.
The second example works since the calling thread (for GetMessage) also owns the Dialog.
Use AttachThreadInput.
In your example programm finish after create window.
But anyway in win32 all threads have own message queue.
And all message queues get messages for windows created in this thread.
see:
http://msdn.microsoft.com/en-us/library/ms644928(VS.85).aspx (Using Messages and Message Queues)
http://msdn.microsoft.com/en-us/library/ms644936(VS.85).aspx (GetMessage Function)
You can of course change the window procedure that handles messages for any window. Check the SetWindowLong function - http://msdn.microsoft.com/en-us/library/ms633591(VS.85).aspx - there are some rules as to what address space the new proc is. I suggest using a dll. Another way is to sub class the window message queue.
Of course you can !
Just use remote code injection ! (very classic !)