Is there a way in QT to detect when the system is entering screensaver (in windows)?
keep in mind, that my process is a background process and isn't active all the time, so i can't use this as an Qevent... and i don't want to try and figure out if the user hasn't touched the keyboard or mouse for x time, only to detect if the pc has opened the screen saver... any ideas?
Related
OK, I get it: focus stealing is evil. Or at least it is 99.9% of the time. But I really need to steal the focus reliably on Windows 8, and so far I'm thwarted by the hordes of people insisting focus stealing is always evil.
Scenario: we run a custom application on an ordinary PC running Windows 8.1 (soon to be Windows 10). The screen, keyboard and mouse sit roughly 5m off the ground up some stairs that the forklift operator really shouldn't climb. The one input device they have is a numeric keypad on an extender cable down at their level. Everything they need to do they can do from that keypad... so long as some evil program hasn't stolen our application's focus, or some remote user hasn't logged out and left another application with focus.
The application is essentially a maximised desktop application - it fills the screen (but is not strictly a "full screen" or "topmost" application), and therefore allows other applications to appear in front of it when required. But when the mouse goes idle, we want this application to resume its "normal" position in front of all other applications so that it gets focus and the numeric keypad input will work reliably.
On Windows 7, using SetForegroundWindow() (enabled by AllowSetForegroundWindow() works fine - the application can be brought back to the front and resume focus. On Windows 8, SetForegroundWindow() only results in the taskbar icon flashing, but the application does not regain focus, forcing our user to climb the stairs... where the full keyboard and mouse is too tempting for them not to press buttons they shouldn't, and chaos typically ensues.
So please sir: can our (MFC, desktop) application steal back the focus once the mouse has gone idle for 1 minute, because it is more or less the only application that should normally be running anyway. If that is permitted, how do we steal it reliably?
Configure hotkeys on numeric keypad (RegisterHotKey).
Pressing a registered hotkey gives you the foreground activation love by Raymond Chen
After you call the RegisterHotKey function to register a hotkey, the
window manager will send you a WM_HOTKEY message when the user presses
that hotkey, and along with it, you will get the foreground love. If
you call SetForegroundWindow from inside your hotkey handler, the
foreground window will change according to your instructions.
Possible solution (with major limitations): do nothing extra; wait.
One of our service technicians observed that on the third or fourth attempt to regain focus using AllowSetForegroundWindow() and SetForegroundWindow() as had been working on Windows 7, Windows 8 finally allowed our application to regain focus. It is not clear what the conditions are that make this work, or if it works reliably, but we have now observed our application regaining focus from beneath Chrome, from beneath another (self-developed) MFC application, and from beneath a third party application - all desktop applications. Approximately 3-4 minutes needed to elapse in each case before focus was surrendered back to our (desktop) application.
However, we have not witnessed it regain focus from beneath metro applications, and nor do we expect it (e.g. hit the Windows key and leave the system lingering on the Start screen).
In our (restricted) situation, we are willing to take the gamble that our users will not launch a metro application that obscures our desktop application, at least not without restoring our application, since their business relies on it. Our main concern is that one of our busy service technicians will log in remotely, get distracted, and carelessly leave one of our desktop utilities with the focus. Waiting 3-4 minutes appears to be a solution to this specific scenario.
I would try it in this way:
Setup a timer in you application. That checks GetForegroundWindow on a regular basis.
If GetForgroundWindow does not belong to your process (GetWindowThreadProcessId)
If a different process onws the foreground window use AttachThreadInput and attach your input queue to the input queue of the other process.
Now use SetForegoundWindow and detach the thread input again.
Now you can use SetFocus as needed to control the input focus of your program.
Does Windows provide some sort of mechanism to detect when an app running in fullscreen mode (e.g. games, media players, etc.) exits fullscreen mode, either returning to windowed mode or exiting its process?
There is no such thing as "fullscreen mode" or "windowed mode" as far as the OS is concerned. A window simply has dimensions, which may happen to be the same as the screen dimensions or not. The application that owns the window controls that behavior, not the OS, so only the application knows when it is displaying the window in "full screen" or "windowed" mode.
That being said, the application may optionally call ChangeDisplaySettings/Ex() with the CDS_FULLSCREEN or CDS_RESET flag when changing modes. That will send WM_DISPLAYCHANGE notifications to all top-level windows, but it will not tell them that a fullscreen window is being displayed or not.
As for detecting process termination, WMI has an event for that. See Receiving Event Notifications Through WMI.
A simple approach to this, and what I decided to go with, is using RegisterWaitForSingleObject on the created process as explained here: https://stackoverflow.com/a/22418949/1019385
I found it more approachable than the WMI solution.
I've written a win32 App in C++ (a game) and I want to be able to know if the application has lost focus due to the user pressing CTRL-ALT-DEL and starting the task manager. How can I do this? What I want to do after detecting the event is to minimize the window of my game and pause its processing (animations, audio, etc.). However, if the user returns from the CTRL-ALT-DEL menu to the game then it should keep running as usual. I've thought that I could check for key presses on CTRL, ALT and DEL but that doesn't seem to work and just reacting to the lost the focus (WM_KILLFOCUS) is not what I want.
You can use WTSRegisterSessionNotification(), you'll get the WM_WTSSESSION_CHANGE message when the user presses Ctrl+Alt+Del and switches to the secure desktop.
Beware that you cannot tell that it was actually the secure desktop that he switched to, that would be rather nasty security leak. You'll also get the notification when he switches to another logon session. Also a case where you want to stop your game of course.
For that matter, a game ought to automatically pause whenever the game window loses the foreground. Nobody likes to be killed when they switch to their email reader :) Use the WM_ACTIVATEAPP message
I am working on a program for Windows, and only on Windows xp 32 bit my bug happens.
The thing is that when Windows is in sleep mode and I wake it up and my GUI is messed up.
My program is connected to a server, and when the computer is waking up, the connection is broken. My GUI is going to the Login panel and doing a re-connection, but for some reason, the GUI display is only showing the animation of the re-connection, with all the rest of the components from the last screen also displayed.
What it should be showing is a blank screen with-reconnecting animation.
I want to catch the event/message that the system is passing to my application when it is waking up to clear the screen before reconnecting.
Is there any way to do so?
I have been thinking a lot over keyboard handling. How does it work? I can't seem to google me to a good explaining.
I know that a keyboard interrupt is made every time a key is pressed. The processor halts whatever it is processing and load the keyboard data from the keyboard buffer, storing it in a system level buffer.
But what happens next? Let's take a practical example. What happens when I run the following piece of code:
...
std::string s;
std::cin >> s;
....
Does the cin read from a user level representation of the system level keyboard buffer? That makes perfect sense in my head because then 2, or more processes can read from the same buffer, and by that way I don't loose any key presses. But does it work this way?
I know I'm talking in very general terms. The OS I'm using is OS X.
Except in rare situations, your keyboard and display are managed by a Window Manager: X11, Gnome, KDE, Carbon, Cocoa or Windows.
It works like this.
The keyboard driver is part of the OS.
The window manager is a privileged process, which acquires the device during startup. The window manager "owns" the device. Exclusively.
The interrupts go to OS.
The OS responds the interrupt by queueing. Eventually -- when there's nothing of a higher priority to do -- it captures the keyboard input from the interrupt and buffers it.
The owning process (the window manager) is reading this buffer. From this, it creates keyboard events.
Your application works through the window manager.
Example 1 -- You're running a command-line application. In a terminal window. When terminal window is front-most, the window manager directs events at the terminal window. Keyboard events become the stdin stream.
Example 2 -- you're running GUI application. In your own application's window. When your application's window is front-most, the window manager direct events at your application window. Keyboard events are available for your various GUI controls to process. Some keyboard events may cycle among the controls or active buttons.