#7 Theme support for TGlyphButton

[Sebastian Ledesma]

When developing a themed application that uses TGlyphButton, there is a notable difference between Windows buttons and TGlyphButton that breaks the visual harmony of the user interface. TGlyphButton should be rendered using the active theme.

[Sebastian Ledesma]

Submitted to Vidar and Jogy.
Hope it gets approved :)

[Vidar Hasfjord]

Hi Sebastian, what is the status on this? As far as I can remember, you had working code close to complete. Do you plan to submit directly to the repository or post a new patch for review?

[Sebastian Ledesma]

I just have to sit and work on it to finish. :)
I was working on Linux and OSX, but I should not forget Windows.

[Vidar Hasfjord]

Hi Sebastian, I have now updated your preliminary patch and submitted it in [r1785].

Note that the issues I remarked upon in my review still remain:

• Theme detection must use both IsThemeActive and IsAppThemed. See TGadgetWindow and articles on the net for reference.
• Theme detection at initialization (InitVars) doesn't cope with activation and deactivation of themes during the lifetime of the button. A change to "Windows Classic" in the Control Panel causes the "glyphbtn1" demo to fail with an ObjectWindows Exception: "Unable to open theme." (Tested on Windows 7.) For this reason isThemed should not be a member variable (and not be static, as you suggest). It should be a function detecting themes dynamically. See TGadgetWindow and TButtonGadget for reference. Don't worry about the speed of detection.
• There is no need to SendMessage repeatedly in EvMouseMove if the button already is hot. Same goes for the other states (the existing code). This causes message flooding. Consider implementing a single-shot EvMouseEnter event where this is handled. (Such an implementation is easier in conjunction with WM_MOUSELEAVE. See below.)
• I am a little concerned about using IdleAction to implement WM_MOUSELEAVE manually. I vaguely recall some problems with getting IdleAction events in dialogs in some cases. As an alternative implementation, I recommend you look at the TrackMouseEvent function in the Windows API. It will cause Windows to generate WM_MOUSELEAVE messages for the button.
• The old implementation of TGlyphButton::PaintButton used a memory DC to provide flicker-free drawing. The new code does not. Flicker-free drawing should be reinstated.
• For readability, you should define an enumeration with symbolic values instead of using integers 0, 1, 2 for the argument to BM_SETSTATE.

Aside: OWLNext lacks response table macros for WM_MOUSELEAVE and the related events. You should consider adding these. Encapsulation functions for TrackMouseEvent in TWindow would also be nice:

:::C++
void TWindow::TrackMouseEvent(
  DWORD flags = TME_HOVER | TME_LEAVE, 
  DWORD hover_time = HOVER_DEFAULT);

void TWindow::CancelMouseEvent(
  DWORD flags = TME_HOVER | TME_LEAVE);

TRACKMOUSEEVENT TWindow::QueryMouseEventTracking() const;

[Vidar Hasfjord]

The theme detection issues mentioned in my review have now been fixed [r1918].

TGlyphButton will now cope with run-time theme changes and seamlessly switch the rendering style according to the compatibility settings for the application and the theme selection in the Control Panel (including Classic non-themed style).

[Vidar Hasfjord]

The issues regarding hot state tracking has now been addressed [r1923]. This change relies on new support for TrackMouseEvent and WM_MOUSELEAVE [r1922].

[Vidar Hasfjord]

The old implementation of TGlyphButton::PaintButton used a memory DC to provide flicker-free drawing. The new code does not. Flicker-free drawing should be reinstated.

Flicker-free painting has been reinstated in [r4539]. The fix was merged into Owlet in [r4540] and into 6.44 in [r4541].