I'm curious to know if this is possible, I want to know when a window loses focus.
I know in linux it can all be seen with xev (perhaps multiple sessions monitoring all the windows), but I need a solution in Windows.
A VM running windows in seamless mode does not help - since all internal windows are considered the 'virtualbox window', xev does not pick up internal activity.
Is there a hook to do this? Are there any other ways? I can't count on the user using alt-tab, some may click to change windows.
Related
I'm wondering if there's a good way to automate changing my display configuration in Windows 10?
I have 3 monitors attached, and I find myself wanting to configure my system in one of 3 ways:
All monitors set up to extend the desktop.
Only my central (largest) monitor enabled, others both disabled.
Only my right-most monitor enabled, others both disabled (I think hook up a spare HDMI cable on my center monitor to my laptop, and the monitor automatically switches to that input).
Manually, this involves opening the Display Settings panel, selecting the monitors, and either marking them as "Disconnected" or "Extend desktop on this display".
Is there some nice, scripting-friendly way to do this? I'm more comfortable doing this sorta thing on Linux, where I'd whip up a quick shell script to call the xrandr command a few times, or something like that...
I'm developing a software that should be able to "lock" the computer in it, so there will be no chance for any user to return to Windows and use other softwares except if he closes the software using a key (I guess this is what people call to operate in kiosk mode).
After much research I managed to disable Ctrl, Windows Key and Alt using hooks and registry files, so with this I could eliminate (I think) all ways of the user getting away from the software from the keyboard.
But now I found that if somebody plugs an USB device (e.g. a pendrive/data traveler), considering W7, the taskbar immediately apears alongside that traditional dialog where you can choose what you're going to do with the USB device you plugged (open its contents with Explorer, etc.), so somebody can go away from the software apart from the keyboard.
I would like to know how could I stop this, by code or registry (code would be much better!), so if somebody plugs a pendrive the taskbar don't appear and neither that dialog. If I can block USB input from thoose already used (by mouse and keyboard), that could also help.
Btw, if somebody knows of any other tricky way of going away from a kiosk-mode app, tell me!
Thanks,
Momergil
If you replace explorer.exe with your own application in the Shell value of the Winlogon registry key, your application will be started instead of Explorer. Then all you need to do is disable Task Manager, which can be done via a group policy setting.
The full path to the Winlogon key is
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
Why don't you just stop explorer.exe, disable Ctrl+Alt+Delete and Ctrl+Shift+Esc to enter kiosk mode?
I have been working on windows automation and monitoring.
What exactly happens when I lock the screen of a windows machine?
I am working with Windows 7 at the moment, are there big differences to the behavior if I switch to Vista or the server versions?
Is there still a desktop that can be accessed via api's?
I know that i can still send key strokes and mouse clicks to specific windows (via ControlSend and ControlClick), but there seems to be no "desktop" itself.
Could someone shed some light on this whole thing or point me at a readable source where I could get an overview over the topic?
Basically what happens is that Windows switches to the secure desktop, makes it the current one, so input is now associated with it.
The old desktop remains where it was: all the HWNDs on the desktop are still there, and any thread attached to that desktop can still access those HWNDs, get their location, and so on. You can still send messages to windows on this desktop, so long as the thread sending the message is also on that desktop.
However, since the desktop is now inactive, it cannot receive input. GetForegroundWindow will return NULL (IIRC), and you can't use SendInput any longer, since input now belongs to [a thread on] a different desktop; no controls on that inactive desktop can receive focus.
Note that sending keypress messages to a control that doesn't have focus can sometimes cause unexpected behavior, since the app or control generally never expects to receive keyboard input without getting the focus first. (This can be problematic for controls that set up some sort of input context in WM_SETFOCUS and clear it up in WM_KILLFOCUS, for example.)
In short, the UI is still there: you can do certain queries against it, but you can no longer automate it as you could on a regular desktop by sending input, and some other functions that relate to focus or input may fail.
I'm not super familiar with AutoHotKey, but the name and description of functionality suggests that it's heavily reliant on the underlying Win32 SendInput API. This won't work at all for keyboard input when a desktop is inactive.
For a reasonable overview of how desktops work and how they relate to winstations, the locked desktop, and so on, check out the Desktop article on MSDN.
One issue that I've run into in the past with desktops and automation is: how to I leave a long-running test that's using some form of user input automation (mouse, keyboard simulation), but still lock my PC so that someone can't just walk by and interfere with it. Once you lock the PC, the desktop is inactive, and so the automation stops working. A similar issue happens if the screensaver kicks in: the desktop switches, and the automation fails.
One solution is to use two PCs: let's call them Main and Test: from Main, open a remote terminal services client onto the Test machine, and then run the automated test on the test machine, but from a terminal services client window on the Main machine. Now the cool part: you can minimize that TSC window, or even lock the Main machine (or let the screensaver kick in), and that virtual session will continue working, thinking that it is still active - it's just that nobody is paying it any attention. This is one way to create a "connected" session with an active desktop, but one that no-one can interfere with, because it's protected behind the locked desktop of the Main machine.
I don't know the details, but I believe the lock screen constitutes a separate "desktop" and maybe also a separate "window station" (as I understand it a window station is merely a container for desktops). The MSDN section on window stations should hopefully be useful: http://msdn.microsoft.com/en-us/library/windows/desktop/ms687098%28v=vs.85%29.aspx
In order to access a desktop, you will need to use the regular windows api's from a thread that is on that desktop. SetThreadDesktop would probably be the easiest way to do that in C, as long as the desktop isn't on a different window station.
Unfortunately, this is already difficult for a regular privileged application, and using AutoHotkey complicates it even more. Since you don't have control over threads or over process initialization, you will probably have to create a new process in the other desktop (you can do this using the CreateProcess API, which appears to have a wrapper available for AHK to which you can supply a desktop name: http://www.autohotkey.com/forum/topic1952.html). Your process will need special privileges to do this; I'm not sure that even running as Administrator is enough.
When I install a virtual desktop manager on Windows 7, and I switch to a different virtual desktop, all the current windows disappear, also disappearing from the Start Menu.
I want to hide some of a particular application's windows, but not all of them, in a similar manner. How can I hide a window like this?
In particular, I need to hide a VirtualBox Seamless mode window, so I'm not sure minimizing the window will work. It does, however, disappear when using virtual desktop managers.
The same window cannot appear on multiple desktops. If you need your application window to appear on multiple desktops you need to create a separate window for each desktop. The desktop a window appears on depends on the thread that creates the window. You can change the desktop thread assignment using the SetThreadDesktop function.
The answer is simply ShowWindow(SW_HIDE) and ShowWindow(SW_SHOW). I think "Virtual Desktop Managers" just hide windows and show them as necessary when the desktops change.
I've only ever done server, web, and database programming, never any desktop programming. I now want to learn and have a small project I want to attempt, but am not sure which library/framework to use.
I'd like to create a small cross-platform app that runs in the system tray (and whatever the OSX equivalent is), and listens for changes to windows on the Desktop. Specifically:
Windows XP, Vista, 7, Gnome, KDE, OSX. BSD, Android, and/or iOS would be nice too but not required.
Listens for when any window gains focus, loses focus, is opened or closed, or if the window title changes (for example when switching tabs in a tabbed browser). Any other information it can scrape from the window would be useful as well.
Can store these events, preferably in an embedded database like SQLLite.
The lighter-weight the better.
Includes an options GUI accessible via a right-click menu from the system-tray icon.
Preferably FOSS, but if you know any non-FOSS please list too.
Is there a single library or framework that can do all that across multiple platforms? QT? Python? Java? Something else? TIA.
Almost any GUI framework can easily let you know when your own application gains or loses focus (or the other operations you mention). However, listening for these events for other arbitrary applications is definitely platform-specific and may or may not even be possible.
One framework for doing this on Windows is the CBT callback hook. See the question CBT Hook not working in Windows Vista for information about possible limitations on using this technique.