Directory Opus and WindowBlinds: Visual style issues and fixes.

Table of Contents

Issue Summaries

Issues in or directly affecting Opus:

IDDescriptionActions for Opus?Actions for WindowBlinds?
D1Opus menu text color.Fixed in 10.0.3.1N/A
D2Opus menu gutters and glyphs.Fixed in 10.0.3.1, tweaked in 10.0.3.2Fixed in 7.30a
D3Opus menu drop-buttons not selected with some themes.Fixed in 10.0.3.1Minor/debatable theme issue
D4Opus resize grips opaque on glass status bar.Workaround in 10.0.3.1Minor/debatable theme issue
D5Opus glass status bar text colors forced to black.N/AFixed in 7.30a
D6Opus folder tabs with black fringing.Fixed in 10.0.3.1N/A
D7Opus custom controls missing frames.Workaround in 10.0.3.1Fixed in 7.30a
D8Opus toolbar lines too dark.Fixed in 10.0.3.1 (not perfect)N/A
D9Opus missing (most of) the horizontal gripper on some toolbars/dialogs.N/AFixed in 7.30a
D10Opus's entire color-chooser dialog flashes when its buttons are touched.N/AFixed in 7.30a
D11Opus transition animations broken by Sublime.N/ABug or theme issue
D12Opus "help" buttons partially off the right edge of their windows.Workaround in 10.0.3.1Bug
D13Opus "help" button backgrounds don't match menu-bar backgrounds.Fixed in 10.0.3.2Fixed in 7.30a
D14Opus (and Explorer) show no keyboard-focus rects.N/AFixed in 7.30a
D15Opus theming and file dialogs broken by WindowBlinds.N/AFixed in 7.30a
D16Opus (and other apps') menu bars not painted properly when resized.N/AFixed in 7.30a
D17Opus titlebar splits in half with Sublime on XP.N/AFixed (AFAIK)

WindowBlinds issues that do not affect Opus in particular

IDDescriptionActions for WindowBlinds?
W1WindowBlinds Sublime glitches with Aero Peek.Bug or theme issue
W2WindowBlinds Sublime line on scrollbar.Fixed in 7.30a
W3WindowBlinds "Win8" paints extra resize grip where it shouldn't be.Theme issue
W4WindowBlinds Sublime has a gap in the multi-line tab control.Fixed in 7.30a
W5WindowBlinds Sublime breaks resizing by window corners.Fixed in 7.30a
W6WindowBlinds makes DebugView look like a Win95 app.Bug?
W7WindowBlinds "Win8" menu misreports gutter width and has incorrect elements.Theme issue
W8WindowBlinds styles with incorrect disabled-bullet glyphs.Fixed in 7.30a
W9WindowBlinds Sublime (and more) makes "Empty Recycle Bin" look disabled when it isn't.Bug or theme issue
W10WindowBlinds styles cause various Win7 taskbar glitches.Fixed in 7.30a
W11WindowBlinds Sublime makes parts of Windows barely readable.Fixed in 7.30a (mostly)
W12WindowBlinds causes OS to report inconsistent/incorrect non-client metrics to apps.Bug

Issue Details

D1Opus menu text color.
Description:In Opus, selected menu text used the theme's "normal" color, not its "hot" color. (Colors are identical in most themes, but not all. e.g. Sublime.)
Directory Opus:
  • Fixed in 10.0.3.1.
WindowBlinds:
  • N/A. (Bug in Opus.)
Screenshots:
  
D2Opus menu gutters and glyphs.
Description: Some WindowBlinds themes had incorrect gutter elements, plus issues with menu-theme glyph colors.

WindowBlinds 7.30a fixed the gutters and I've worked around the glyph colors in Opus by drawing the glyphs without using the theme if the normal and hot text colors are different. (If the colors are the same then the glyphs should be readable in both states. There aren't separate hot versions of the glyphs.)

The SystemParametersInfo:SPI_GETFLATMENU stuff is removed in Opus 10.0.3.2, thanks to changes in WindowBlinds 7.30a that mean it is no longer required.
Directory Opus:
  • Fixed in 10.0.3.1, tweaked in 10.0.3.2 to take advantage of changes in WB 7.30a.
WindowBlinds:
  • Fixed in 7.30a.
Screenshots:
  
D3Opus menu drop-buttons not selected with some themes.
Description:Some WindowBlinds styles (e.g. Sublime) caused Opus to draw selected menu drop-downs without a selected background.

This was due to the themes' "normal menu item" background being opaque instead of transparent as in the standard Windows Aero menu theme.
Directory Opus:
  • Fixed in 10.0.3.1. (The "normal item" background was being drawn on top of the drop-down arrow by mistake, but the mistake was invisible with most styles.)
WindowBlinds:
  • While this was definitely a bug in Opus, it would still make sense for Sublime (and any similar styles) to draw nothing, instead of an opaque background, for the normal-menu-item element, so that it conforms to the standard styles (which are the closest thing anyone has to API documentation in most cases).
Screenshots:
  
D4Opus resize grips opaque on glass status bar.
Description:Some WindowBlinds themes (e.g. Precision) draw resize grips with opaque backgrounds, which looked bad if Opus was configured to use a glass status bar.
Directory Opus:
  • Fixed in 10.0.3.1. (Kludge: if the drawn grip is entirely opaque we guess the background colour and remove it.)
WindowBlinds:
  • Precision (and any other visual styles with the same behaviour) should IMO be changed to draw resize grips with a transparent background like all the standard visual styles (which are the closest anyone has to actual theme API documentation). Open to debate, though, and not a big deal.
Screenshots:
  
D5Opus glass status bar text colors forced to black.
Description:With wblind*.dll patched to remove DOPUS.EXE, WindowBlinds styles like Precision and Sublime cause all text on Opus's glass status bar to be black. The themes seem to cause DrawThemeTextEx's text-color argument to be ignored, and force it to be black even though their titlebar text is closer to white.

Strangely, this does not happen with WindowBlinds unpatched and detecting Opus. I have no idea why, given standard behaviour with Windows Aero is to honor the colors.

Note: Opus can be configured to render the status bar without glass, so this isn't a showstopper, but it still seems wrong.
Directory Opus:
  • N/A. (Not an Opus issue, as far as I can tell.)
WindowBlinds:
  • Fixed in 7.30a.
Screenshots:
  
D6Opus folder tabs with black fringing.
Description:With styles which had non-rectangular tabs, and with Opus configured to show its folder tabs (upside-down) below the file display, Opus drew the folder tabs with black fringes around them.
Directory Opus:
  • Fixed in 10.0.3.1.
WindowBlinds:
  • N/A. (Bug in Opus.)
Screenshots:
  
D7Opus custom controls missing frames.
Description:Some of Opus's custom controls had missing/unpainted frames with some WindowBlinds styles.

Opus tried to draw the frames using DrawThemeBackground with PartId=0 and StateId=0 but the LISTVIEW and TREEVIEW themes (and/or their Explorer::* versions) within some WindowBlinds styles are missing those elements.

To work around this, Opus now tests GetThemeBackgroundExtent and, if it does not expand the rectangle for a frame, calls DrawThemeEdge instead of DrawThemeBackground.

This is not ideal, since it means the frames don't always match other control frames, but in my opinion the real fix is needed to the visual styles themselves; the styles should not contain themes which are missing parts present in the standard Windows Aero style's equivalent themes (which is the closest anyone has to API documentation on how visual styles behave). Especially for the PartId=0,StateId=0 parts.

Directory Opus:
  • Fixed in 10.0.3.1. (Workaround for older WB, and should be perfect with WB 7.30a.)
WindowBlinds:
  • Fixed in 7.30a.
Screenshots:
  
D8Opus toolbar lines too dark.
Description:With some styles, Opus drew the horizontal lines between toolbars using black when a lighter color should have been used.

The underlying cause is the same as the previous issue (D7), since the color was being taken from the frames, which were not being drawn by some styles.

(It seems like there must be a better way to get the shadow color for a theme, but we must have tried other ways before resorting to the kludge of reading colors out of rendered theme elements. Will check that again, however, though it's not urgent as things seem okay.)
Directory Opus:
  • Fixed in 10.0.3.1. (Not perfect, need to test better way/suggestions.)
WindowBlinds:
  • N/A.
Screenshots:
  
D9Opus missing (most of) the horizontal gripper on some toolbars/dialogs.
Description:The REBAR theme has two elements, GRIPPER and GRIPPERVERT. The first should be a horizontal strip of some kind, for going along the top edge of things like vertical toolbars. The second should be a vertical strip, for going along the left edge of things like horizontal toolbars.

With some WindowBlinds styles (e.g. Precision and Sublime), both elements are a vertical strip, leaving just a little dot or two for the grip at the top of vertical toolbars and the color-chooser in Opus.

(If you don't see any grips at all in Opus, you may need to unlock the toolbars or enter Customize mode.)
Directory Opus:
  • N/A. (Bug in the WindowBlinds styles that we cannot easily work around.)
WindowBlinds:
  • Fixed in 7.30a.
Screenshots:
  
D10Opus's entire color-chooser dialog flashes when its buttons are touched.
Description:Best seen via the video, linked below. If you are using the Precision theme and open the Opus color-chooser, whenever the mouse pointer crosses one of the three buttons the entire color-chooser window has an animated shine/flash effect played over it.

The buttons in question are "windowless" controls, where the BUTTON theme element is drawn directly into part of the color-chooser window.

At a guess, WindowBlinds is applying this affect to any window with particular styles (e.g. no border; or some other heuristic) when it draws a hot BUTTON element into itself, on the assumption that the window itself is a button. If my guess is true, WindowBlinds needs to improve the assumptions and conditions it uses to decide when and where to do this. e.g. Only apply the effect to the area where the button element was actually drawn, and/or don't apply the effect to such a large, top-level window.
Directory Opus:
  • N/A. (Bug in WindowBlinds.)
WindowBlinds:
  • Fixed in 7.30a.
Screenshots:010.mp4 (Video, since a screenshot won't really work.)
  
D11Opus transition animations broken by Sublime.
Description:If you use the Sublime theme, transition animations in Opus are broken.

From debugging, this seems to be because Sublime causes bogus/inconsistent window sizes/metrics to be reported to applications. Those bogus size values trip sanity-checks in our animation code and cause it to bail out. (I tried removing the sanity checks and the result is completely messed up animations.)

This is most likely related to issue W12, which affects most WB styles but affects Sublime more than others.

Further info: Sublime breaks the transition animations of any file display that is touching the right-hand edge of the window it is in, due to (I think) the window-metrics issue causing Opus's layout code to position the right-hand edge of the file display slightly outside of the top-level window's client area. Similar problems, or glitches like animations which cause the window contents to be offset while playing, may affect other themes/situtations, but Sublime seems the worst as it makes the window metrics further out than most others.
Directory Opus:
  • N/A. (Bug in WindowBlinds or Sublime.)
WindowBlinds:
  • Window metrics should be corrected.
Screenshots:YouTube Video (Video, since a screenshot won't really work. Skip to 2m53s if the link doesn't do so automatically.)
  
D12Opus "help" buttons partially off the right edge of their windows.
Description:The Opus Preferences window (and various others) has a help button at the top-right. With many WindowBlinds styles, this button is too far to the right and partially clipped by the window edge.

This is not a bug in Opus; the help button in is being positioned by the standard Win32 menu control.

The styles which cause this problem will do so with any right-aligned menu on any standard menu bar. That includes menus with simple text labels.

The problem is easier to see with some styles than others. Sublime makes it easiest to see (modulo the black-on-dark-gray text). Presumably its wide window borders are somehow related to the problems the standard menu control has in determining the width of the window? (Could this tie into D11 and the broken transition animations with Sublime?)

With other styles, like in the second screenshot below, it can be harder to notice because the clipping isn't enough to eat into the label but does still eat into the menu-item's frame. In that second screenshot, note that the label is right up against the edge of the window, not indented like the File item is on the left, and also note that you cannot see the right-hand edge of the Help item's frame.

The MenuTest program shown below is just the Visual Studio 2008 template Win32 GUI application with a single change: Giving the "Help" menu RightJustify=TRUE in the menu resource.

This is almost certainly a consequence of issue W12.
Directory Opus:
  • Workaround in Opus 10.0.3.1. Based on issue W12, Opus detects the WindowBlinds non-client metrics error and increases the width of the Help menu item proportionally, so that it is still clipped but the icon itself looks correct.
WindowBlinds:
  • Definitely a bug in WindowBlinds.
Screenshots:



  
D13Opus "help" button backgrounds don't match menu-bar backgrounds.
Description:The Opus Preferences window (and various others) has a help button at the top-right. With many WindowBlinds themes, the button's background is wrong (a solid square) compared to the menu bar it is on top of (often a gradient fill or similar).

While this will require a code-change in Opus (Opus currently draws the solid square background itself), several problems in WindowBlinds have prevented me from finding a way to fix it.

The button is currently an owner-draw menu item (MFT_OWNERDRAW) where the WM_DRAWITEM handler fills the solid menu background color.
  1. If the WM_DRAWITEM handler is changed so it doesn't draw any background at all, and paints on top of whatever is in the HDC given to it by the OS, then this works fine with Windows Aero but results in a solid black background with the WindowBlinds styles I tested. So we can't do that. (Unless there's some unwritten requirement to do something special regarding the alpha channel, which I didn't think to try. But that isn't needed for Windows Aero, anyway.)

  2. If the WM_DRAWITEM handler is changed to explicitly draw the MENU theme's background, that doesn't work either. Some themes don't seem to even have a MENU background element (or if they do it doesn't match what is actualyl drawn on the menu). Others have the background a element but only one them, and draw a different background when the window is active and inactive. (So when the window is activated/deactivated, the backgrounds no longer match up.) It looks like some WindowBlinds themes also make the top-level window translucent in the menubar area, which probably complicates things.

  3. I also tried changing the menu item from being completely owner-draw to just having an owner-draw bitmap (MFT_OWNERDRAW cleared from fState, MIIM_BITMAP added to fMask and hbmpItem set to HBMMENU_CALLBACK). That also works great with Windows Aero but fails with the WindowBlinds styles. (I can't remember if it resulted in a black background or no icon at all.)

  4. Finally, I tried letting the menu control do all the drawing itself -- no owner-draw or WM_DRAWITEM handler at all -- by converting the icon into an RGBA 32bpp bitmap and setting it as hbmpItem when adding the menu item. That works great with Windows Aero but draws nothing at all with any of the WindowBlinds themes.
Directory Opus:
  • Fixed in 10.0.3.2, thanks to changes in WB 7.30a.
WindowBlinds:
  • Fixed in 7.30a.
Screenshots:

  
D14Opus (and Explorer) show no keyboard-focus rects.
Description:With most of the non-Aero-derived WindowBlinds themes, trying to operate Directory Opus or Windows Explorer via the keyboard Ctrl-Up/Down (move focus without changing selection) is very difficult because the themes are missing the focus rects and you are driving blind.
Directory Opus:
  • N/A. (Bug in the WB styles.)
WindowBlinds:
  • Fixed in 7.30a.
Screenshots:Windows Explorer + "Win8" theme:
(Keyboard focus is on the Videos library, but there's no outline around it.)


(See the 4th video from my earlier set for better examples in both Explorer and Opus.)
  
D15Opus theming and file dialogs broken by WindowBlinds.
Description:The current version of WindowBlinds breaks all visual styles within Opus and, more importantly, breaks all standard file dialogs in Opus (they won't even open). WindowBlinds detects any program called "dopus.exe" and causes these problems with it.

(Obviously, the rest of this page was based on testing against a patched version of WindowBlinds where its detection of DOPUS.EXE was hex-edited out.)
Directory Opus:
  • N/A. (Bug in WindowBlinds.)
WindowBlinds:
  • Fixed in 7.30a.
Screenshots:(Lots of screenshots and videos on YouTube and in the WB forum; no need to repeat them here.)
  
D16Opus (and other apps') menu bars not painted properly when resized.
Description:With the WindowBlinds Precision style and a window with a standard menu-bar at the top, as you increase the width of the window a trail of artifacts is left along the bottom edge of the menu bar.

Looks like Precision is not painting the bottom row of pixels for that element. (Also results in the whole width of it being randomly black or white sometimes.)

Affects Opus dialogs like the Filetypes editor and standard Windows apps like Notepad and Task Manager.
Directory Opus:
  • N/A.
WindowBlinds:
  • Fixed in 7.30a.
Screenshots:Opus:


Notepad:


Task Manager:
  
D17Opus titlebar splits in half with Sublime on XP.
Description:I haven't tested much with WB on XP, but this is completely bizarre.

With Sublime on XP, opening any child dialog of the Opus licence manager causes the minimize box to jump over to the left half of the dialog, then back again when the child closes.

I haven't the foggiest idea what might cause this, although it's worth noting that the top-right edge of the window borders is wrong from the moment they open and things get worse from there.
Directory Opus:
  • N/A.
WindowBlinds:
  • I think this has been reported fixed, although I haven't taken the time to re-test it myself.
Screenshots:Still frame:


Video of what happens:
D17b.mp4
  
W1WindowBlinds Sublime glitches with Aero Peek.
Description:With WindowBlinds set to use Sublime, triggering Aero Peek causes:
  1. White lines and other artifacts to appear along the top edge and all four corners of the active window.
  2. Where a glass placeholder represents the other windows, the glass shine texture does not reach the edges, leaving conspicuous gaps between the shine and the outline. Most visible at the top, but happens on all four sides.
WindowBlinds:
  • Bug in WB affecting all applications.
Screenshots:Two Notepad windows side-by-side:
  
W2WindowBlinds Sublime line on scrollbar.
Description:With WindowBlinds set to use Sublime, all apps showing disabled scrollbars (e.g. Notepad, pictured below) have a white line between the horizontal scrollbar and its right arrow. The other three arrows do not have a similar line.
WindowBlinds:
  • Fixed in 7.30a.
Screenshots:
  
W3WindowBlinds "Win8" paints extra resize grip where it shouldn't be.
Description:With WindowBlinds set to use the "Win8" style, vert+horiz scrollbars always have a resize grip in their bottom-right square, whether or not the app has requested one.

e.g. With Notepad (with status bar turned on), or MSPaint, you get a window with two resize grips at the bottom.

In some cases the extra grip is in the middle of the window which makes even less sense.

(The extra grips are not there with other styles so it's not just the apps making a mistake, which can happen as well, e.g. TextPad.)
WindowBlinds:
  • Bug in "Win8" style.
Screenshots:Notepad + "Win8":


MSPaint + "Win8":


MSPaint + Windows Aero:


Windows file permissions dialog + "Win8":
  
W4WindowBlinds Sublime has a gap in the multi-line tab control.
Description:With WindowBlinds set to use Sublime, the multi-line tab control has a gap in the right-hand side where the frame doesn't join up.
WindowBlinds:
  • Fixed in 7.30a.
Screenshots:Windows exe-file Properties dialog:
  
W5WindowBlinds Sublime breaks resizing by window corners.
Description:With WindowBlinds set to use Sublime, you cannot diagonally resize windows by the top-right corner at all (and where it indicates you can, clicking actually closes the window instead of resizing it). Diagonal-resizing by the other corners is possible but the hotspots are in the wrong place, so it's not actually by the corners, but somewhere significantly in from the corners.
WindowBlinds:
  • Fixed in 7.30a (top-right corner not perfect, but it's much better).
Screenshots:(See the 4th video from my earlier set.)
  
W6WindowBlinds makes DebugView look like a Win95 app.
Description:With WindowBlinds set to use anything but Windows Aero, the SysInternals DebugView app has all themes disabled, to the point that even its window borders look like Win95. This is despite the app working fine with Windows Aero, and (if you rename the exe) fine with the WindowBlinds styles as far as I could tell. Even if there are valid compatibility issues, it surely doesn't deserve to be made to look this bad.
WindowBlinds:
  • Whatever the reason, disabling themes entirely for DebugView is overkill.
Screenshots:
  
W7WindowBlinds "Win8" menu misreports gutter width and has incorrect elements.
Description:With WindowBlinds set to use the "Win8" style, right-clicking the desktop shows you a menu where the icons are too far to the right, so far that they are drawn on top of the menu-gutter edge.

This appears to be caused by the style's MENU theme misreporting its gutter width as zero.

The same theme causes two different problems with Firefox 9 where the gutter has a box drawn around it and the horizontal separators start too far to the right.

(From what I can tell, Firefox is using the theme's gutter element and that's where the box is coming from. I'm not sure why the system isn't drawing the same box; maybe the system code falls back on its own gutter-rendering if the theme reports a zero-width element. Either way, both the standard menu-rendering code and Firefox's code look wrong, in different ways, with this style.)
WindowBlinds:
  • Bugs in "Win8" style.
Screenshots:Windows desktop + "Win8" style:
(Note the position of the icons in the menu.)


Firefox 9 + "Win8" style:
(A box, which comes from the theme itself, is drawn around the menu-gutter; the horizontal separators also start too far to the right.)

(Firefox should look a bit better in WB 7.30a, though I haven't tested. Windows itself and Opus still have problems with separator positions and/or icon placement.
  
W8WindowBlinds styles with incorrect disabled-bullet glyphs.
Description:MENU themes should have four glyphs:
  1. Checkmark
  2. Disabled Checkmark
  3. Bullet
  4. Disabled Bullet
The disabled versions are usually some combination of grayed/ghosted/translucent.

With the Sublime style, the first three glyphs are correct but the disabled-bullet glyph is identical to the normal one, without any ghosting etc.

(I noticed the same problem with at least one other style but didn't note which it was. Most of the non-Opus problems on this page should be checked against the other styles since I wasn't actually looking for problems in the styles and just made a not of the ones I stumbled upon while testing Opus.)
WindowBlinds:
  • Fixed in 7.30a.
Screenshots:
  
W9WindowBlinds Sublime (and more) makes "Empty Recycle Bin" look disabled when it isn't.
Description:With Sublime, when you right-click the Recycle Bin on the desktop, the menu that opens appears to have a disabled "Empty Recycle Bin" item, as if the bin was already empty and the option was not available...

...as soon as you move your mouse over that item, it is re-drawn in the enabled state.

I checked several times and it always happens with Sublime and never happened with Windows Aero.

I later noticed the same problem with another theme, I think Precision but I'm not certain.
WindowBlinds:
  • Happens less in 7.30a, but right-click the bin a few times and you'll still see it.
Screenshots:Disabled-looking item when the menu first appears:


Move the mouse over it and it looks enabled:
  
W10WindowBlinds styles cause various Win7 taskbar glitches.
Description:With several of the styles there are weird bars, seams, missing edges and other glitches in various places on the Windows 7 taskbar.

Sometimes the glitched regions fade in and out or move around, which really draws attention to them.

(Contrary to my earlier assumptions, it turns out this was just a bug; the styles in question were in fact designed for Win7 and something just got messed up, and is now fixed.)
WindowBlinds:
  • Fixed in 7.30a.
Screenshots:Best seen in a motion for the full effect, so here's a quick video:
W010.mp4

Some screenshots:





  
W11WindowBlinds Sublime makes parts of Windows barely readable.
Description:I know some people like really dark styles but Sublime makes things almost unreadable in places, even when just looking at standard Win7 apps.

Sublime also has white backgrounds in other places, making the low-contrast, dark-gray-on-black (or vice versa) areas even harder on the eye because they're next to big white panels.

Surely these color combinations were not intentionally chosen with Windows 7 in mind?

This, along with the various other problems I ran into, gave me the impression that, while they may have worked great in the past, at least some of the styles that ship with WindowBlinds were never properly used/tested/updated for Windows 7.
WindowBlinds:
  • Fixed in 7.30a (Explorer details panel still the same, FWIW.)
Screenshots:



  
W12WindowBlinds causes OS to report inconsistent/incorrect non-client metrics to apps.
Description:WindowBlinds causes WM_NCCALCSIZE and ClientToScreen to produce inconsistent results, in addition to (and possibly because of) SM_CXSIZEFRAME and/or SM_CXFIXEDFRAME being incorrect for the actual borders.

All of the non-Aero styles, except the "Metro" one, are incorrect for resizable windows. It seems to be pure luck that Metro is correct for resizable windows, as it is still incorrect for fixed-size windows.

Some styles are more incorrect than others, e.g. Sublime is out by five pixels (ten if you count both edges) while most of the others are out by less. The style that's a clone of OS X is out by a negative offset.

This most likely explains several problems that WindowBlinds causes, e.g. the standard menus mis-calculating the width of the window, and Sublime breaking Opus's transition animations.

Another thing that seems odd is that the disparity between WM_NCCALCSIZE and ClientToScreen only happens once a window has been shown on-screen. If the window remains hidden, or is shown but in an off-screen position, the metrics are still consistent. So, while I'm not entirely sure, it seems like something that WindowBlinds breaks the first time it paints the border around a window. That makes it a pain to detect the problem and apply corrections to layout code since the problem doesn't manifest until the window is already on the screen.

This is essentially breaking several parts of the Win32 API contract.

The WBTest.zip program (source included) was used to investigate this and make the screenshots below. The version in the zip file lets you test both fixed-size and resizable windows, although only resizable ones are shown in the screenshots below.
WindowBlinds:
  • Bug.
Screenshots:(The WBTest.exe output looks slightly different now as I added some more checks/reports after making these screenshots.)

Windows Aero, Luna, Classic and all standard styles give consistent metrics:


Every WindowBlinds style I tried, other than Aero-based ones, broke the metrics for either resizable or fixed-size windows (and usually for both):

Context and Rationale

This page is written by a member of the Directory Opus team and only represents my take on things:

We strongly request that future versions of WindowBlinds do not detect Opus or treat it specially in any way whatsoever:

Tools Stardock could provide to help

Stardock are in a unique position to help themselves, their users and the entire Windows development community with tools to help developers work with visual styles.

Windows has supported visual styles for over a decade but Microsoft, shamefully, have failed to document the API much beyond the basic function prototypes and a few identifier definitions. There is very little documentation explaining when each theme element, metric, etc. is supposed to be valid, how they are supposed to behave, and which parts/states/metrics should be used to draw different types of controls.

The API is also comical in the number of different ways it can provide information (e.g. the width or color of a part) combined with the high likelyhood that the information that actualy comes back is completely bogus for a given style/theme/ID. Developers are expected to magically know what to ask for, when to ask for it, and which of the many possible methods for doing so is correct.

With no proper guidance, and a messy API full of redundant methods (most of which don't actually work in most situations), developers have to get by based on the behaviour of the standard styles, a hell of a lot of guesswork and experimentation, the rare piece of (usually very incomplete) sample code, word-of-mouth and (when really desperate) assembly-level debugging of system components. The situation is downright ridiculous.

On the opposite side, style authors have no way to know what developers expect their styles to do, except by looking at what the standard styles do and how different applications happen to use them. That, too, is far from ideal.

There is no real API contract, only incomplete examples which people use to infer the API's behaviour. Where a theme deviates from standard behaviour for no good reason, it is breaking the closest thing we have to an API contract.

Ten years on, there is little hope of Microsoft ever documenting things properly, but Stardock are in a unique position to help with tools: