Community
Participate
Working Groups
This is a strange one. When developing our RCP app with Eclipse 4.13 on Windows 10 and setting the OS dark mode on (Windows Settings, Colours, "Dark" for app mode) Display#isSystemDarkTheme() returns true and works correctly. However, once the same RCP app has been exported as a standalone app and run Display#isSystemDarkTheme() returns false whatever the setting. I've checked the registry setting of HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Themes\Personalize\SystemUsesLightTheme and it is set to "0" Not sure how I can create a test case with this one as the app has to be standalone for this to happen.
I ran into exactly the same problem. When running the RCP app from Eclipse 4.16 on Windows 10, Display.isSystemDarkTheme() returns the state reflected by the registry key HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Themes\Personalize\AppUseLightTheme, but when running as a standalone app it returns false no matter what the registry key is set to. Inspection of the source code for Display.isSystemDarkTheme() reveals that the value of the registry key is only read when the Windows version is at least 10. This is accomplished by comparing the member OS.WIN32_VERSION which is populated by the static constructor of class OS using the Windows API function GetVersion(). The documentation of that function (https://docs.microsoft.com/en-us/windows/win32/api/sysinfoapi/nf-sysinfoapi-getversion) explains that the behavior of that function changed in Windows 8.1. If an application is not manifested for Windows 8.1 or Windows 10, it will simply return the Windows 8 version value (6.2), even when actually running from Windows 10. When checking the value of OS.WIN32_VERSION, it can be seen that for the standalone RCP app, 6.2 (Windows 8) is reported whereas the correct Windows version is reported when running from within Eclipse. So, this explains the behavior of Display.isSystemDarkTheme(). In the latter situation, Eclipse launches the RCP app through a new javaw.exe process. Since this Java executable is correctly manifested, also for Windows 10, GetVersion() returns the correct version. However, when examining the manifest of the standalone RCP app (or even eclipse.exe, which are the same), the required XML tags (compatibility, application, supportedOS) for targeting the application for specific Windows versions turn out to be missing. This is ultimately the reason of the different behavior of GetVersion(). An example for targeting apps for Windows versions is given here: https://docs.microsoft.com/en-us/windows/win32/sysinfo/targeting-your-application-at-windows-8-1 I fixed the issue on my RCP app by adding the missing tags to the existing manifest after the product was exported. This can be done by a resource compiler and another tool for modifying resources in exe files (e.g. GoRC and ResourceHacker). I can give further details on this process if needed. Due to the problem, any code relying on a check of the value of OS.WIN32_VERSION should be considered unsafe for the time being as it might not return the actual Windows version (or, to be more precise, the Windows version which was selected as a compatibility setting when running an app). In my opinion, updated manifests including the relevant tags need to be provided already out of the box which I believe is rather part of the launcher. After all, eclipse.exe contains the same manifest as an exported RCP app and thus suffers from the same problem.
(In reply to Christian Herrmann from comment #1) > In my opinion, updated manifests including the relevant tags need to be > provided already out of the box which I believe is rather part of the > launcher. After all, eclipse.exe contains the same manifest as an exported > RCP app and thus suffers from the same problem. IMO, with fix for "Bug 570406 - Declare Windows 10 compatibility in the manifest" problem should be resolved. *** This bug has been marked as a duplicate of bug 570406 ***
