Develop Reference

Detect dark windows taskbar

For theming purposes, I'm looking to detect the color of the Windows taskbar (in my case, for a tray icon).
I'm using Java, but any solutions are welcome as I'd happily convert them over as needed.
My first attempt was to read the registry.
This worked great for desktops that provided this value, but falls
short when the registry
does not provide it.
My second attempt was to take a screenshot of the taskbar and try to guess if it's dark or light themed.
This even works when autohide is on. Unfortunately it returns a black background regardless of what I do:
WinDef.HWND tray = User32.INSTANCE.FindWindow("Shell_TrayWnd", null);
BufferedImage bi = GDI32Util.getScreenshot(tray);
SwingUtilities.invokeLater(() -> JOptionPane.showMessageDialog(null, new JLabel((new ImageIcon(bi)))));
Assuming I don't want to rely on the white/black color of the Windows logo, is there a way to detect this?
Related:
How can I detect Windows 10 light/dark mode?
How do I get the mode (Light/Dark) of the PC in C#?
How can I get whether Windows 10 Anniversary Update or later is using its light or dark theme in a WPF app?
Similar (10 year old) question on MSDN

So far, I have not encountered the lack of SystemUsesLightTheme and AppsUseLightTheme in the registry.
But I think recreating the key-values is worth trying.
Here is code sample(C++):
#include <iostream>
#include <string>
#include <sstream>
#include <fstream>
#include <Windows.h>
using namespace std;
int main() {
HKEY key;
if (RegOpenKey(HKEY_CURRENT_USER, TEXT("Software\\Microsoft\\Windows\\CurrentVersion\\Themes\\Personalize"), &key) != ERROR_SUCCESS)
{
cout << "unable to open registry";
}
DWORD value_data = 0;
if (RegSetValueEx(key, TEXT("SystemUsesLightTheme"), 0, REG_DWORD, (const BYTE*)&value_data, sizeof(value_data)) != ERROR_SUCCESS)
{
RegCloseKey(key);
cout << "Unable to set registry value value_name";
}
else
{
cout << "value_name was set" << endl;
}
}

When the documented registry entries are missing, it appears something in the OS is coded to fallback the following settings:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Themes\Personalize\
If AppsUseLightTheme is missing, assume it's 1
... and then make the dark/light Windowing decisions based on this value.
If SystemUsesLightTheme is missing, assume it's 0
... and then make the dark/light Taskbar/SystemTray decisions based on the this value.
The glory details...
Although fresh Windows Home installs defaults to the Light theme, these fresh installers also set the registry keys properly, so the combination of a missing registry key and a light taskbar is extremely unlikely (and probably impossible). To a similar point, studying modern OSs may -- improperly -- suggest the defaults come from the file C:\Windows\resources\Themes\aero.theme**, but don't be fooled! Older OSs didn't have a differentiating entry either... More below.
Instinct would suggest that the CurrentTheme or perhaps the InstallTheme registry values would serve as a sane fallback value, but changing these values appear to be for historical purposes and do not appear to actually change the light/dark theme.
reg query HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Themes /v InstallTheme
>>> returns the path to aero.theme
type %SystemRoot%\resources\Themes\aero.theme |find "SystemMode"
>>> returns SystemMode=dark
Even changing the InstallTheme for the entire machine (HKEY_LOCAL_MACHINE) doesn't modify this behavior of preferring SystemMode=dark (note, even this entry wasn't available in older Windows 10 versions. For example, Windows 10 v1507 doesn't have this entry in the theme file either).
Chasing the aero.theme hit some dead ends too. Attempts to directly modify aero.theme failed due to permissions, but copying aero.theme to the Desktop and changing SystemMode=dark to SystemMode=light and then double-clicking the theme file will make the taskbar go white, but only on newer Windows versions that supported the light theme.
So, yes, I have to agree with #strive-sun-msft the SystemUsesLightTheme registry entry is the best location. When testing, even the Task Bar itself monitors this, deleting it will reset it back to black. Unfortunately that fallback black Task Bar color remains to be a mystery. I can only assume it's hard-coded into the task bar itself.
Another workaround for this behavior is to just install the aero.theme file again by running it if the registry entries are missing. On newer Windows 10 versions, simply running this file will create the missing entries. Unfortunately, this doesn't work on older Windows 10 versions and worse, this will reset any custom preferences set by the user.
So the least intrusive way to detect the color of the taskbar is to read the registry and if the keys are missing, simply assume the theme Windows 10 shipped with is still in effect: Dark Taskbar, Light Windows.

You can use the Windows Registry Value SystemUsesLightTheme that is available at this Registry Path: Software\Microsoft\Windows\CurrentVersion\Themes\Personalize
for detecting the dark/light theme.
I found a library called JRegistry that allows you to access
this value.
RegistryKey windowsPersonalizeKey = new RegistryKey("Software\\Microsoft\\Windows\\CurrentVersion\\Themes\\Personalize");
RegistryValue systemUsesLightThemeValue = windowsPersonalizeKey.getValue("SystemUsesLightTheme");
if (systemUsesLightThemeValue != null) {
//this value is available
//getting the actual value
byte[] data = systemUsesLightThemeValue.getByteData();
byte actualValue = data[0];
boolean windows10Dark = actualValue == 0;
if (windows10Dark) {
//the theme is dark
} else {
// the theme is light
}
}
Also, if you want to listen to this value dynamically:
RegistryKey registryKey = new RegistryKey("Software\\Microsoft\\Windows\\CurrentVersion\\Themes\\Personalize");
RegistryWatcher.addRegistryListener((RegistryEvent registryEvent) -> {
RegistryKey changedKey = registryEvent.getKey();
if (changedKey.equals(registryKey)) {
RegistryValue value = changedKey.getValue("SystemUsesLightTheme");
//....
}
});
RegistryWatcher.watchKey(registryKey);

Why isOperational() in mobile vision text Recognizer in a device return true and in other return false?

Why isOperational() in mobile vision text recognizer returns false?
At first, mobile vision only show preview camera and after many tries to get the result, I saw that the texts recognized but in one device it works and in other device does not.
What should I do?
For example, in one device, isOperational() returns false, and it goes to readstate() and after that goes to looper() and stays on it!
in other device it only return false and doesn't go to looper.
I want ask other questions about it:
My first question is: how does isOperational() work? I can't understand it.
Maybe it goes to looper to download the native library in a queue and after many try, at last download completes and work. Can it be correct? Or is it just a bug that it goes to looper? Anywhere, what should I do?
Can I work on this when it works in one device I tried and in other does not? Or it must work in every device to I can work on it? And I get .apk from project but it can't install in devices, why?
Should it check for network?
Should it check for access to the memory?
note: it works with camera API and its deprecated. maybe the problem is with this!
TextRecognizer textRecognizer = new TextRecognizer.Builder(context).build();
textRecognizer.setProcessor(new OcrDetectorProcessor(graphicOverlay));
if (!textRecognizer.**isOperational**()) {
// Note: The first time that an app using a Vision API is installed on a
// device, GMS will download a native libraries to the device in order to do detection.
// Usually this completes before the app is run for the first time. But if that
// download has not yet completed, then the above call will not detect any text,
// barcodes, or faces.
//
// isOperational() can be used to check if the required native libraries are currently
// available. The detectors will automatically become operational once the library
// downloads complete on device.
Log.w(TAG, "Detector dependencies are not yet available.");
// Check for low storage. If there is low storage, the native library will not be
// downloaded, so detection will not become operational.*
IntentFilter lowstorageFilter = new IntentFilter(Intent.ACTION_DEVICE_STORAGE_LOW);
boolean hasLowStorage = registerReceiver(null, lowstorageFilter) != null;
if (hasLowStorage) {
Toast.makeText(this, R.string.low_storage_error, Toast.LENGTH_LONG).show();
Log.w(TAG, getString(R.string.low_storage_error));
}
}
*// Creates and starts the camera. Note that this uses a higher resolution in comparison
// to other detection examples to enable the text recognizer to detect small pieces of text.*
cameraSource =
new CameraSource.Builder(getApplicationContext(), textRecognizer)
.setFacing(CameraSource.CAMERA_FACING_BACK)
.setRequestedPreviewSize(1280, 1024)
.setRequestedFps(2.0f)
.setFlashMode(useFlash ? Camera.Parameters.FLASH_MODE_TORCH : null)
.setFocusMode(autoFocus ? Camera.Parameters.FOCUS_MODE_CONTINUOUS_VIDEO : null)
.build();
}
It doesn't produce any error and show preview camera but doesn't recognize texts in some devices.

Is there any way to set auto focus with ARCore camera?

I am working on an application where I need to put object using ARCore. And then I need to save the frames as an image.
So is there any way to set auto focus for ARCore camera?

As of ARCore 1.4, you can enable or disable autofocus through your ARCore Session's Config:
Session session = new Session(context);
Config config = new Config(session);
if (enableAutoFocus) {
config.setFocusMode(Config.FocusMode.AUTO);
} else {
config.setFocusMode(Config.FocusMode.FIXED);
}
session.configure(config);
https://developers.google.com/ar/reference/java/com/google/ar/core/Config.html#setFocusMode(com.google.ar.core.Config.FocusMode)

Here's what Google ARCore engineers say about Config.FocusMode:
public static final enum Config.FocusMode
Config.FocusMode enum selects the desired behaviour of the camera focus subsystem. Currently, the default focus mode is FIXED, but this default might change in the future. Note, on devices where ARCore does not support Auto Focus due to the use of a fixed focus camera, setting AUTO will be ignored. See the ARCore Supported Devices page for a list of affected devices.
For optimal AR tracking performance, use the focus mode provided by the default session config. While capturing pictures or video, use AUTO. For optimal AR tracking, revert to the default focus mode once auto focus behavior is no longer needed. If your app requires fixed focus camera, call setFocusMode(Config.FocusMode)(FIXED) before enabling the AR session. This will ensure that your app always uses fixed focus, even if the default camera config focus mode changes in a future release.
There are two values:
public static final Config.FocusMode AUTO
public static final Config.FocusMode FIXED
So, in Java code:
Config ar_session_config = session.getConfig();
ar_session_config.setFocusMode(Config.FocusMode.AUTO);
session.configure(ar_session_config);
Hope this helps.

Old question, but I thought I'd update the answer with implementation in Sceneform. Sceneform SDK 1.4 added the ability to setup autofocus. I use an extension function to enable it.
Declare the relevant fields globally.
//The AR Core session
private var arSession: Session? = null
private var arConfig: Config? = null
and the extension function definition :
private fun Session.setupAutofocus() {
//Create the config
arConfig = Config(this)
//Check if the configuration is set to fixed
if (arConfig?.focusMode == Config.FocusMode.FIXED)
arConfig?.focusMode = Config.FocusMode.AUTO
//Sceneform requires that the ARCore session is configured to the UpdateMode LATEST_CAMERA_IMAGE.
//This is probably not required for just auto focus. I was updating the camera configuration as well
arConfig?.updateMode = Config.UpdateMode.LATEST_CAMERA_IMAGE
//Reconfigure the session
configure(arConfig)
//Setup the session with ARSceneView
fragment.arSceneView.setupSession(this)
//log out if the camera is in auto focus mode
ARApplication.log("The camera is current in focus mode : ${config.focusMode.name}")
}
and a good place to call this is your activity's onResume
override fun onResume() {
super.onResume()
//Check if ARSession is null. If it is, instantiate it
if(arSession == null) {
arSession = Session(this#EdgeActivity)
arSession?.setupAutofocus()
}
}

If the problem is in a Unity project, then change the CameraFocusMode parameter to Auto instead of Fixed.

java 1.8+ Full-Screen Exclusive Mode setFullScreenWindow(Frame) strange behavior

I'm working on a fullscreen application and discovered some really weird behavior using setFullScreenWindow(Frame) to actually get the application frame to fullscreen exclusive mode on some notebooks. While my code works on most WinOS systems on some it just doesn't. The resolution change works but the application stays in the top left corner of the screen in its former resolution like the setFullScreenWindow(Frame) call did not actually work. No exception thrown. If I connect a second display to the system and make it primary display it suddenly works. If I disconnect the second display and run the app on the previous used native display it also now suddenly works. If I reboot the system the native display again fails to bring the app to fullscreen. Both isFullScreenSupported() and isDisplayChangeSupported() are true in any cases.
Strange. Notebook is a MacBookPro with a Bootcamp WinOS10 installation but problem is not limited to this hardware or WinOsVersion.
client.windowScale = 2;
client.setVisible(false);
client.setResizable(false);
client.setUndecorated(true);
client.setSize(RES_WIDTH * client.windowScale, RES_HEIGHT * client.windowScale);
DisplayMode newDisplayMode;
GraphicsDevice gd = GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice();
DisplayMode_Old = gd.getDisplayMode();
if (gd.isFullScreenSupported() & gd.isDisplayChangeSupported()) {
gd.setFullScreenWindow(client);
gd.setDisplayMode(
new DisplayMode(
RES_WIDTH * client.windowScale,
RES_HEIGHT * client.windowScale,
DisplayMode_Old.getBitDepth(),
DisplayMode_Old.getRefreshRate()));
}
else {
System.out.println("Fullscreen failed.");
}
}
Actual Image:

How can I prevent the Charm bar from showing up in my Java application?

I've got a Java swing program that runs in full screen mode. It's effectively a kiosk program in that I want it to lock out everything else while it's running. This is running on a Windows 8.1 tablet, so of course the tablet is touchscreen, and therefore if you do an "edge swipe" (drag your finger from the right) the charms bar pops up and you can get to the Start screen from there. Is there some way to disable this from happening in Java? (Or is there some third-party solution not involving Java that can work in tandem to achieve the same result?)

You can disable edge gestures while your app is active and full screen by setting the System.EdgeGesture.DisableTouchWhenFullScreen property on the window.
I don't know if Java provides a direct way to set this (probably not), but you should be able to set this from a JNI.
Here's a C++ snippet from the DisableTouchWhenFullScreen docs:
HRESULT SetTouchDisableProperty(HWND hwnd, BOOL fDisableTouch)
{
IPropertyStore* pPropStore;
HRESULT hrReturnValue = SHGetPropertyStoreForWindow(hwnd, IID_PPV_ARGS(&pPropStore));
if (SUCCEEDED(hrReturnValue))
{
PROPVARIANT var;
var.vt = VT_BOOL;
var.boolVal = fDisableTouch ? VARIANT_TRUE : VARIANT_FALSE;
hrReturnValue = pPropStore->SetValue(PKEY_EdgeGesture_DisableTouchWhenFullscreen, var);
pPropStore->Release();
}
return hrReturnValue;
}

What I ended up doing was to write a batch script that kills explorer.exe and then re-spawns it after the app exits, based on this answer on Super User.