Hi Alexey,
With this change, property "win.xpstyle.themeActive" change is fired on the
toolkit thread
Is it possible to install a change listener for this property from user
code, and hence eventually allow executing some user code on the toolkit
thread with your fix?
--
best regards,
Anthony
On 4/18/2014 12:09 PM, Alexey Ivanov wrote:
Hello Swing and AWT teams,
Could you please review the fix for jdk9:
bug: https://bugs.openjdk.java.net/browse/JDK-8039383
webrev: http://cr.openjdk.java.net/~dmarkov/8039383/jdk9/webrev.00/
Problem description:
When changing Windows themes from a theme with visual styles (Windows
Aero or Windows Basic) to a classic one, NullPointerException could be
thrown from Swing code during component tree validation, or
InternalError could be thrown during component painting.
Root cause:
Windows theme data are "cached" in XPStyle object. When the theme is
switched to a classic one, HTHEME handle becomes unavailable and data
cannot be accessed from the theme any more. The change in theme in
posted to EDT via invokeLater. At the same time, the UI needs to repaint
itself as soon as Windows changed the theme, and paint code is often
called before the theme change is handled in Java. This leads to NPE and
InternalError as the code tries to access the data that has become
unavailable.
The fix:
Update "win.xpstyle.themeActive" desktop property and invalidate the
cached XPStyle as soon as windowsSettingChange() is called from native
code. Thus when Swing code needs to access theme data, it will see no
theme is available and will fallback to classic painting.
Note: Before the fix, PropertyChangeEvents for desktop properties in
Windows were fired on the Event Dispatch Thread. With this change,
property "win.xpstyle.themeActive" change is fired on the toolkit
thread; all other properties are changed on the EDT as before.
Regards,
Alexey.
