łukasz milewski home

In my previous post about Vista glass I’ve introduced very simple way to enable DWM glass in SWT. Since that time, I did a lot of experiments how one can improve that experience, and I’ve found solutions to almost all issues with DWM/Glass/Vista in SWT. This post became much bigger than I’ve anticipated, therefore it’s divided into “text after more…” :-)

First, let’s see some screenshot of application in work:

Above you see an application running on Windows Vista with DWM and Glass enabled. That part was covered in previous post, but since then I was able to place native widgets on glass without alpha blending of black (and gray) regions. Trick is rather complicated, explaining without an example code would be problematic, so let us see how this widget looks like (beware, it’s work in progress code, and I’m not yet very proficient in writing native widgets in SWT, some errors/memory leaks could be there).

Bottom line is, we need to overwrite native widget WM_PAINT message and introduce buffered painting with alpha capabilities. Method callWindowProc() is a bit trimmed down from original Text.callWindowProc() but additional functionalities were not needed for purpose of this example. Another change that had to be made specifically to Text widget was its handling of EN_CHANGE message, without invalidating and updating content of native widget, entire widget was falling back to not buffered paint until new WM_PAINT message was dispatched. Following this pattern, we’re able to place any native widget on glass without loosing its correct painting (as was hinted by Steve in 3rd comment).

Having this done, example application started to look how it should be in glass - the Search text field was now correctly painted and I was able to continue my work on handling scenario when DWM is disabled, but default Vista theme is enabled. You may notice that Explorer (even Internet Explorer > 7) is falling back very nicely to extended chrome (here I will call it header pane):

Very nice indeed, folks that don’t have DWM and glass enabled still have same user interface, just a little bit differently painted. So how we can achieve similar effect in SWT. Well, it’s also very complicated, and showing once again code example would be easier. This time it’ll be two classes that we need to write.

First class is GlassAwareShell that we need to use instead of original Shell class:

New shell provides new method to store header inside shell object, it’s useful in requesting for invalidation and update of its native widget. What’s important is WM_ACTIVATE message handling method. Essentially in default theme, colors change when window is focused or blurred, we need to handle this scenario also. Here I’ve faced a big roadblock. After sending InvalidateRect message to header native widget I had big delays between painting chrome (windows border) and header pane, so noticeable that it was unacceptable. After days of studying MSDN I found that one can request WM_PAINT without going to dispatcher queue using UpdateWindow method on header. That was a big relief, because header started to paint itself immediately after border (still there’s sometimes noticeable, few milliseconds of delay, but I found this delay in Internet Explorer also). Last thing that was added to this shell is listener DWM_CHANGE that is posted when WM_DWMCOMPOSITIONCHANGED message is received by shell. This message is not declared in OS, therefore I’ve added it at the top of the GlassAwareShell class. Message is sent by operating system, when there’s a change of DWM state (disabled/enabled).

Now we need to implement this header pane for ourselves. It’s not provided. Here’s the example code:

This GlassAwareComposite is actually useful for DWM enabled and disabled. In each case different paint method will be used, for DWM enabled we draw black background, for DWM disabled we are doing something more interesting. Header pane is painted by UxTheme method DrawThemeBackground. Biggest problem with that was to get correct theme data and image index. Unfortunately in SWT theme data for “WINDOW” object is not available, therefore we need to open it for ourselves. Theme data also needs to be released, which we’re doing in dispose() method. For purpose of painting header pain, we can use same image that is painted on top left side under chrome title bar, but we need to shift it few pixels, because of left border. This is where our WM_ACTIVATE message is extensively used. GlassAwareShell when receive WM_ACTIVATE, sets active state on header pane, then invalidate and update header pane, GlassAwareComposite receive WM_PAINT message and paint it’s content.

After applying all those magic stuff, our application can looks following, activate:

and inactive:

Thanks to DWM_CHANGE listener introduced in GlassAwareShell application can handle DWM change, accordingly to its desires - I found that if we want to have the same user interface alignment in both DWM enabled and disabled we need to change margins in our layout. I’ve also noticed that Glass information (created with DwmExtendFrameIntoClientArea() method) is lost after DWM change, so it’s suggested to call this method once again in DWM_CHANGE listener.

Notice! Due to heavy use of overriding methods with default visibility in Shell, Text and Composite new widgets needs to stay inside org.eclipse.swt.widgets package. This is annoying limitation that could be easily resolved by marking methods protected.

I hope that too much of code wasn’t discouraging and examples were proficient enough to discover that SWT applications under Vista can look the same as those written in C++.

PS. You can observe that I’m also experimenting with explorer toolbar, but unfortunately I wasn’t able to find any windows api to draw it, so I just placed background image on Composite ;-)