Using local adb shell, I was able to modify battery_saver_constants.
it didn't do the need though
advertise_is_enabled=true,datasaver_disabled=false,enable_night_mode=true,launch_boost_disabled=true,vibration_disabled=true,animation_disabled=true,soundtrigger_disabled=true,fullbackup_deferred=true,keyvaluebackup_deferred=true,firewall_disabled=true,gps_mode=2,adjust_brightness_disabled=false,adjust_brightness_factor=0.5,
force_all_apps_standby=false,force_background_check=false,
optional_sensors_disabled=true,aod_disabled=true,quick_doze_enabled=true
these are my modifications, Is there any way to stop switching accessibility settings off?
Related
How can I detect Restricted, Synchronizing, and Synchronized mode on a database? Are there other modes?
Yes, I know that is is visible in SSMS. I need a script to detect it.
I'm using a thrid-party screen capturing application (Screenpresso). It's configured to start screen-capturing when I press PrtSc. And indeed it works except when Intellij has Windows focus. In fact, to screen capture code I have to focus on any other window press PrtSc and then select the area within Intellij.
I've looked through all the settings, and especially the Keymap settings, and I can't see anything else that has been assigned to PrtSc. Of course, I'm not really sure; when I try to find a setting via nothing happens, as pressing PrtSc has no effect.
I know this used to work for me in previous versions of Intellij (though I can't remember what versions). But PrtSc used to work in Intellij just like every other application.
So I guess the question is, why is Intellij eating the PrtSc keypress event? And can I turn it off so that the event gets correctly passed to my dedicated screen capturing application.
Intellij 2019.2.4
Windows 10, 64b
This turned out to be an issue with Screenpresso:
https://www.screenpresso.com/support/hot-keys/
Why shortcut [print screen] key does not always work?
This must be because you run your application with elevated
privileges (with admin rights) (the UAC must have displayed a popup
at startup).
For security reasons, Screenpresso can handle shortcuts
from Windows running with elevated privileges only when it is
installed in Program Files folder.
To fix this, you should install
Screenpresso in Program Files folder which is not the default
behavior:
Uninstall Screenpresso
Run again Screenpresso: Right click Screenpresso.exe and select Run as administrator
Click on the INSTALL on this computer button while holding the Control key or click on the sub-menu Install for all users:
Some users have this problem, first reported 5 years ago: Find here
Crash dumps (java_error_in_*.log in the user's home directory) can help to understand it better.
I'm using VS2017 and have made a very simple 'launcher' for various RDP settings files using a Windows Forms application. This just calls Process.Start with a direct link to a .rdp file, or alternatively just straight to mstsc.exe
The application (and RDP sessions) displays and works correctly on standard PCs. However I have run into a problem on high DPI devices such as Surface Books/pros.
The RDP client not scaling correctly is a fairly well known issue, and we have fixed this problem using the manifest/reg change method. This is confirmed working. Double clicking a .rdp config file works correctly too.
( https://www.blackforce.co.uk/2016/04/18/remote-desktop-rdp-resolution-on-a-surface-book )
My own application also displays correctly at the correct scale. However, when I launch RDP using Process.Start, RDP client is scaled badly, as it always was before the manifest fix. I've tried opening the client alone, and with a .rdp file and result is the same. I open the same .rdp file manually, not via my app, and the client is scaled correctly.
Can anyone replicate this, or advise why the mstsc manifest file is ignored when started this way? I've also tried the using ProcessStartInfo to set UseShellExecute but still the same result.
Windows desktop apps, such as RDP, can specify a DPI-scaling mode ("DPI awareness mode") either through a manifest setting or via API calls during initialization. Applications will behave differently whenever the scale factor of the display that they're on changes. You can read more about this here.
I'd speculate (I haven't tried this to confirm this speculation) that the RDP process is using a manifest to declare it's DPI awareness (as Per Monitor DPI aware) and that when you're launching a process through Process.Start that the specified DPI awareness of the app is getting changed... possibly to the DPI awareness of the calling process?
I'd use System Internals Process Explorer to determine the DPI awareness of the RDP app when it runs as expected, and then compare that to the DPI awareness of the RDP app when it's launched from your app. If that is the case, look it to whether you can specify the DPI awareness of the process that you want to start in Process.Start. Another thing that you can try is to set the DPI awareness of your WinForms app to the same DPI awareness of the RDP app (per-Monitor) to see if that helps.
Also, I'm assuming that you're running on an OS > 8.1 as Per-Monitor support was introduced in 8.1.
Here is the situation. The company I work for builds this piece of software in c that can make a Windows computer act a bit like a TV. Essentially, our piece of software is meant to be played full screen and content is displayed from the internet without the user having to ever touch the computer again.
The problem is that once in a while, the system brings up pop-ups like "Your Windows system is ready for an upgrade." or "Please renew your Norton subscription" etc. which the user has to periodically and manually remove.
Is there a way to display content full screen without being bothered by those warnings?
Yah, whether or not the development community agrees, Microsoft has several standards for when and why it might be acceptable to have exclusive use of the monitor.
The most official strategy is to use DirectX in exclusive mode. This is what games do, what windows media player does in full screen video with hardware acceleration enabled, etc... If your application is multimedia intensive (as suggested by TV like functionality), you should probably be using DirectX too. Besides giving you the exclusive display access it will also increase your applications performance while lowering the CPU load (as it will overload graphics work to the video card when possible).
If DirectX is not an option, there are a great number of hacks available that seem to all behave differently between various generations of windows operating systems. So you might have to be prepared to implement several techniques to cover each OS you plan to support.
One technique is to set your application as the currently running screensaver. A screensaver if really just an EXE renamed to SCR with certain command line switches it should support. But you can write your own application to be such a screensaver and a little launcher stub that sets it as the screensaver and launches it. Upon exit the application should return the original screensaver settings (perhaps the launcher waits for the process to exit so that it returns the settings in both graceful exits and any unplanned process terminations ie: app crash). I'm not sure if this behavior is consistent across platforms though, you'll have to test it.
Preventing other applications from creating window handles is truly a hack in my opinion and pretty bad one that I wouldn't appreciate as a customer of such software.
A constant BringWindowToTop() call to keep you in front is better (it doesn't break other software) but still a little hack-ish.
Catch window creation messages with a global hook. This way you can close or hide unwanted windows before they become visible.
EDIT: If you definitely want to avoid hooks, then you can call a function periodically, which puts your window to the top of the z-stack.
You could disable system updates http://support.microsoft.com/kb/901037 and remove the norton malware.
You could also connect a second screen so that the bubbles appear in the the first monitor.
Or you rewrite it for linux or windows ce.
One final option is to install software that reconfigures your os into a kiosk http://shop.inteset.com/Products/9-securelockdown.aspx
If you don't need keyboard or mouse input, how about running your application as a screensaver?
A lot of thoses messages are trigged/managed by Windows Explorer.
Just replace it with your dummy c#/winform.
By changing the registry value
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]
"Shell"="Explorer.exe"
You can specify virtually any exe as an alternative to explorer.exe
That's the way all windows based (embedded) system (ATM & co) do.
There's still few adjustment (disable services you dont need / dr watson & others), and of course, you'll want to keep a "restart explorer.exe" backdoor.
But that's a good start
I'm not sure if this is technically a Kiosk, but it's basically the same idea. I have a program that runs full screen all the time from boot to shutdown to control a machine that the computer is hooked to.
Right now I just have a shortcut to the exe in the Startup folder so it starts when the system boots up and logs in. Is there any better way to do this? I'd really like the user to never see the Windows environment (just the windows loading progress bar on boot) if at all possible, but I'm guessing that's not possible.
Just thought I'd ask and see if there is a better way to do this than putting it in the startup folder?
The best option is to use Windows Embedded. This gives you much more control over the shell, and what is run and installed with the system.
If you have to do this with a consumer OS, you can try to bypass the login prompts to auto-login your user, and have your program setup in the registry to startup. Disable any other services you don't need. That will minimize the time the shell is displayed (but it's very difficult to remove it).