When my WTL C++ application is activated or gets the keyboard focus I need to determine the window handle of the application that was previously activated/had focus. However, the window handles (LPARAM) of both the WM_SETFOCUS and WM_ACTIVATE messages are both NULL (XP, 32 bit).
How can I determine the application that just lost focus when my application is activated? Is there a simple way to do this or will I need to roll a special CBT hook?
An easy way to see exactly what messages are being sent and what their parameters are is to fire up Spy++ and set it to Log Messages while you Alt+Tab to another window.
Consistent with what you've discovered, the lParam for both WM_SETFOCUS and WM_ACTIVATE will be NULL when the previously active window (or the window being active) is not in the same thread.
You might have more luck with WM_ACTIVATEAPP, as David suggested. Once you get the thread identifier, you can try calling the GetGUIThreadInfo function to determine the active window for that thread. This function will work even if the active window is not owned by the calling process.
If your app is anything other than a small utility that the user is not expected to keep open and running for very long, I would shy away from using a CBT hook if at all possible, given the potential performance implications. Unfortunately, interaction like this across process boundaries is difficult.
If you're not afraid of using things that may break with future versions of Windows, you could investigate the RegisterShellHookWindow function. I can't tell you much about it, having never used it myself, but it's an easier way to get the shell messages you would otherwise only receive by installing a hook.
It was around as far back as Windows 2000, but wasn't included in the SDK until XP SP1. It still exists in Windows Vista and 7, as far as I can tell.
Related
I have a serious problem on my work machine with a third party software window stealing keyboard focus, using a winapi monitor tool i detect that whenever the windows steal focus it first call SetForegroundWindow.
While searching about, i have found the winapi LockSetForegroundWindow, wow i thought i had solved the problem, however, LockSetForegroundWindow blocks me from activating any other window.
I also found that would be possible to 'block' the window from calling SetForegroundWindow using a hook, but i have no knowledge about hooking, would like to ask if there's something else i could try.
Usually calling SetForegroundWindow() isn't bad. Since Windows XP, there is a lock that no program do this without being allowed to do this. Read the docs: https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setforegroundwindow
This are the exceptions:
The process is the foreground process.
The process was started by the foreground process.
The process received the last input event.
There is no foreground process.
The process is being debugged.
The foreground process is not a Modern Application or the Start Screen.
The foreground is not locked (see LockSetForegroundWindow).
The foreground lock time-out has expired (see SPI_GETFOREGROUNDLOCKTIMEOUT in SystemParametersInfo).
No menus are active.
But when the third party tools uses AttachThreadInput(), it bypasses all these checks.
Just delete this "bad" software. Contact the developers.
everyone.
Now, I'm developing desktop window apps with c++ mfc.
I wanna get the mouse move and down event on the desktop background.
Why I want these, this app requires all windows move and resize event, and also mouse position.
After so many googling, I don't search things as a right solution.
Someone suggests that global mouse hooks is helpful, but I don't really know how to use this.
What is your idea about this?
Please help me to find a right solution.
Best Regards
Falcon
You're looking for the windows low level global input hook api SetWindowsHookEx
You can find more information here: https://msdn.microsoft.com/en-us/library/windows/desktop/ms644990(v=vs.85).aspx
Specifically, you're looking to use the "low level" mouse hook like so:
HHOOK mousehook = SetWindowsHookEx(WH_MOUSE_LL, MouseHookProc, NULL, 0);
You'll need to use this with a windows message queue per this link:
Why must SetWindowsHookEx be used with a windows message queue
The low-level hooks, WH_KEYBOARD_LL and WH_MOUSE_LL are different from all the other hooks. They don't require a DLL to be injected into the target process. Instead, Windows calls your hook callback directly, inside your own process. To make that work, a message loop is required. There is no other mechanism for Windows to make callbacks on your main thread, the callback can only occur when you've called Get/PeekMessage() so that Windows is in control.
A global hook like WH_KEYBOARD is very different. It requires a DLL and the callback occurs within the process that processes the keyboard message. You need some kind of inter-process communication to let your own program be aware of this. Named pipes are the usual choice. Which otherwise of course requires that this injected process pumps a message loop. It wouldn't get keyboard messages otherwise.
Favor a low-level hook, they are much easier to get going. But do pump or it won't work. And beware of timeouts, if you're not responsive enough then Windows will kill your hook without notice.
We have an application built on an older framework (Qt 3.3.5) that we would prefer not to have to attempt to upgrade to recognize touch events.
We recently upgraded it from win32-msvc2005 to win32-msvc2013. For the most part this has gone just fine, but tablets (for testing purposes, a Surface Pro on Windows 8.1) that sent mouse events when compiled against 2005 now send only WM_POINTER events when the touch screen is used in the 2013 compiled application.
I have been completely unable to find a way to get Windows to send me mouse events for touchscreen input again. My research implies that if I register for WM_TOUCH events I should also get mouse events (as indicated by many people on the internet angry about getting mouse events with their WM_TOUCH events), but my (supposedly) successful calls to RegisterTouchWindow don't seem to actually enable the WM_TOUCH events (or any mouse events), and I am still receiving pointer events.
I feel like I must be missing something obvious, especially with not being able to get WM_TOUCH events (which I don't even want, but would supposedly get me mouse events), but whatever it is continues to elude me. (Presumably it would have to be RegisterTouchWindow not being called for the specific hwnd I am actually touching on the screen, but I've gone so far as putting a RegisterTouchWindow call in specifically upon seeing any WM_POINTERUPDATE event for the hwnd that spawned the event, and outputting the result of the Register call upon it returning true and it is returning true, so that seems impossible as the cause.)
I'm also calling DefWindowProc on all WM_TOUCH/GESTURE/POINTER events, which is the only other thing the internet seems to think might be necessary for events to bubble into more basic events correctly. The framework does not call RegisterRawInputDevices and does not attempt to handle WM_INPUT events (which it wouldn't receive anyway thanks to not being registered for raw input). Any events not handled explicitly should fall through to a DefWindowProc call.
Is there even a way that older applications like ours can move to a newer msvc without going through the pain of teaching the framework to correctly handle the various touch protocols? How does an application that worked just fine on msvc2005 using the built in windows touch to mouse events conversion get that functionality back in msvc2013?
im learning to make things to other windows like resize the ie or any type of window. the only problem i don't know how i can get or give messages to other windows.
so like i pressed a key in ie i would like to get that message to my program too!
any idea
To get the messages that are sent to windows programs you have to install a hook in order to listen to the messages you want. You do this via the SetWindowsHookEx function.
However, I believe that you should read a book about this kind of behaviour, since there are certain rules you have to apply. For instance, before returning from your callback function, you have to call CallNextHookEx in order to let the other hooks handle the message. This is the first hit in books.google.com when searching for setwindowshookex.
Normally your application won't receive Windows messages for other applications (this can be a security problem, for example with keylogger spyware). However, the CBT Hook method can be used to install a hook that receives other window message inputs.
However, note that a Windows feature called UIPI can cause problems with CBT hooks.
I am developing an application for PocketPC. When the application starts the custom function SetScreenOrientation(270) is called which rotates the screen. When the application closes the function SetScreenOrientation(0) is called which restores the screen orientation.
This way the screen orientation isn't restored if the user minimizes the application and this is not acceptable.
Does anyone know where (in which event handlers) should SetScreenOrientation(int angle) be called to set the screen orientation on application start, restore orientation on minimize, set the orientation on maximize and restore the orientation on close?
Actually I don't know which event handler handles the Minimize and Maximize event.
The correct message is WM_SIZE, but Daemin's answer points to the wrong WM_SIZE help topic. Check the wParam. Be careful as your window may be maximized but hidden.
Going from my Windows CE experience you should handle either the WM_SIZE or WM_WINDOWPOSCHANGED messages. If you're working on PocketPC I would suggest you take a look at the WM_WINDOWPOSCHANGED message first because I'm not sure the WM_SIZE has the right parameters that you need.
From the WM_WINDOWPOSCHANGED message's WINDOWPOS structure take a look at the flags member, specifically SWP_SHOWWINDOW and SWP_HIDEWINDOW.
The specific version of the messages that you need to look at vary with what operating system you're using. The Pocket PC OS is built on Windows CE 3.0 (and lower), while Windows Mobile is now built on Windows CE 5.0 (even Windows Mobile 6), but was also built on Windows CE 4. (Source)
So just look under the relevant section in MSDN for the OS that you're writing for.
I don't know what these are called in the C++ world, but in .NET Compact Framework your application form's Resize event would be called when you minimize/maximize a window, and then in the event code you would check the WindowState property of the form to see if its minimized or mazimized.
Altering the state of your PDA from within your application is risky (although there are lots of good reasons to do it), because if your app crashes it will leave the PDA in whatever state it was in. I've done a lot of kiosk-type (full-screen) apps in Windows Mobile, and one of the tricks to doing this effectively is to hide the WM title bar (the top row with the Windows start button) to keep it from flashing up for a split second every time you open a new form. If the app crashes, the windows bar remains invisible until you reset the device, which isn't good. At least with screen rotation the user can restore it manually.
It really depends on the platform, but I'd go with WM_WINDOWPOSCHANGED or the OnShow. It's not wm_size.. That one is not always thrown on all platforms. Casio's don't throw the size event when you'd expect them to. TDS and Symbol's do.
Even though the MSDN is a great sourse for info, remember not all OS's are created equal. In the PPC world the hardware provider gets to create their own OS and sometimes the miss things, or purposfully ignore things.
I've got a platform here (name withheld to protect... well me) that has left and right buttons.. When you press them, you'd expect to be able to catch VK_LEFT, VK_RIGHT.. You'd be wrong. You actually get ';' or ':'. How's that for a kick in the pants.