Is there any API to retrieve a state of Windows 10 Power mode slider?
I was looking at Windows.System.Power namespace. But PowerManager class seem to provide only an immediate state of the power system, but not user preferences set by the slider.
The slider also exists somehow in parallel with previous "power plan" settings. It does not seem that the slider state is reflected directly in Win32_PowerPlan.
Change the position of the slider, and the registry key:HKLM\SYSTEM\ControlSet001\Control\Power\User\PowerSchemes\ActiveOverlayAc/DcPowerScheme will also change.
ActiveOverlayAcPowerScheme is for non-battery powered and ActiveOverlayDcPowerScheme is for battery powered.
However, Starting with Windows release 1903 the slider is available for AC only devices as an OEM opt-in feature.
The values of the key ActiveOverlayAcPowerScheme and the corresponding slider modes are as follows:
Better Battery {961CC777-2547-4F9D-8174-7D86181b8A7A}
Better Performance {381B4222-F694-41F0-9685-FF5BB260DF2E}
Best Performance {DED574B5-45A0-4F42-8737-46345C09C238}
the ActivePowerScheme will be overlaid with ActiveOverlayAcPowerScheme.
you can retrieve the key value to get the slider mode.
Related
I'm working on a Win32 app with multiple windows, some of which use WS_POPUPWINDOW style (no caption) and some of which use WS_OVERLAPPEDWINDOW style. The app has System DPI awareness.
When I move the overlapped windows between monitors, they scale to match the current monitor DPI as expected. But the popup windows only do this if there are no other open overlapped windows. Otherwise, they always try to match the scaling of the last active overlapped window in the same process, even if it's on another monitor with a different scale factor.
I guess this makes sense for some use cases, since you'd always want eg. a popup menu to match the scale of the current window. But I want my popups to behave as independent windows with their own scale factor.
How do I make popup windows always match the DPI of the monitor that they're positioned on?
As a quick fix before I eventually convert the app to per-monitor DPI awareness, I created an invisible overlapped owner window for the popup that tracks its position / size. This ensures that whenever the popup is active, it updates to use its owner's scaling, which always matches the current monitor.
We've run into a tricky situation developing our Windows application (problem applies to both our old WinForm-based app as well as our new UWP-based app). The application is used on a touch screen based device (15 – 27 inch touch screen depending on system size). Hence, no touch pad involved. Touch screen only (which does not have any Windows-related adjustments available that does effect this scenario. The touch device is identified as a “10-point multi touch screen” by Windows.
When using the tap-gesture (as opposed to previously using PointerPressed) the interface gets very picky about the way the user taps. If there is only the slightest "glide" when the finger touches the button (which is very often the case, it turns out, in usability studies) the pan-event is trigged (as opposed to the tap-event) and the button is not "pressed". The pan gesture is used for other purposes in the application.
The problem is specifically noticeable on smaller devices (with higher DPI). Probably a function of the finger used "does not scale" as the display does.
Is there a way to adjust for high DPI for the tap gesture? Something along the lines “if the slide is less than x pixels, then it’s not a pan but a tap”-kind of value?
“Google” has little to offer on the subject.. On the other hand - we simply cannot be the first to run into this situation!?
I am building a mini project where I want to have a color picker feature. I found the Digital Color Meter on macOS is helpful. I did some search and found I can write a simple AppleScript to activate the application.
It would be awesome if I can monitor the next left-click mouse event (even if I am not focusing Digital Color Meter application). By monitoring the next left-click mouse event, I want to get the value from the R, G and B options as you can see from the image above.
I think mouse event handler should be able to achieve (though I don't know how to do it). I am not sure whether I can read the value from the Application...
Simply use
choose color
from Standard Scripting Additions.
In the color picker window there is also a eyedropper (pipette).
Explorer seems to always start my application with SW_MAXIMIZE (STARTF_USESHOWWINDOW is set in STARTUPINFO.dwFlags). I know that ShowWindow will use this value the first time you/Windows needs to display a window but it has the unfortunate consequence of maximizing a window that should never be maximized.
My window is created with CreateDialogIndirectParam and has the following styles: WS_CAPTION|WS_SYSMENU|WS_MINIMIZEBOX|WS_CLIPCHILDREN|DS_MODALFRAME|DS_CENTER|WS_VISIBLE. Why does ShowWindow not check if WS_MAXIMIZEBOX is set before allowing STARTF_USESHOWWINDOW to force SW_MAXIMIZE? Is this a bug in Windows?
This happens on a HP Stream 7 with Windows 8.1. I'm not sure if Explorer does this because it is touch enabled or because of the small screen.
Is this Explorer behavior documented anywhere and is there a way to turn it off? What is the best way to stop Explorer (or any other parent process) from affecting my initial window mode? (I don't want to block people starting me with SW_*MINIMIZE*)
WinVer.exe in system32 has the same problem:
My first thought was to turn off STARTF_USESHOWWINDOW in the PEB if the parent wanted me to start maximized but that is too nasty and undocumented so I have not tried that yet.
Preventing any kind of size change (which is OK for my application since it is just a "modal" dialog) sort of works:
case WM_WINDOWPOSCHANGING:
((WINDOWPOS*)lp)->flags |= SWP_NOSIZE;
return true;
The problem is that the window position is still set to 0 x 0 like a maximized window.
A better solution seems to be to detect and correct the problem after WM_INITDIALOG:
case WM_INITDIALOG:
PostMessage(hDlg, WM_APP, 0, 0);
break;
case WM_APP:
if (IsZoomed(hDlg)) ShowWindow(hDlg, SW_SHOWNOACTIVATE);
break;
I am the proud owner of several HP Stream 7 tablets and I would like to add my 2 cents here. Microsoft has made an arbitrary decision that devices with screen sizes smaller than 8 inches will behave differently than the norm. A lot of users are somewhat aware of this, but unaware that this is where your problem originates.
Windows determines a screen's size by reading the EDID information from the screen, which contains sizing information in it, in centimeters.
If no sizing information is present in the EDID, or the sizing information is below Microsoft's arbitrarily chosen 8 inch threshold, you get this apparent misbehavior which is at the very least, aggrivating to those who notice it and don't want it.
The solution is to override the default driver for the monitor in Device Manager with one that informs Windows that the screen is in fact, 8 inches or larger.
To do so, you need to first read the EDID information from the registry with a tool such as Deltacast's E-EDID Editor (free, last time I checked), and modify the size values and save the modified file someplace you can find it.
After you have modified your EDID file and saved it, download Monitor Asset Manager from EnTech (also free) and use it to create an INF file.
Once the INF file has been created, you need to restart Windows with the Advanced settings menu and choose to Disable Driver Signing Enforcement, since the INF file you created won't be digitally signed. Once disabled, open Device Manager in Windows and update the driver for the monitor using the INF file you created. You will need to confirm that you do in fact want to install the unsigned driver file.
Reboot and Windows will now behave normally with the one catch that, the onscreen keyboard will now appear a different size and will have more options available.
Sadly, Microsoft can change this behavior in the future, so there is no guarantee that through the same flawed decision making process they used to implement this in the first place, they won't force it down our throats again, using a much more difficult to counteract method.
I have a Windows 7 system, a regular monitor as the primary display (serving as a desktop, etc.), and an additional screen attached to the same graphics card.
I want to write a program that takes control of the secondary display and uses it for fullscreen OpenGL rendering. I tried to enumerate displays with EnumDisplaySettings, pick the secondary display, create a device context associated with the display, set the pixel format on the DC, and create a WGL context associated with it. I can get this far without errors, but then the call to wglMakeCurrent fails for no apparent reason (return value is 0, GetLastError() is 0, and OpenGL does not function.)
The only way I could get it to work is to extend the desktop onto the secondary display (manually, from Windows display settings), create a window and move it onto the secondary display. Which is tolerable but undesirable (I don't want the secondary display to interfere with the desktop. For example, in this setup, I can move the mouse cursor from the desktop into the secondary display.) Is there a way to avoid this?
More generally, in order to get OpenGL to work on a display, do I need (1) to have the display attached to the desktop (or "a" desktop?), and/or (2) to have a window of my own on that display?
P.S. It seems that I might be able to get this to work with a third-party library such as glfw3, but I don't want extra baggage (I don't need 90% of functionality of glfw3) and I'd prefer to get this done directly through native API calls if possible.
Unfortunately the Windows graphics driver model does not allow to use displays independently. You will have to extend the desktop to the second display and create a fullscreen window on it. When it comes to constraining the mouse, the usual way is to hook into the system mouse events and whenever the mouse pointer is moved into the secondary screen remove it back to the primary screen.