While capturing the WM_ACTIVATE message, I am getting the LPARAM parameter of the message handler as NULL if the windows are in the different threads. So after some reading and searching I found that for this kind of situation one should use WM_ACTIVATEAPP. But my problem is that WM_ACTIVATEAPP is not supported for WINCE. I want to know some alternative so that if activation happens and windows affected are in the different threads I can get handle of other window in current window class..
Related
We have a user definable "dashboard". It is possible to add several components into this window. Some windows are browser controls (ActiveX controls created with CLSID_WebBrowser). This browser controls can show content from different sources in the internal web.
To avoid blocking of the application each browser control is hosted in its own thread. Reason here was that the ActiveX Webbrowser control is hosted in an STA and only loads and shows data when message loop is running and this may block other parts of the UI.
So we have one parent window containing child windows of type list control, tree control, statics and group boxes, mixed with some browser controls. Except the browser control, all controls belong to the same UI thread. But the threads use one input queue and AttachThreadInput was executed for each thread to attach it to the main thread.
Now we face the following problem:
When the user designs his screen with a group box and a web control inside it. the application locks when the user moves the mouse over the browser control and clicks or uses the mouse wheel. The application locks and doesn't accept any further input. If you minimize the application and activates it again, you can work on and input is accepted again.
Reasons
With the debugger and spy++ we found out, that any mouse event causes WM_NCHITTEST to be sent to the group box. The group box returns HTTRANSPARENT. But the underlying window is of a different thread. We can see that an infinite loop occurs an WM_NCHITEST messages are fired to the group box and the input is blocked until this loop gets interrupted (minimizing by showing the desktop).
We can read in the documentation that WM_NCHITTEST and HTTRANSPARENT are limited to windows of the same thread. And I can find 2 other article in the net that describe the same or similar problem.
The simple solution
The simple solution is just to take care that the browser controls are never covered by a group box or static control. So changing the Z-order is simple and works (groupbox must follow the windows of the different thread in Z-order)
Question
I would be interested if there is another way to get around this problem. Or if there is a way to prevent such input queue deadlocks. Or if somebody knows what is happening internally when this WM_NCHITTEST must handle windows from different threads.
Would someone please answer my question?
Does the C++ program (written using visual studio) create a separate thread for handling mouse events? Would you please describe it concisely?
Thanks
In Windows, each thread that creates a window, and some that don't create any, receive a message queue (and remember that any application has at least one -the main- thread).
This queue is a OS structure that contains any message directed to any windows created by this thread; that includes window handling messages, timers, mouse events directed to any of these windows, keyboard events when any of these windows has the keyboard focus, system events, etc...
It is the responsibility of any thread that has a message queue to pump these messages periodically. This is usually done in what is called the main loop of the thread.
This main loop, in its simplest form is:
MSG msg;
while (GetMessage(&msg, 0, 0, 0))
DispatchMessage(&msg);
But it is usually much more convoluted, depending on the complexities of the program.
These two functions:
GetMessage(&msg) removes one message from the queue and puts it in msg. The 0s mean: do not filter.
DispatchMessage(&msg) handles the message, probably calling the callback function relevant to this particular message. With Window messages (mouse and keyboard included) this usually means to locate the window class and then call the window function from within.
So, answering your question: mouse messages are handled in the same thread that created the window that receives them. And it processes them one by one.
No, the mouse events are submitted to the main UI thread/Message loop, along with keyboard and any other peripherals (and system events, and messages from other processes, etc.)
if you want to create a keyboard and mouse hook in Visual C++ 2005 Check this..
http://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/3d9bb875-8e79-4c1e-b2ef-b24503e6abbd/how-to-create-a-keyboard-and-mouse-hook-in-visual-c-2005?forum=windowssdk
I'm writing a linux application using C++ and wxWidgets.
From my application, I need to send keyboard events to the window that currently has the focus (not belonging to my application!).
My questions are:
How can I find out what window has the focus?
How can I send a keyboard event to a window not belonging to my application?
Thanks
Daniele
XGetInputFocus(3).
X11 does not care about "applications". There are only windows. It's enough to have a window ID (Window is the Xlib data type). Use whatever method of sending events works. There are two methods I know of: XSendEvent(3) and XTestFakeKeyEvent(3). The former method does not work with some programs that chose to ignore events coming from XSendEvent. The latter one requires the XTest extension, which is present in most, but not all, modern servers.
Note that InputFocus is a valid window designator for XSendEvent, and XTestFakeKeyEvent is delivered to the window that has the focus anyway, so you probably don't need to call XGetInputFocus at all.
If you use 2.9, you can use wxUIActionSimulator. It is intended to work with other windows of the same (wxWidgets) application but AFAICS it should actually work with the windows of other applications when using X11 too (however I didn't test it myself).
How can we generate event, so that the framework will invoke its message handler OnSize() function in MFC at the instance at which I need.
Thanks
Use SendMessage or PostMessage functions and send WM_SIZE message
I am very often repeating this statement: Windows is not an event driven system; hence, you do not generate events. Event in Windows is an entity used to synchronize threads.
Each window works by processing messages from the system or application and acting accordingly. They can be predefined messages or message defined specifically for the application.
I respectfully but strongly disagree with previous posts. Even though information was given with good intentions, it shows a bad programming practice.
You should never use Send/Postmessage to change windows size. Use windows API:
MoveWindow or SetWindowPos. This will send WM_SIZE (and other companion messages) to the window to notify about size change request.
In general:
Never send or post messages that are generate by the system, since this does not work in most cases because system usually generates additional messages that you do not send, causing unexpected behavior.
You can use SendMessage function, something like this:
SetWindowPos (NULL, 0,0, myrect. Height (), myrect. Width (), SWP_FRAMECHANGED|SWP_NOZORDER);
To be more general, the way to synthesize events in MFC is by using SendInputfunction:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms646310(v=vs.85).aspx
my question is : how can I use SendMessage() to implement thread communication between two threads, one with a window (GUI) and the other with no window?
The problem is that SendMessage() needs a handle (HWND)?
Another detail about my project : Two threads, one running managed code (the one with the user interface), and the other running native code (the one without window)
Thank you very much!
I would suggest creating a hidden window. When using postthreadmessage, there is a chance that your message could get lost (ie: if a messagebox is running the message loop).
More info about that at:
http://blogs.msdn.com/oldnewthing/archive/2005/04/26/412116.aspx
Perhaps you should try to use PostMessage or PostThreadMessage
If the thread has no window, no message queue, and no message dispatcher, then it's going to be hard to a message to it. It is common for threads to create hidden windows just for communication purposes (take a look with Windows Spy and you'll see plenty of examples).
One alternative is to use shared memory and a synchronization primitive such an event or semaphore. Another alternative is to use pipes.
what #jdigital said. Note that if you create a hidden window, and your thread does not already implement a message loop (either in regular win32-speak, or one in the context of a COM STA -- and if you have no idea what I'm talking about then one probably does not exist in your thread), you'll also want to create a message loop as well. ATL makes it fairly easy with _AtlModule.RunMessageLoop(); Unfortunately this also means the thread in question is probably going to need to be event-driven while it is in the message loop. You can do tricky things like MsgWaitForMultipleObjects, but it gets hairy.
Here's an example of hidden windows if you're familiar with ATL/COM. I went through this pain a while back and thought there was a useful discussion on microsoft.public.vc.atl, but the best I can find now is this post. which goes into some detail about variants of message loops (what to do differently if you have keystroke accelerators or modeless windows, sounds like you don't in your application).