Our application does not work correctly on some Windows 8.1 devices with high DPI settings (150% or higher). Specifically, we are hosting embedded web browsers using CEF. All these embedded CEF browsers are rendering the elements offset.
The application works fine when "Disable display scaling on high DPI settings" is checked. However, this is not checked by default.
How do I ensure that my application (MFC based) builds with this setting ticked by default?
I've tried switching DPI awareness off in the manifest as per posts like: https://msdn.microsoft.com/en-us/magazine/dn574798.aspx and http://blogs.msdn.com/b/vcblog/archive/2010/03/11/mfc-applications-now-default-to-being-dpi-aware.aspx. However, this didn't seem to work.
The underlying issue was fixed with an update to CEF.
However, the solution in the interim (and the actual answer to this question, which will hopefully be useful to someone else) was to switch on the "Disable display scaling on high DPI settings" checkbox using a custom action during our (WiX) installation. Here is some code in C++:
#include "shlwapi.h"
#include <winreg.h>
//
// Include the MSI declarations etc
// - Also ensure the dll is linked with msi.lib
//
#include <msi.h>
#include <msiquery.h>
#pragma comment(lib, "msi.lib")
UINT __stdcall DisableHighDPIAware(MSIHANDLE hInstaller)
{
HKEY key;
DWORD dwDisposition;
LONG error = RegCreateKeyEx(HKEY_LOCAL_MACHINE,(LPCWSTR)L"Software\\Microsoft\\Windows NT\\CurrentVersion\\AppCompatFlags\\Layers", 0, NULL, 0, KEY_ALL_ACCESS | KEY_WRITE | KEY_WOW64_64KEY, NULL, &key, &dwDisposition);
if (error != ERROR_SUCCESS)
{
return ERROR_INSTALL_FAILURE;
}
wchar_t pathToApp[MAX_PATH];
DWORD PathSize = sizeof(pathToApp);
error = MsiGetProperty(hInstaller, L"CustomActionData", pathToApp, &PathSize);
if (error != ERROR_SUCCESS)
{
return ERROR_INSTALL_FAILURE;
}
wchar_t* value = L"~ HIGHDPIAWARE";
PathAppend(pathToApp, L"app.exe");
error = RegSetValueEx(key, (LPCWSTR)pathToApp, 0, REG_SZ, (const BYTE*)value, (DWORD)(lstrlen(value) + 1)*sizeof(TCHAR));
if (error != ERROR_SUCCESS)
{
return ERROR_INSTALL_FAILURE;
}
return ERROR_SUCCESS;
}
Related
I'm writing a library that makes a color in the window client area invisible.
In the application half, first I call window_fix_transparent_color() to make the window layered. Then I use window_set_transparent_color() to make a color in the client area invisible.
Here's my library's code:
#define _WIN32_WINNT 0x0501
#include <windows.h>
extern "C"
{
void window_fix_transparent_color(double window_handle)
{
// sets the window flags to support RGB color transparency.
SetWindowLong((HWND)(DWORD)window_handle,GWL_EXSTYLE,
GetWindowLong((HWND)(DWORD)window_handle,GWL_EXSTYLE)|WS_EX_LAYERED);
}
void window_set_transparent_color(double window_handle,double red,double green,double blue)
{
// sets the RGB color to be transparent for the specified window.
SetLayeredWindowAttributes((HWND)(DWORD)window_handle,RGB(red,green,blue),255,LWA_COLORKEY);
}
}
I'm using the version of MinGW that is packaged with the latest Code::Blocks as my compiler. It works on Windows 7, but not on Windows 8, 8.1, or 10...
Any ideas as to why that is? Also, a weird thing worth noting - it used to work on Windows 8/8.1/10, which leads me to believe a certain Windows update for those platforms may have broken my code. I haven't made any changes to my code since the time it stopped working on platforms past Windows 7.
Thanks!
Why are you using strange types and casts? You should never cast a handle type to DWORD, use INT_PTR or UINT_PTR if you must. A double is actually larger than a HWND in 32-bit applications so you are actually wasting space in addition to making things harder for yourself. A double cannot be used to store a handle in a 64-bit application!
You are also not checking the return value of SetLayeredWindowAttributes so it is impossible to know what the problem really is.
Rewrite the function with correct types and error handling:
void display_error(DWORD error)
{
char buf[100];
wsprintfA(buf, "Error %u!", error);
MessageBoxA(NULL, buf, 0, 0); // Ideally you would pass a window handle here but I don't know if your handle is actually valid
}
void window_fix_transparent_color(HWND window_handle)
{
DWORD error;
// get the window flags to see if RGB color transparency is supported.
SetLastError(0);
LONG_PTR ExStyle = GetWindowLongPtr(window_handle, GWL_EXSTYLE);
if (ExStyle == 0)
{
error = GetLastError();
if (error != 0)
{
display_error(error);
return;
}
}
if ((ExStyle & WS_EX_LAYERED) == 0)
{
// set the window flags to support RGB color transparency.
SetLastError(0);
if (!SetWindowLongPtr(window_handle, GWL_EXSTYLE, ExStyle | WS_EX_LAYERED))
{
error = GetLastError();
if (error != 0)
display_error(error);
}
}
}
void window_set_transparent_color(HWND window_handle, BYTE red, BYTE green, BYTE blue)
{
// sets the RGB color to be transparent for the specified window.
if (!SetLayeredWindowAttributes(window_handle, RGB(red, green, blue), 255, LWA_COLORKEY))
{
display_error(GetLastError());
}
}
...
HWND mywindow = CreateWindowEx(...);
window_fix_transparent_color(mywindow);
window_set_transparent_color(mywindow, ...);
My guess is that you're using "basic" or "classic" theme on Windows 7. Although
undocumented, it activates Windows XP compatibility mode for the Desktop Window
Manager, and changes the way layered windows work. That doesn't happen in later
versions of Windows.
In VC++, I use EnumWindows(...), GetWindow(...), and GetWindowLong(), to get the list of windows and check whether the window is top window (no other window as owner), and whether the window is visible (WS_VISIBLE). However, although my desktop is showing only 5 windows, this EnumWindows is giving me 50 windows, how funny! Any Windows geek here please help me clarify...
The way to list out only windows in taskbar (or similarly in Alt-Tab box) is described by Raymond in this article on MSDN blog:
Which windows appear in the Alt+Tab list?
And this is the super function to check whether a window is shown in alt-tab:
BOOL IsAltTabWindow(HWND hwnd)
{
TITLEBARINFO ti;
HWND hwndTry, hwndWalk = NULL;
if(!IsWindowVisible(hwnd))
return FALSE;
hwndTry = GetAncestor(hwnd, GA_ROOTOWNER);
while(hwndTry != hwndWalk)
{
hwndWalk = hwndTry;
hwndTry = GetLastActivePopup(hwndWalk);
if(IsWindowVisible(hwndTry))
break;
}
if(hwndWalk != hwnd)
return FALSE;
// the following removes some task tray programs and "Program Manager"
ti.cbSize = sizeof(ti);
GetTitleBarInfo(hwnd, &ti);
if(ti.rgstate[0] & STATE_SYSTEM_INVISIBLE)
return FALSE;
// Tool windows should not be displayed either, these do not appear in the
// task bar.
if(GetWindowLong(hwnd, GWL_EXSTYLE) & WS_EX_TOOLWINDOW)
return FALSE;
return TRUE;
}
Credited to the source code here:
http://www.dfcd.net/projects/switcher/switcher.c
The windows that you are talking about, with an X button and a title bar, etc. are not the only kind of windows. Buttons, dropdown menus, labels, icons, text boxes, the task bar, and just about everything else is a window too1. So EnumWindows is doing exactly what it's supposed to do: enumerate all the top level windows.
1 Even though this is true, EnumWindows only enumerates the top level windows. That means it won't enumerate any child windows:
The EnumWindows function does not enumerate child windows, with the exception of a few top-level windows owned by the system that have the WS_CHILD style.
However, many things on your desktop are windows as well, not just the "windows" you're thinking about.
The answer provided by #jondinham does work perfectly for me. So I work out my own solution.
1.Problems I met with previous solution
Running on Windows 10 home edition 1909., I get two extra unexpected Windows "Calculator" and "Setting".
In addition, windows of Tencent QQ can not be detected, because the following fails:
// the following removes some task tray programs and "Program Manager"
ti.cbSize = sizeof(ti);
GetTitleBarInfo(hwnd, &ti);
if(ti.rgstate[0] & STATE_SYSTEM_INVISIBLE)
return FALSE;
However, I think the bug may be resulted by the particularity of Tencent QQ, I can not even make its' window TOPMOST with DeferWindowPos.
Perhaps someone can help me figure out why this happened and help improving the previous solution by #jondinham.
2.My Solution
I tried to examing the icons of the windows, and filter out windows that does not have its own icon or uses the icon same as the system default. I use code snippets from answer and answer and do some modification. This solution works very well for me.
HICON get_windows_HICON_critical(HWND hwnd)
{
// Get the window icon
HICON icon = reinterpret_cast<HICON>(::SendMessageW(hwnd, WM_GETICON, ICON_SMALL, 0));
if (icon == 0) {
// Alternative method. Get from the window class
icon = reinterpret_cast<HICON>(::GetClassLongPtrW(hwnd, GCLP_HICONSM));
}
// Alternative method: get the first icon from the main module (executable image of the process)
if (icon == 0) {
icon = ::LoadIcon(GetModuleHandleW(0), MAKEINTRESOURCE(0));
}
// // Alternative method. Use OS default icon
// if (icon == 0) {
// icon = ::LoadIcon(0, IDI_APPLICATION);
// }
if(icon == ::LoadIcon(0, IDI_APPLICATION)){
// Filter out those with default icons
icon = 0;
}
return icon;
}
static BOOL CALLBACK enumWindowCallback(HWND hWnd, LPARAM lparam) {
int length = GetWindowTextLength(hWnd);
char* buffer = new char[length + 1];
GetWindowText(hWnd, buffer, length + 1);
std::string windowTitle(buffer);
// List visible windows with a non-empty title
if (IsWindowVisible(hWnd) && length != 0) {
HICON icon = get_windows_HICON_critical(hWnd);
if(icon!=0){
std::cout << hWnd << ": " << windowTitle << std::endl;
}
}
return TRUE;
}
3.Problems with my solution
My solution can not deal with Windows Store APP, according to this question.
For all people looking to find a way to remove Invisible windows like Settings or Microsoft Store from the list:
These windows are cloaked, meaning they still have the dwStyle WS_VISIBLE, but the user can't see them.
You can detect this using the function DwmGetWindowAttribute. The dwAttribute you want to get is DWMWA_CLOAKED (enum constant 14). Only if the value in pvAttribute after the method call is 0, the window is not cloacked.
I have a windows application written in C++.
The application generates certain configuration files in a hidden directory.
I want to give user an option to open that directory from my application.
Clicking that option should open a windows explorer like dialog with an input directory location.
I spend time searching for a similar api, but end up with certain dialogs like "DlgDirListComboBoxW" or "GetOpenFileName" or "GetSaveFileName".
I am looking for an api to open normal Windows explorer like Dialog with an input directory location.
It would be really helpful if the api belongs to CommonDialogs section.
You can use the SHBrowseForFolder
It shows a dialog similar to this:
This is a example for how to use it:
BOOL GetFolder(LPCSTR folderpath,
LPCSTR szCaption,
HWND hOwner /*= NULL*/)
{
BOOL retVal = FALSE;
// The BROWSEINFO struct tells the shell
// how it should display the dialog.
BROWSEINFO bi;
memset(&bi, 0, sizeof(bi));
bi.ulFlags = BIF_USENEWUI;
bi.hwndOwner = hOwner;
bi.lpszTitle = szCaption;
// must call this if using BIF_USENEWUI
::OleInitialize(NULL);
// Show the dialog and get the itemIDList for the
// selected folder.
LPITEMIDLIST pIDL = ::SHBrowseForFolder(&bi);
if(pIDL != NULL)
{
// Create a buffer to store the path, then
// get the path.
char buffer[_MAX_PATH] = {'\0'};
if(::SHGetPathFromIDList(pIDL, buffer) != 0)
{
// Set the string value.
folderpath = buffer;
retVal = TRUE;
}
// free the item id list
CoTaskMemFree(pIDL);
}
::OleUninitialize();
return retVal;
}
How about:
HWND hWndOwner = NULL;
ShellExecute(
hWndOwner,
_T("explore"),
_T("c:\\some\\path"),
NULL,
NULL,
SW_SHOWNORMAL);
You can set hWndOwner to your main window handle if you're so inclined and can choose from a variety of other options.
For more information and usage details, check out the MSDN page on ShellExecute.
I am writing a remote desktop application like TeamViewer in C++ on Windows 7 (x64) and Windows 8 (x64).
1. What made me stuck
I have implemented the mouse input and keyboard input by using SendInput(). I found SendInput() worked perfectly when the process ran under winsta0\desktop. But after the user locked the computer or the screensaver launched, it didn’t work.
If I run the process under winsta0\winlogon, SendInput() doesn’t work under winsta0\default.
2. What I have tried
I have tried using SetThreadDesktop() to switch the process from winsta0\desktop to winsta0\winlogon, but I got error 170: "The requested resource is in use" and I stucked.
3. What I want to know
I noticed that TeamViewer has a process named TeamViewer_Desktop.exe which can control mouse and keyboard under Winlogon, Default and Screensaver. How does it do it?
Can you provide the code to help me understand how to solve my question?
I want to know** how I can make my application switch between the default desktop and Winlogon desktop. So I can control the mouse and keyboard on a secured desktop without creating another process running under winlogon.exe.
You did the right thing: SetThreadDesktop is correct. The error is telling you that you have some resources open on the current desktop though, such as a window, and that prevents you from switching. If you had tried to produce a minimal test-case (as you are meant to do when asking questions here!) you would have found that out.
Cut out parts of your program until you find the chunk that's preventing you switching desktop. Some Windows APIs are nasty and prevent you switching desktop, so need to be called in a dedicated thread.
As #NicholasWilson said, SetThreadDesktop() is the correct way to switch a process between default desktop and winlogon desktop.
The error 170, "The requested resource is in use", occurred because I called MessageBox() before SetThreadDesktop() called. Also calling CreateWindow() can cause the error.
I think any function associated with GUI creation called before SetThreadDesktop() called can cause the error. So if you want to invoke SetThreadDesktop() successfully, you must be sure not to call any GUI creation function before you invoke SetThreadDesktop().
Code
Code here is how to switch the process to the specified desktop.
Usage: SetWinSta0Desktop(TEXT("winlogon")), SetWinSta0Desktop(TEXT("default"))
SetWinSta0Desktop() function:
BOOL SetWinSta0Desktop(TCHAR *szDesktopName)
{
BOOL bSuccess = FALSE;
HWINSTA hWinSta0 = OpenWindowStation(TEXT("WinSta0"), FALSE, MAXIMUM_ALLOWED);
if (NULL == hWinSta0) { ShowLastErrorMessage(GetLastError(), TEXT("OpenWindowStation")); }
bSuccess = SetProcessWindowStation(hWinSta0);
if (!bSuccess) { ShowLastErrorMessage(GetLastError(), TEXT("SetProcessWindowStation")); }
HDESK hDesk = OpenDesktop(szDesktopName, 0, FALSE, MAXIMUM_ALLOWED);
if (NULL == hDesk) { ShowLastErrorMessage(GetLastError(), TEXT("OpenDesktop")); }
bSuccess = SetThreadDesktop(hDesk);
if (!bSuccess) { ShowLastErrorMessage(GetLastError(), TEXT("SetThreadDesktop")); }
if (hDesk != NULL) { CloseDesktop(hDesk); }
if (hWinSta0 != NULL) { CloseWindowStation(hWinSta0); }
return bSuccess;
}
ShowLastErrorMessage() function:
void ShowLastErrorMessage(DWORD errCode, LPTSTR errTitle)
{
LPTSTR errorText = NULL;
FormatMessage(
FORMAT_MESSAGE_FROM_SYSTEM |
FORMAT_MESSAGE_ALLOCATE_BUFFER |
FORMAT_MESSAGE_IGNORE_INSERTS,
NULL,
errCode,
MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT),
(LPTSTR)&errorText,
0,
NULL);
if ( NULL != errorText )
{
WCHAR msg[512] = {0};
wsprintf(msg, TEXT("%s:\nError Code: %u\n%s\n"), errTitle, errCode, errorText);
LocalFree(errorText);
errorText = NULL;
OutputDebugString(msg);
}
}
I'm facing some weird (at least for me) behavior on using the Common Item Dialogs in my MFC Windows application running on Windows 7 or Vista.
According to the MSDN http://msdn.microsoft.com/en-us/library/windows/desktop/bb776913(v=vs.85).aspx I'm using the new interfaces to display file open and save dialogs:
bool OpenFileDialog(CString& strFile, CString strTitle, CStringArray& astrFilter, CStringArray& astrFilterExtension, ULONG nFlags, HWND hParentWnd)
{
USES_CONVERSION;
INT_PTR nResult = 0;
INT_PTR nFilterCount = astrFilter.GetCount();
IFileDialog* pfod = 0;
HRESULT hr = ::CoCreateInstance(CLSID_FileOpenDialog, NULL, CLSCTX_INPROC_SERVER, IID_PPV_ARGS(&pfod));
if(SUCCEEDED(hr))
{
// New dialog starting with Vista/Windows 7
COMDLG_FILTERSPEC* pOpenTypes = 0;
if((nFilterCount > 0) && (nFilterCount == astrFilterExtension.GetCount()))
{
pOpenTypes = new COMDLG_FILTERSPEC[nFilterCount];
for(int nIdx = 0; nIdx < nFilterCount; nIdx++)
{
pOpenTypes[nIdx].pszName = astrFilter[nIdx].GetBuffer();
pOpenTypes[nIdx].pszSpec = astrFilterExtension[nIdx].GetBuffer();
}
}
// Set the file types to display.
if(pOpenTypes)
{
hr = pfod->SetFileTypes(nFilterCount, pOpenTypes);
if(SUCCEEDED(hr))
hr = pfod->SetFileTypeIndex(0);
}
if(!strFile.IsEmpty())
pfod->SetFileName(strFile);
if(!strTitle.IsEmpty())
pfod->SetTitle(strTitle);
if(SUCCEEDED(hr))
{
// Ensure the dialog only returns file system paths.
DWORD dwFlags;
hr = pfod->GetOptions(&dwFlags);
if(SUCCEEDED(hr))
{
dwFlags |= FOS_FORCEFILESYSTEM;
if(nFlags & OFN_FILEMUSTEXIST)
dwFlags |= FOS_FILEMUSTEXIST;
if(nFlags & OFN_PATHMUSTEXIST)
dwFlags |= FOS_PATHMUSTEXIST;
hr = pfod->SetOptions(dwFlags);
if(SUCCEEDED(hr))
{
// Create an event handling object, and hook it up to the dialog.
IFileDialogEvents* pfde = NULL;
DWORD dwCookie;
// Actually only added for debugging purposes
/*hr = CDialogEventHandler_CreateInstance(IID_PPV_ARGS(&pfde));
if(SUCCEEDED(hr))
{
// Hook up the event handler.
hr = pfod->Advise(pfde, &dwCookie);
if(!SUCCEEDED(hr))
{
pfde->Release();
pfde = 0;
}
}*/
// Now show the dialog. Usually called with hParent == 0
if(hParentWnd)
hr = pfod->Show(::GetWindow(hParentWnd, GW_OWNER));
else
hr = pfod->Show(0);
// do something with the path when the dialog was closed...
So the dialog appears and works fine if I want to select a file from a normal drive. I can navigate through the folders and select any file I want. On leaving the dialog I also get the correct file information.
But it doesn't work for one of the Libraries in the navigation pane on the left side. Whenever I try to select a Library like Documents, Videos or Pictures the dialog doesn't update the right pane which shows the folder/library content.
What I noticed is that on clicking a Library in the file open/save dialog the OnFolderChanging() event of the IFileDialogEvents interface is fired but the OnFolderChange() and OnSelectionChange() are not. Those events are fired if I click and navigate on a "normal" drive like C.
I also tried to call the dialogs early in my InitInstance method to avoid possible side-effects with my other code but this didn't help either.
Is there someone who had the same behavior and was able to resolve this?
Thanks a lot!
So I finally found the answer to this issue. Creating the new MFC project for the application was the actual hint to solve this. The reason was that the "Stack reserve size" was too big. The settings in the old VS6.0 project had the stack size increased to more than 100MB. Apparently the IFileDialog based dialogs do not work properly when the reserved stack size is simply too large (other thing might don't work also as expected). So I had to set it back to 15MB in my case.