I'm using some code like this Get active window text (and send more text to it) to send keys to the foreground window. When I run it from the console, it works great. When I run it from my service, the GetForegroundWindow() call returns 0 (zero). How can I get the foreground window handle from my service?
EDIT: A little research tells me about services running as different sessions - if that is relevant to my problem, I need to know how to get the foreground window of the console (physical monitor) session if one exists.
EDIT #2: My use case only involves XP.
Well on XP GetForegroundWindow will work if you set
Allow service to interact with desktop
check box in service properties (Log on tab). This is NOT working on Vista and newer.
But you shouldn't do that, in fact you shouldn't call GetForegroundWindow from service, services run even when there are no users logged, and they also work when there is a more than one user logged on.
I don't know why you are doing this from windows service, but maybe simple desktop app hidden in tray will do the trick.
Related
My application is a fullscreen window which is rendering a designated other window (from dwm), for example Google Chrome. I would like to know if it's possible to send events (such as mouse keyboard events) to the specified window.
Of course the designated window has to stay in background, and my current application on the foreground.
My application is written in C++. I'm working on Windows 7/8.
Just to put it into an answer.
Based on this question Does any program/language/library that interacts with windows do it via the WIN32 API? you should be able to use the windows API to send a windows message to any window. All you need to get is that windows handle, or you could do a broadcast to all windows.
The specific function http://msdn.microsoft.com/en-us/library/windows/desktop/ms644950(v=vs.85).aspx
Though that function will block until the windows responds and processes the message, this could hurt GUI performance. If you notice issues try implementing http://msdn.microsoft.com/en-us/library/windows/desktop/ms644951(v=vs.85).aspx instead.
I need to hide the taskbar and start button via a Windows service.
In a console program I can successfully call FindWindow and/or EnumWindows to get the "Shell_TrayWnd" window and then hide it using ShowWindow(hwnd, SW_HIDE).
But when the service performs FindWindow("Shell_TrayWnd", NULL) it returns NULL, and when the service performs EnumWindows it gets an incomplete list which does not include the "Shell_TrayWnd" window.
Can anyone suggest how a service can see the "Shell_TrayWnd" window, or suggest an alternative method for hiding the taskbar and start button (that works in a service)? Thanks.
The correct way to provide a UI (or otherwise interact with UI elements) for a service is to provide a GUI client that runs in the user's context and uses some IPC method (possibly RPC, possibly message-passing) to communicate with the service. UI processing within privileged services is and always has been a security hole.
If you simply want a computer-wise process to kill the taskbar, then a service is neither needed nor helpful. Configure a scheduled task to run at login. Or set the registry to launch a custom shell instead of explorer.exe. You aren't doing anything that requires privilege other than the user's own account.
To avoid blinking a console window, build your program for the WINDOWS subsystem, or use editbin /SUBSYSTEM:WINDOWS to change the flags in the PE header after build is complete.
Unfortunately, there is no way for a service to access windows. It's a (designed) limitation for services.
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.
i am using the createdesktop api to create a desktop and i would like to take a screenshot or send input mouse/keyboard without dispalying the desktop to the user.any ideeas on how to implement this???
The short answer that I've found is that you can't. You can't take a screenshot of an inactive desktop because there are no paint calls because there are no visible windows to redraw.
You can do a SwitchDesktop() call, screen shot, then SwitchDesktop() back. The user won't notice it, but you likely won't get much in the screen shot because in this short time the windows haven't had time to redraw.
Another thing is, you have to make a new thread to call SetThreadDesktop(). If you use your main thread to do so, it will fail when using a GUI application. SetThreadDesktop() fails when you have a window in the current desktop.
SysInternals has an application to manage multiple desktops (like the linux desktop switch). When your about to pick a desktop to switch to it will show you a thumbnail of the desktop. This thumbnail is not live, it is captured by the last known full redraw when the user is in that desktop. In short, if SysInternals can't do a live screenshot I doubt any of us will.
This is of course based on my own research of this exact feature. If someone has actually gotten it to work I'd love to know so I can't use it too!
Edit: This won't work for invisible desktops, I've looked to my old code, and I see that I needed that for catching screenshot of active desktop (which was not 'WinSta0\Default'), to get handle of active user desktop I've used OpenInputDesktop.
+1 ThievingSix you are right.
Sorry everyone for my misunderstanding.
You need to use SetThreadDesktop (if you are creating desktop by CreateDestkop, then you have handle for it which you pass to SetThreadDesktop). After switching desktop for thread, you can catch screenshot. Good idea would be revert to previous desktop for thread (to not 'break' other/future code).
var
lOldDesktop: HDESK;
begin
lOldDesktop:= GetThreadDesktop(GetCurrentThreadId);
try
if not SetThreadDesktop(ADesktop) then // pass handle to your desktop, or dekstop handle obtained from OpenInputDesktop
{error handle, like RaiseLastOSError or Exit(False)};
// your screenshot/input/mouse code here
finally
if lOldDesktop<> 0 then // GetThreadDesktop can fail (I don't know condition when this GetThreadDesktop(GetCurrentThreadId) could fail)
SetThreadDesktop(lOldDesktop); // revert thread to previous desktop
end;
end;
This code should run in non-main thread, as ThievingSix pointed because SetThreadDesktop can fail in that case. Safe way is spawn thread to make screenshot.
PS. I'm not sure if this will work with "send input mouse/keyboard" (it should), but for screenshot works.
Edit:
More on sessions, window stations, desktops here http://blogs.technet.com/b/askperf/archive/2007/07/24/sessions-desktops-and-windows-stations.aspx
Desktop tool (SysInternals) - http://technet.microsoft.com/en-us/sysinternals/cc817881
I have an application that manages patient demographic information. Along with this data a user can scan a picture of a patient and assign that picture to a patient. When the user clicks the scan button a separate application is opened as a dialog in order to scan the image. When running this on XP everything worked fine. The imaging application loaded up fine and gained focus. On Vista however occasionally the imaging application will not gain focus and will popup behind the main application. When running full screen or through 2008 Application Server you cannot see the application, you only get a locked screen and it appears nothing has happened. Is there any way to change the window focus management on Vista to work the way XP did? I'm looking for a way to solve this without making changes to the actual application if possible.
I think you will have to make changes to your application to allow the imaging application to take the focus. I'm going to assume that your application launches the imaging application through ShellExecute or CreateProcess. If so, you can get the process handle of the launched process either through SHELLEXECUTEINFO.hProcess (for ShellExecute) or PROCESS_INFORMATION.hProcess (for CreateProcess). Immediately after launching the imaging application call the AllowSetForegroundWindow API:
AllowSetForegroundWindow(GetProcessId(hProcess));
This will allow the imaging application to place its main window/dialog in the foreground when it's starting up.
You could try the following steps:
1. Right Click on the exe
2. Select Properties
3. Select the Compatibility Tab
4. Check the Run this program in campatibility mode for:
5. Select Windows XP (Service Pack 2)
You could iterate through all top level HWNDs and identify the scanning application via its window class, then send an appropriate message to raise the window.
I don't believe this is Vista vs XP related. I think that simply this imaging app takes longer to start on Vista.
Since Windows 2000, the window manager has prevented background applications stealing the foreground. When an application is launched, it has a window of opportunity to create and show a window that will take the foreground. If it takes too long, the window manager thinks that the current window should keep the foreground, and inhibits the other app taking the foreground when it does finally launch.
I can't think of any specific way to avoid this... other than using FindWindow to search for the other apps window after launching the app. When you eventually find it, call SetForegroundWindow on it to bring it to the foreground.