Is calling a function that does the same thing as the message you're sending faster than calling SendMessage()?
For example in the code below in case WM_RBUTTONUP:, which is faster, calling EnableTwoWindows(firstWnd, secondWnd);or sending SendMessage(hwnd, CUSTOM_MESSAGE_ENABLE_TWO_WINDOWS, 0, 0);? And what are the advantages and disadvantages of calling a function vs sending a message?
void EnableTwoWindows(HWND hwnd1, HWND hwnd2)
{
EnableWindow(hwnd1, TRUE);
EnableWindow(hwnd2, TRUE);
}
LRESULT CALLBACK WndProc(HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
static HWND firstWnd, secondWnd;
switch(msg)
{
case CUSTOM_MESSAGE_ENABLE_TWO_WINDOWS:
EnableWindow(firstWnd, TRUE);
EnableWindow(secondWnd, TRUE);
break;
case WM_RBUTTONUP:
//EnableTwoWindows(firstWnd, secondWnd); //Is calling this function faster? or
//SendMessage(hwnd, CUSTOM_MESSAGE_ENABLE_TWO_WINDOWS, 0, 0); //Is sending message faster?
break;
case WM_DESTROY:
PostQuitMessage(0);
break;
default:
return DefWindowProc(hwnd, msg, wParam, lParam);
}
return 0;
}
Calling the function directly is faster than going through a SendMessage call.
This can be easily inferred, when you look at what SendMessage does: It first needs to determine, whether the target window is owned by the same thread, and if so, retrieve the window procedure, and finally call that.
If the target window is owned by another thread, it gets more costly, as the SendMessage call has to queue up the message on the target thread's queue, wait for it to invoke a message retrieval function, and can only return, when the target thread has dispatched the message and produced a return value. In that case, however, it is mandatory to call SendMessage. Manipulating windows from threads other than the owning thread results in undefined behavior. SendMessage ensures, that the manipulations run on the same thread, that owns the window.
In addition, the compiler can inline the direct function call. This is not possible when calling SendMessage, since the compiler cannot see its implementation.
Performance is not an issue: You are responding to user input. The user is the bottleneck. Correctness, on the other hand, is essential. If you need to decide, use the following rule: If the windows you are manipulating are owned by a thread other than the calling thread, use SendMessage. If the windows are owned by the calling thread, go for a direct function call.
Yes.
It costs more to call multiple functions than it does to call one function.
Related
I write simple windows c program to display the bitmap at the place where the left mouse button is pressed. At the first time when I click my left mouse button, the bitmap appears. But on the second time on words the bitmap is not getting displayed on the place where I made a left mouse click.
Here is my code.........
LRESULT CALLBACK myHandler(HWND hw, UINT m, UINT mextra, long co_ord)
{
HDC hdc, hmemdc;
PAINTSTRUCT ps;
HBITMAP hbmp;
RECT r;
HGDIOBJ holdbmp;
int x, y;
switch(m)
{
case WM_LBUTTONDOWN:
hdc = BeginPaint(hw,&ps);
hmemdc = CreateCompatibleDC(hdc);
hbmp = LoadBitmap(h, MAKEINTRESOURCE(IDB_BITMAP1));
holdbmp = SelectObject(hmemdc, hbmp);
x = LOWORD(co_ord);
y = HIWORD(co_ord);
BitBlt(hdc, x, y, 190, 220, hmemdc, 0, 0, SRCCOPY);
EndPaint(hw,&ps);
SelectObject(hmemdc, holdbmp);
DeleteObject(hbmp);
DeleteDC(hmemdc);
DeleteDC(hdc);
break;
case WM_DESTROY:
PostQuitMessage(0);
break;
default:
return DefWindowProc(hw,m,mextra,co_ord);
}
return 0L;
}
The code is wrong about seven different ways from Sunday. Even after the changes you've made in response to WhozCraig's comments, it is still wrong.
For starters, the only place you are allowed to call BeginPaint and EndPaint is in response to a WM_PAINT message. You are trying to call these functions in response to a WM_LBUTTONDOWN message. That cannot work. What you'll want to do is trigger a WM_PAINT message from within your WM_LBUTTONDOWN message handler, which you can do by calling the InvalidateRect() function, passing your window handle and NULL for the rectangle to invalidate (to invalidate your entire window). Then, inside of the WM_PAINT message handler, you can call BeginPaint/EndPaint and do your drawing. If you want the drawing to be different depending on whether the left mouse button is down, you can either set a flag inside of the WM_LBUTTONDOWN message handler and test the value of that flag inside of your WM_PAINT message handler, or you can use something like GetKeyState to determine whether the mouse button is down (VK_LBUTTON).
You are also leaking GDI objects because you are not correctly releasing/destroying them. A bitmap that has been loaded with LoadBitmap needs to be destroyed by calling DeleteObject. (However, loading a bitmap repeatedly inside of a WM_PAINT message handler will lead to poor performance. Instead, prefer to load the bitmap a single time in response to the WM_CREATE message, cache its handle in a global or class-level variable, use it when necessary, and destroy the bitmap via that handle in response to the WM_DESTROY message.)
The LOWORD and HIWORD macros should never be used for extracting cursor coordinates. These are liable to return the wrong result on multiple monitor systems. Instead, you should use GET_X_LPARAM and GET_Y_LPARAM. This is specifically mentioned in the MSDN documentation for the WM_LBUTTONDOWN message. Always read the documentation for things you are unfamiliar with!
Finally, the signature for your window procedure is also completely wrong. I have no idea where you got that signature, but not only do you have non-standard parameter names that obscures the actual meaning of those arguments, but you have the wrong types. A window procedure looks like this:
LRESULT CALLBACK myHandler(HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam)
{
...
}
It is extremely difficult to learn Windows API programming by just hacking around, especially if you aren't disciplined about reading the MSDN documentation. If you really want to learn it, consider purchasing a book, like Charles Petzold's classic Programming Windows, 5th edition (yes, you need the 5th edition, not a newer edition).
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.
I wanted to 'protect' a certain window from closing. So I wanted to hook WM_CLOSE, WM_DESTOY or WM_QUIT. And this is what I tried to do so:
LRESULT CALLBACK WindowHookProc(int nCode, WPARAM wParam, LPARAM lParam)
{
if (nCode >= 0)
{
MSG* msg = (MSG*)lParam;
//if (msg->hwnd == GetForegroundWindow())
{
if (msg->message == WM_CLOSE || msg->message == WM_QUIT || msg->message == WM_DESTROY)
{
//MessageBox(0, "TEST", "", 0);
msg->message = 0;
CallNextHookEx(hMsg, nCode, (WPARAM)NULL, (LPARAM)NULL);
return TRUE;
}
}
}
CallNextHookEx(hMsg, nCode, wParam, lParam);
}
I tried:
Returning TRUE or FALSE
Calling CallNextHookEx with NULL as LPARAM or
editing the msg->message to 0
Also what I noticed, if I hook WH_GETMESSAGE it doesn't 'block' the message loop. But it does so with hooking WH_CALLWNDPROC. I discovered this with prompting a messagebox when the msg->message equals to WM_CLOSE.
Thanks in advance,
Regards.
WH_GETMESSAGE installs a hook for messages that are retrieved from the message queue. It does allow you to modify the message. But the problem is that WM_CLOSE is not posted to the message queue with PostMessage(), it is sent with SendMessage(). This hook can't see it.
WH_CALLWNDPROC installs a hook that runs just before the window procedure is called. Which will allow you to see WM_CLOSE. However, you are not allowed to modify the message or make it disappear.
There is no hook that allows you to do what you want to do. Instead you have to sub-class the window procedure. So that your own custom window procedure is called before the window's own procedure. Now you can simply filter WM_CLOSE by just not calling the old window procedure.
Beware that you still need the same kind of plumbing that SetWindowsHookEx() provides, you still need to inject a DLL with your window procedure into the process. Best way is to still use SetWindowsHookEx to get that done with a dummy hook that doesn't otherwise do anything.
Instead of trying to install a hook, just subclass the window and have your subclass WndProc ignore the WM_CLOSE while forwarding all the other messages.
You can't and shouldn't try to stop WM_QUIT. As rodrigo pointed out, you can't do anything about WM_DESTROY. At that point, DestroyWindow has already been called, and your window is going away whether you like it or not.
i want to write a global keyboard hook to disallow task switching.When i googled i found a whole lot of codes in c#,cpp (and delphi), but i need some basic concepts about hooking (would be the best if examples are in C).So, kindly suggest the resources,links that can help me understand the thing in C's perspective.
PS: I found one good working example(works on winXP and older versions),but when i tried compiling the code it gives me:
And i tried searching the "IDC_" constants in all the headers(default ones that come with MinGW gcc installation and the ones provided by developer),but no luck...If any one can compile the code and make it run please help me.I have not uploaded the source itself here as there are a few header file dependencies and in that case i'd have to post all the code here.
winXP is the target environment but would be better if i get it to run Win7 also.
I will go out on a limb here assuming you are on Windows and you want to capture global keystrokes. A way to do this is to use LowLevelHooks. Look at the following example:
Define this callback function somewhere in your code:
//The function that implements the key logging functionality
LRESULT CALLBACK LowLevelKeyboardProc( int nCode, WPARAM wParam, LPARAM lParam )
{
char pressedKey;
// Declare a pointer to the KBDLLHOOKSTRUCTdsad
KBDLLHOOKSTRUCT *pKeyBoard = (KBDLLHOOKSTRUCT *)lParam;
switch( wParam )
{
case WM_KEYUP: // When the key has been pressed and released
{
//get the key code
pressedKey = (char)pKeyBoard->vkCode;
}
break;
default:
return CallNextHookEx( NULL, nCode, wParam, lParam );
break;
}
//do something with the pressed key here
....
//according to winapi all functions which implement a hook must return by calling next hook
return CallNextHookEx( NULL, nCode, wParam, lParam);
}
And then somewhere inside your main function you would set the hook like so:
//Retrieve the applications instance
HINSTANCE instance = GetModuleHandle(NULL);
//Set a global Windows Hook to capture keystrokes using the function declared above
HHOOK test1 = SetWindowsHookEx( WH_KEYBOARD_LL, LowLevelKeyboardProc, instance,0);
More general information about hooks can be found here.
You can also capture other global events with the same exact way only following the directions given in SetWindowsHooksEX documentation.
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.