I am using GetForegroundWindow() from a service as i want to monitor the window that is in focus but the function is returning null on windows 7 due to interactive user problem. Is there any way by which i can get the focused window in my service?
HWINSTA hWinStaUser = OpenWindowStation(_T("WinSta0"), FALSE, MAXIMUM_ALLOWED);
if (SetProcessWindowStation(hWinStaUser))
{
/* -- Open user's desktop "Default". -- */
HDESK hDeskUser = OpenInputDesktop(0,FALSE,MAXIMUM_ALLOWED);
//HDESK hDeskUser = OpenDesktop(_T("Default"), 0, FALSE, MAXIMUM_ALLOWED);
/* -- Set thread desktop to "Default". -- */
if (SetThreadDesktop(hDeskUser))
{
HWND hwndActiveWin = GetForegroundWindow();
int idActive = GetWindowThreadProcessId(hwndActiveWin, NULL);
if ( AttachThreadInput(GetCurrentThreadId(), idActive, TRUE) )
{
HWND hwndFocused = GetFocus (); // focused control within the active window, i.e. focus throughout the screen
if(hwndFocused != NULL)
{
DWORD dwProcessID = 0;
GetWindowThreadProcessId(hwndFocused, &dwProcessID);
processPid = dwProcessID;
}
AttachThreadInput(GetCurrentThreadId(), idActive, FALSE);
}
}
you need to understand the problem itself. services cannot interact with desktop because of security risk and because there can be many desktops (many logged in users). GetForegroundWindow() is an interaction with desktop. There's no simple workaround. Complicated one involves separate process running as windows application (not a service) and communicating with your service.
Related
I need to disable notifications at my app when there is another app fullscreen like powerpoint or VLC to do not bother a user.
For now, I get to this code, but it always returns true. Whether there is some app fullscreen or not. I am not sure whether this should work only for app bars or also taskbar.
HWND hWnd;
hWnd = FindWindow(L"Shell_TrayWnd", nullptr);
if( hWnd )
{
APPBARDATA apd;
apd.cbSize = sizeof(APPBARDATA);
apd.hWnd = hWnd;
bool uState = bool(SHAppBarMessage(ABN_FULLSCREENAPP , &apd));
if(uState)
qDebug()<<"fullscreen";
else
qDebug()<<"not fullscreen";
}
ABN_FULLSCREENAPP is not a message you send to the shell, it's a message the shell sends to you when an application enters or leaves full screen mode. The message is sent to the owner of an app bar created with ABM_NEW.
Documentation is here.
My reading of the documentation is that you have to create an app bar to receive this message but you may be able to set it to zero height or width with ABM_SETPOS if you want to hide it.
I have an installation dialog (made with nsis) that has two buttons (install and cancel). I'm trying to write automated tests for the install process using low level win32 api. To click on the button(s) I use the following code:
char windowName[] = "Desktop Application Setup";
char cancelButtonText[] = "Cancel";
HWND hWndMainWindow = NULL;
HWND hButton = NULL;
hWndMainWindow = FindWindow(NULL, windowName);
if (hWndMainWindow)
{
hButton = FindWindowEx(hWndMainWindow, NULL, NULL, cancelButtonText);
if (hButton)
{
SendMessage(hButton, BM_CLICK, 0, 0);
}
}
On Windows 7, this works perfectly. On Windows 10, it simply does nothing. It finds the button, it sends the message, but the click just doesn't happen.
Is this some security thing introduced in Windows 10? Is it a known issue?
it is better to send WM_COMMAND with the ID of the button, but the way you are doing works also if Lang is always in English. but the problem with your case is that buttons on dialog usually have an "&" to indicate the keyboard short cut, and usually hidden by system unless you press alt key. (like menus).
so: text of the button is most likely to be "&cancel"
The following sample has reliably returned the name of the process that is associated with the active window, but does not work with the newer modern/universal apps because it returns the name of a helper process WWAHost.exe on Windows 8 and ApplicationFrameHost.exe on Windows 10 rather than the name of the app.
HWND active_window = GetForegroundWindow();
GetWindowThreadProcessId(active_window, &active_process_id);
HANDLE active_process = OpenProcess(PROCESS_QUERY_INFORMATION | PROCESS_VM_READ, FALSE, active_process_id);
GetProcessImageFileName(active_process, image_name, 512);
With Windows 10 the ApplicationFrameHost.exe is the process that creates the window handles and is what gets returned by GetWindowThreadProcessId(), is there another Win32 API that can be used to get the active process of universal app that is active?
Also tried using GetApplicationUserModelId() and GetPackageFullName() with no success as they return APPMODEL_ERROR_NO_APPLICATION and APPMODEL_ERROR_NO_PACKAGE respectively because the active_process handle is just the helper process and not the process of the active application.
Any other APIs to use to get the process name of a Modern/Universal application given the hwnd of the window, or otherwise figure out the process name of the universal app is active.
Thanks in advance!
Be sure to use the Spy++ utility when you want to reverse-engineer something like this. Included with Visual Studio, you need the 64-bit version in Common7\Tools\spyxx_amd64.exe. Use Search > Find Window and drag the bullseye to a UWP app, like Weather.
You'll see the window you'll find with GetForegroundWindow(), it has at least 3 child windows:
ApplicationFrameTitleBarWindow
ApplicationFrameInputSinkWindow
Windows.Core.UI.CoreWindow, that's the host window for the UWP app and the one you are interested in. Right-click it and select Properties, Process tab, click the Process ID. That takes you to the real owner process you want to know.
So you just need to make an extra step from the code you already have, you just have to enumerate the child windows and look for one with a different owner process. Some C code, trying to make it as universal as possible without making too many assumptions and not enough error checking:
#include <stdio.h>
#include <Windows.h>
typedef struct {
DWORD ownerpid;
DWORD childpid;
} windowinfo;
BOOL CALLBACK EnumChildWindowsCallback(HWND hWnd, LPARAM lp) {
windowinfo* info = (windowinfo*)lp;
DWORD pid = 0;
GetWindowThreadProcessId(hWnd, &pid);
if (pid != info->ownerpid) info->childpid = pid;
return TRUE;
}
int main()
{
Sleep(2000);
HWND active_window = GetForegroundWindow();
windowinfo info = { 0 };
GetWindowThreadProcessId(active_window, &info.ownerpid);
info.childpid = info.ownerpid;
EnumChildWindows(active_window, EnumChildWindowsCallback, (LPARAM)&info);
HANDLE active_process = OpenProcess(PROCESS_QUERY_INFORMATION, FALSE, info.childpid);
WCHAR image_name[MAX_PATH] = { 0 };
DWORD bufsize = MAX_PATH;
QueryFullProcessImageName(active_process, 0, image_name, &bufsize);
wprintf(L"%s\n", image_name);
CloseHandle(active_process);
return 0;
}
Output on the Weather program:
C:\Program Files\WindowsApps\Microsoft.BingWeather_4.5.168.0_x86__8wekyb3d8bbwe\
Microsoft.Msn.Weather.exe
Here is a small console app application that continuously (so you can test it easily selecting different windows on your desktop) display information about the current foreground window process and store process, if any.
Apps can have a window hierarchy that can span multiple processes. What I do here is search the first sub window that has the 'Windows.UI.Core.CoreWindow' class name.
This app uses the UIAutomation API (and also smart pointers, smart BSTRs and smart VARIANTs provided by the #import directive). I suppose you can do the same with standard Windows SDK, but I find the UIAutomation used this way quite elegant.
#include "stdafx.h"
#import "UIAutomationCore.dll"
using namespace UIAutomationClient;
int main()
{
// initialize COM, needed for UIA
CoInitialize(NULL);
// initialize main UIA class
IUIAutomationPtr pUIA(__uuidof(CUIAutomation));
do
{
// get the Automation element for the foreground window
IUIAutomationElementPtr foregroundWindow = pUIA->ElementFromHandle(GetForegroundWindow());
wprintf(L"pid:%i\n", foregroundWindow->CurrentProcessId);
// prepare a [class name = 'Windows.UI.Core.CoreWindow'] condition
_variant_t prop = L"Windows.UI.Core.CoreWindow";
IUIAutomationConditionPtr condition = pUIA->CreatePropertyCondition(UIA_ClassNamePropertyId, prop);
// get the first element (window hopefully) that satisfies this condition
IUIAutomationElementPtr coreWindow = foregroundWindow->FindFirst(TreeScope::TreeScope_Children, condition);
if (coreWindow)
{
// get the process id property for that window
wprintf(L"store pid:%i\n", coreWindow->CurrentProcessId);
}
Sleep(1000);
} while (TRUE);
cleanup:
CoUninitialize();
return 0;
}
Does taking snapshot of running processes and pulling the name out of it by comparing process id not work?
Full reference here:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms686837(v=vs.85).aspx
But you fix the snapshot with CreateToolhelp32Snapshot().
Or from WTSEnumerateProcesses() and surrounding API?
Pretty sure it worked in Win 8. Is it broken in 10?
Starting from Win10 Anniversary Update ApplicationFrameHost child window return anything but UWP application. It worked only in Tablet mode after relogon.
I'm coding an MFC/C++ app that places several icons on the system tray. (The number of icons is controlled by a user and can reach up to 10 or so if the user wishes to do so -- each per certain function of the app.)
My question is, can I control the order at which those icons are placed on the tray?
What happens now is that when I call
Shell_NotifyIcon(NIM_ADD, &nid);
in a certain order, the order at which icons appear on the actual tray is different.
The task tray is just a ToolBar32 control. You can get a handle to it with something like this:
HWND hWnd = ::FindWindow(_T("Shell_TrayWnd"), NULL);
if(hWnd)
{
hWnd = ::FindWindowEx(hWnd,NULL,_T("TrayNotifyWnd"), NULL);
if(hWnd)
{
hWnd = ::FindWindowEx(hWnd,NULL,_T("SysPager"), NULL);
if(hWnd)
{
hWnd = ::FindWindowEx(hWnd, NULL,_T("ToolbarWindow32"), NULL);
}
}
}
Then you should be able to call this:
::SendMessage(hWnd, TB_MOVEBUTTON, nFrom, nTo);
It's kind of weird issue, let me try to explain. I wrote a (dialog based) app in c++/MFC that supports drag-n-dropping.
I do the following test on Windows 7 with default themes. My app is running on the screen. It is not a top window (in its z-order) or in other words it's obscured by other windows on top of it.
If I begin dragging a link or just a text selection from the Chrome or Firefox web browser, first into my app's icon on the taskbar, the icon flashes and my app pops up on the screen (by receiving the top z-order) so I can then drag-and-drop into my app. Everything works fine.
If I do the same from IE 9 (version 9.0.8112, update versions 9.0.12) when I drag selected text or a link first to the taskbar icon of my app to make my app become top window (in z-order), the app icon continues flashing but it never gets shown on the screen like it happens with Chrome or FF, so as a result I have to abandon my drag-and-drop.
Any idea why is it happening like that with IE and if there's a way to fix it?
EDIT: Here's the code sample in regards to my comments below:
HRESULT __stdcall DragEnter(IDataObject* pDataObject, DWORD grfKeyState, POINTL pt, DWORD* pdwEffect)
{
//IDropTarget::DragEnter
m_fAllowDrop = QueryDataObject(pDataObject);
if(m_fAllowDrop)
{
//SUCCESS
// get the dropeffect based on keyboard state
}
else
{
//FAILURE
*pdwEffect = DROPEFFECT_NONE;
}
return S_OK;
}
BOOL QueryDataObject(IDataObject* pDataObject, int* pnOutDataType)
{
static FORMATETC fmtetc_file = {CF_HDROP, 0, DVASPECT_CONTENT, -1, TYMED_HGLOBAL};
static FORMATETC fmtetc_txt = {CF_UNICODETEXT, 0, DVASPECT_CONTENT, -1, TYMED_HGLOBAL};
BOOL bRes = FALSE;
HRESULT hr;
//See if our data type
hr = pDataObject->QueryGetData(&fmtetc_file);
if(hr == S_OK)
{
bRes = TRUE;
}
//In my case hr is E_FAIL or 0x80004005
hr = pDataObject->QueryGetData(&fmtetc_txt);
if(hr == S_OK)
{
bRes = TRUE;
}
//In my case hr is E_FAIL or 0x80004005
return bRes;
}
As part of its sandboxing to prevent unauthorized changes to the machine, Internet Explorer runs in a lower UIPI (User Interface Privilege Isolation) integrity level than other apps do. As such, it does not have permission to access your app by default, which is more likely to be running in a medium or high UIPI integrity level (depending on whether it is UAC elevated or not). The flashing taskbar button means that something is trying to bring your app to the foreground but does not have permission to do so (see the documentation of SetForegroundWindow() for more details). UIPI does not allow a lower-integrity process to send window messages to a higher-integrity process unless the receiving process explicitally tells UIPI to allow it. Chrome and FireFox are likely running in the same integrity level as your app. In order to support drag-and-drop from Internet Explorer, call ChangeWindowMessageFilter() or ChangeWindowMessageFilterEx() to let your app receive WM_DROPFILES, WM_COPYDATA, and WM_COPYGLOBALDATA (0x0049) messages from lower-integrity processes.
Update: It looks like Internet Explorer in particular imposes additional restrictions on drag&drop operations when it is running in Protected Mode:
How to handle drag & drop from low integrity Internet Explorer
Understanding and Working in Protected Mode Internet Explorer - Allowing Drag and Drop Operations in your Application