I try to get some messages from other windows. I need to find window by name, I used FindWindowW(). How can I get active window and get message from its?
When I add hwnd in GetMessage(), it doesn't work.
//WndProc
case WM_KEYDOWN:
OutputDebugStringW(L"Key down");
break;
//main.c
//WNDCLASSEX wc;
HWND hwnd;
MSG Msg;
hwnd = FindWindowW(NULL, L"Sublime Text");
while (GetMessage(&Msg, NULL, 0, 0) > 0)
{
TranslateMessage(&Msg);
DispatchMessage(&Msg);
}
return Msg.wParam;
Only the thread that creates a window can directly receive and dispatch messages for that window. GetMessage() retrieves messages from the calling thread's message queue, so it can only be used with windows that are owned by the calling thread.
Since you are trying to catch messages for a window that is not yours, you will have to use SetWindowsHookEx() or SetWinEventHook() to install a hook callback into that window's owning thread, and then that callback can intercept the desired messages/events for that window. You can use GetWindowThreadProcessId() to get the IDs of the Process and Thread that own the window.
If you use SetWindowsHookEx() and are trying to hook a window in another process, your callback must reside in a DLL so it can be injected into that process. You do not need to do that with SetWinEventHook().
Related
I am trying to exit a window i've third DestroyWindow() and SendMessage() with WM_CLOSE and CloseWindow() the first two don't work and CloseWindow(); only minimizes it!
Example code of what i'm trying to do:
int main()
{
HWND curwind;
char ccurwind[256];
HWND newwind;
HWND wind2;
Sleep(1000);
printf("Destroying in 5...\n");
Sleep(1000);
printf("Destroying in 4...\n");
Sleep(1000);
printf("Destroying in 3...\n");
Sleep(1000);
printf("Destroying in 2...\n");
Sleep(1000);
printf("Destroying in 1...\n");
curwind = GetForegroundWindow();
GetWindowTextA(curwind, ccurwind, 256);
//DestroyWindow(curwind);
if (DestroyWindow(curwind) == 0) {
printf("Failed with error: %s", GetLastError());
}
else {
printf("\nDestroyed %s", ccurwind);
}
getch();
return 0;
}
So basically close the window but not the process
example scenario:
I open a new tab on google in a new window this program will close that window but not the whole process. Is this possible and if so what function would i use?
Only the thread that owns the window is allowed to call DestroyWindow. SendMessage(hWnd, WM_SYSCOMMAND, SC_CLOSE, 0) is the same as closing the window with the system menu but it ultimately just sends WM_CLOSE.
A window can ignore WM_CLOSE and there is not much you can do about that.
If the window is in a process with a higher integrity level than you then UIPI will block your message.
the function: DestroyWindow() should do the job.
From: 'https://msdn.microsoft.com/en-us/library/windows/desktop/ms632682(v=vs.85).aspx'
Destroys the specified window. The function sends WM_DESTROY and WM_NCDESTROY messages to the window to deactivate it and remove the keyboard focus from it. The function also destroys the window's menu, flushes the thread message queue, destroys timers, removes clipboard ownership, and breaks the clipboard viewer chain (if the window is at the top of the viewer chain).
If the specified window is a parent or owner window, DestroyWindow automatically destroys the associated child or owned windows when it destroys the parent or owner window. The function first destroys child or owned windows, and then it destroys the parent or owner window.
DestroyWindow also destroys modeless dialog boxes created by the CreateDialog function.
Original Problem:
I have a window that cannot be closed immediately after being created despite my window procedure function being able to detect the WM_CLOSE message, and calling PostQuitMessage and letting Windows continue to handle the window messages with DefWindowProc.
But, after moving the window by dragging the title bar, it seems to be able to close normally.
The code for the my window procedure function is the following:
LRESULT CALLBACK OnEvent(HWND handle, UINT message, WPARAM wParam, LPARAM lParam)
{
switch (message)
{
case WM_QUIT:
{
printf("WM_QUIT\n");
break;
}
case WM_CLOSE:
{
printf("WM_CLOSE\n");
PostQuitMessage(0);
return 0;
}
}
return DefWindowProc(handle, message, wParam, lParam);
}
So besides sending the WM_MOVE message to my window or using exit(0) in the WM_CLOSE case block, how can I ensure that my window can be closed immediately after being created?
New Question:
After passing NULL to the hWnd parameter of GetMessageW, instead of my window handle, the window now closes properly hence answering my previous question.
Therefore, why did the GetMessageW function previously not retrieve the WM_QUIT message with the provided handle of the only window, instead of using NULL as the hWnd parameter?
A properly written message loop will never dispatch a WM_QUIT message to a window procedure, it will simply break the loop when GetMessage() returns 0 when it receives a WM_QUIT message:
GetMessage function
If the function retrieves a message other than WM_QUIT, the return value is nonzero.
If the function retrieves the WM_QUIT message, the return value is zero.
If there is an error, the return value is -1. For example, the function fails if hWnd is an invalid window handle or lpMsg is an invalid pointer. To get extended error information, call GetLastError.
In response to WM_CLOSE, you should be calling DestroyWindow() instead of PostQuitMessage() directly (the default behavior of DefWindowProc(WM_CLOSE) is to call DestroyWindow() for you). You need a WM_DESTROY handler that should then call PostQuitMessage():
LRESULT CALLBACK OnEvent(HWND handle, UINT message, WPARAM wParam, LPARAM lParam)
{
switch (message)
{
case WM_CLOSE:
{
printf("WM_CLOSE\n");
DestroyWindow(handle);
return 0;
}
case WM_DESTROY:
{
printf("WM_DESTROY\n");
PostQuitMessage(0);
return 0;
}
}
return DefWindowProc(handle, message, wParam, lParam);
}
This is documented on MSDN:
Closing the Window
Here is the flow chart from that page:
As for the GetMessage() issue, if you read the documentation for GetMessage() and PostQuitMessage() more carefully, you will see that the WM_QUIT message posted by PostQuitMessage() is not a window message. Passing a non-NULL HWND to GetMessage() only retrieves messages from PostMessage() and SendMessage() that are intended for that specific HWND 1. GetMessage() will ignore any messages that are not intended for that HWND, which includes thread messages from PostThreadMessage() and PostQuitMessage(). Passing a NULL HWND to GetMessage() allows it to return any pending message, including WM_QUIT.
1 which is dangerous to do, BTW: The dangers of filtering window messages
I had this exact problem when I called GetMessage() in my loop with the handle of the main window as the second argument:
GetMessage(&msg, hMainWindow, 0, 0)
instead of NULL to specify that I want to handle messages for the whole thread / application instance:
GetMessage(&msg, NULL, 0, 0)
The WM_CLOSE messages would lead to WM_QUIT messages, but GetMessage() will ignore these when it's only looking for messages for a particular window. From the documentation:
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.
What exactly causes moving of the window to have subsequent closing attempts succeed is however still beyond me.
Another issue that I had found was that when you had set your window classes (WNDCLASSEX) windows procedure (lpfnWndProc) I had set it to the default window procedure and had not used a custom built window procedure. So when you had closed it nothing would occur.
The application do not need any window or console. It can be a console application if the console window can be removed or can be put into background. The application will do some simple tasks(such as cleaning rubbish files) and exit.
I hope that the application should not be a windows service if possible.
I hope that the application can be started with double-click in explorer window and run silently.
When the application is running, I hope that the mouse cursor should not be changed to hourglass shape. That is to say, do not disturb the user when the application is running. Just run and exit silently.
DO NOT NEED to run it when windows starts or user logins.
I hope this can be done in C if possible. What should I do?
task_finished = 0;
CreateThread(NULL, 65535, task_thread, para, 0, NULL);
MSG msg;
while(!task_finished){
while (PeekMessage(&msg, NULL, 0, 0, PM_REMOVE)) {
if(task_finished)
break;
TranslateMessage(&msg);
DispatchMessage(&msg);
}
}
IIRC, you can do this by just writing a WinMain function that doesn't create or display a window or console. Lambert's answer about using a message loop will help you if you want your program to be able to send or receive messages from other programs, but if you're just doing simple background processing all you should need is a WinMain that doesn't make a window.
All you need is a message loop -- just use this code (modified from here):
MSG msg;
BOOL bRet;
while ((bRet = GetMessage(&msg, NULL, 0, 0)) != 0)
{
if (bRet == -1)
{
// handle the error and possibly exit
}
else
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
}
Edit:
For I/O or other tasks, you can either (1) create another thread, and do everything from there, or (2) Use MsgWaitForMultipleObjects inside the loop (before the next GetMessage() call) to simultaneously wait on your I/O and on messages, so that you can be notified when there's either a message, or when your I/O is finished.
Warning:
I haven't figured out how to make the application not bring up the hourglass shape when starting. If you need that functionality, consider creating a Windows service instead. You can also compile as a console application, then use FreeConsole to hide the window.
I have a program that sets a global keyboard hook and handles key presses. This is my WinMain:
int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR pCmdLine, int nCmdShow)
{
MSG msg;
logFile = fopen("C:\\keylog.txt", "w");
hKeyHook = SetWindowsHookEx(WH_KEYBOARD_LL, (HOOKPROC)KeyEvent, GetModuleHandle(NULL), 0);
GetMessage(&msg, NULL, 0, 0);
UnhookWindowsHookEx(hKeyHook);
fclose(logFile);
return 0;
}
Since it doesn't create any windows it won't ever receive a window message, so GetMessage would stall the program, and it is very light on CPU cycles. However, when it detects a certain key is pressed I want it to exit the program. I can't broadcast a message because it won't receive it. If I do something like:
while(State == true)
Sleep(500);
The program itself and the global hook would stall and this is undesirable. Making it Sleep(0) makes it consume an unmanageable amount of CPU cycles.
So, what is the best alternative for my problem? The only thing I can think of is going through the trouble to register my own window class and create a window to receive the message, but perhaps there is a better way?
Why not create synchronization object (maybe Event) and replace GetMessage with WaitForSingleObject?
You can easily make your keyboard hook routine trigger the object and your app will do the pre-termination stuff.
You can't broadcast a message using HWND_BROADCAST.
You don't need a window to receive messages. However, if you had some way to publish your thread id, then PostThreadMessage() could be used to send a message (probably a WM_QUIT) to your app.
I'm currently trying to integrate some animation drawing code of mine into a third party application, under the form of an external plugin.
This animation code in realtime 3d, based on OpenGL, and is supposed to render as fast as it can, usually at 60 frames per second.
In my base application, where I'm the king of the world, I control the application message pump, so that drawing occurs whenever possible. Like that :
for (;;)
{
if (PeekMessage(&msg, NULL, 0, 0, PM_REMOVE))
{
do
{
if (msg.message == WM_QUIT) break;
TranslateMessage(&msg);
DispatchMessage(&msg);
}
while (PeekMessage(&msg, NULL, 0, 0, PM_REMOVE));
}
draw();
}
Now that I'm no more king in the world, I have to play nice with the application messages, so that it keeps being responsive. To my knowledge, as I'm a plugin, I can't hijack the whole application message pump ; so I tried various things, doing my drawing in WM_PAINT message handler :
Use WM_TIMER, which doesn't work :I don't know in advance which time step I need (often not fixed) and the timing in not accurate.
Call InvalidateRect as soon as I'm done drawing, doesn't work : completely prevents the rest of the application of being responsive and doing its own refreshing.
Create a 'worker' thread, whose only job is to post a user message to the plugin window. This message is posted as soon as the drawing is finished (signaled by an event). The user message handler, in turn, calls InvalidateRect (see there).
So far, my last attempt is the better, and sometimes work fine.
DWORD WINAPI PaintCommandThreadProc(LPVOID lpParameter)
{
Plugin* plugin = static_cast<Plugin*>(lpParameter);
HANDLE updateEvent = plugin->updateEvent();
while (updateEvent == plugin->updateEvent())
{
::WaitForSingleObject(updateEvent, 100);
::Sleep(0);
if (updateEvent == plugin->updateEvent())
{
::PostMessage(plugin->hwnd(), WM_USER+0x10, 0, 0);
}
}
return 0;
}
...
LRESULT CALLBACK PluginWinProc(HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
bool processDefault = true;
LRESULT result = 0;
Plugin* plugin = reinterpret_cast<Plugin*>( GetWindowLong(hWnd, GWL_USERDATA) );
switch (msg) {
...
case WM_GL_MESSAGE:
{
::InvalidateRect( hWnd, NULL, FALSE );
processDefault = false;
result = TRUE;
}
break;
case WM_PAINT:
{
draw(hWnd);
::SetEvent( plugin->updateEvent() );
processDefault = false;
result = TRUE;
}
break;
...
}
if (processDefault && plugin && plugin->m_wndOldProc)
result = ::CallWindowProc(plugin->m_wndOldProc, hWnd, msg, wParam, lParam);
return result;
}
On some occasions, the host application still seems to miss messages. The main characteristics of the problem are that I have to press the 'Alt' key for modal dialogs to show up ; and I have to move the mouse to give some processing time to the host application !...
Is there any 'industry standard' solution for this kind of as-often-as-you-can animation repaint problem ?
Each thread has its own message queue, and messages sent to a window arrive in the queue of the thread that created the window. If you create your plugin window yourself, you can create it in a separate thread, and that way you will have complete control over its message pump.
An alternative solution (which imho is better), is to only have OpenGL rendering in a separate thread. All OpenGL calls must occur in the thread that created the OpenGL context. However, you can create a window in one thread (your application main thread), but create the OpenGL context in another thread. That way the original application message pumps stays intact, and in your rendering thread you can loop forever doing rendering (with calls to SwapBuffers to vsync).
The main problem with that second solution is that communication between the plugin WindowProc and the rendering loop must take into account threading (ie. use locks when accessing shared memory). However since the message pump is separate from rendering, it can be simultaneous, and your message handling is as responsive as it can get.