Our application includes a screen capture capability. Some applications use overlay surfaces to display video so we included an option to disable hardware acceleration in order to force those applications into software rendering mode so that we can screen cap them. This worked fine under Windows XP.
However, under Windows 7 it appears, from my research, that very few display drivers support the ability to disable hardware acceleration since the DWM uses DirectX9 rendering. On those sysetms the Display Settings->Advanced Settings->Troubleshoot->Change Settings... button is disabled. But I have heard reports that on some systems that button is enabled.
So, my question is what API (or heuristic) is the windows control panel using to enable/disable the "Change settings..." button so that I can enable/disable a similar control in our application?
Related
My C++ game allows users to hold down the shift key for a speed boost, but after 8 seconds this causes an annoying dialog to pop up on a fresh Windows 10 machine ("Do you want to turn on Filter Keys?"). Is there a way to disable this programmatically while my game is running?
I suggest you could refer to the Doc:Disabling Shortcut Keys in Games
To avoid these issues, you should disable these keys when running in full-screen mode, and either enable the keys back to their default handlers when running in windowed mode or exit the application.
To turn off these shortcuts:
1,Capture the current accessibility settings before disabling them.
2,Disable the accessibility shortcut when the application goes into full-screen mode if the accessibility feature is off.
3,Restore the accessibility settings when the application goes into windowed mode or exits.
You could try to use SystemParametersInfo to Get and Set System Information.
Context: our desktop application is used predominantly by users with significant access issues and therefore some of them use the Windows on screen keyboard. One bit of feedback we've had is that the software is awkward to use with the OSK as too many important bits of the UI get covered up. If we could detect the presence of the keyboard we could adapt the UI to some extent.
Therefore is it possible in code to detect that the Windows in-built OSK is open? And is it possible in code to detect the location of the keyboard?
The application is in WinForms and usually runs on full desktops/laptops - not smaller touchscreen machines.
I need to do a pre-purchase evaluation of a Flash application that is intended for a touch screen.
Since I still don't have the touchscreen now, I need to run the application on my desktop computer and the application is unusable without a visible cursor.
I am using Windows.
Is there a way to unhide the cursor without asking the developers to change the application?
I've previously used remote access software (such as Windows Remote Desktop or TeamViewer) for this purpose. Another option is a virtual machine - in both cases you'll be able to see the cursor on the local/host machine.
If you happen to be on a Windows 8 machine, you might give a try to the Windows Simulator (http://blogs.msdn.com/b/visualstudio/archive/2011/09/29/first-look-at-windows-simulator.aspx, available for free with Visual Studio Express) that additionally simulates multitouch gestures such as pinch/rotate with only a mouse.
A few other ideas:
1) You can try using the "Show location of pointer when I press the CTRL key" mouse visibility property (Control Panel - Hardware and Sound - Devices and Printers - Mouse - Pointer options). Although not entirely convenient, it might help you if the application doesn't require quick response times.
2) If the application is distributed as a .swf file and the right button hasn't been disabled, sometimes right-clicking (anywhere in the application) to bring up the context menu will cause the cursor to show up and remain visible.
In my OpenGL application I switch between windowed and fullscreen mode using
Raymond Chen's solution:
http://blogs.msdn.com/b/oldnewthing/archive/2010/04/12/9994016.aspx
This works apart from two very annoying side effects when used in a
multi-monitor setup (only):
After the window mode was switched BOTH screens flicker/flash just in the
moment glViewport is called to accommodate the changed window dimensions.
Windows on the desktop from other applications are not painted correctly
after the switch until I e.g. minimize/maximize them (or do something similar
to force a refresh).
Does one know these effects and maybe also knows a solution?
ps: further tests showed that this only happens on my PC with an AMD card but not with my Nvidia card. If only one monitor is active it doesn't happen at all.
We noticed that on W7 with DPI set to > 125% or to > 100% with ("Use windows xp style dpi scaling") turned off, our fullscreen mode (which sets the client rect of our window = desktop rect of the main monitor) no longer hides the task bar like it does for other settings.
(The setting can be found in the Control Panel\Appearance and Personalization\Display section after clicking on the "Set custom text size (DPI)" link)
I found the following interesting article:
http://www.mathies.com/weblog/?p=908
So I set out to try to work around the bug in other means than manually hiding/restoring the taskbar visibility but so far I've failed and currently believe it's a bug in W7 (and possibly vista).
The following applications also fail to work properly in fullscreen mode (the taskbar is still visible):
* Microsoft Visual Studio 2008
* Microsoft Word 2007
* Adobe Reader 9.1.3
These apps work (probably by hiding the task bar through the WIN32 API):
* Powerpoint Slide Show
I also tried creating a brand new MFC-based app and use its "SetFullScreenMode()" functionality but it fails in the same way as all other apps on the list.
For now it seems the only temporary fix which has worked for me is to disable display scaling on high DPI settings for the program your using fullscreen with.
To do this goto properties (right-click the program's shortcut) >> compatability >> and check the option to disable display scaling on high DPI settings.
The only drawback is that you will not get the higher DPI for that program but the taskbar should hide when fullscreen is enabled.
This is a problem that I understand Windows 7 developers are aware of but have not come out with a solution.