Sent to all top-level windows when the colorization color has changed.
wParam: Specifies the new colorization color. The color format is 0xAARRGGBB.
lParam: Specifies whether the new color is blended with opacity.
We receive this message when the Aero Glass colour changes. Unfortunately, the value contained in wParam is not the ‘base colour’, as it is in fact the result of the DwmGetColorizationColor function. As Rafael Rivera noted last year, when glass transparency is enabled, the value returned by this function is quite different to the base colour:
As such, we shouldn’t rely on the contents of wParam (or on the DwmGetColorizationColor function in general).
The easiest method to find the actual base colour is to retrieve the ColorizationColor DWORD from HKCUSoftwareMicrosoftWindowsDWM. This, however, is undocumented, and could potentially change in a future version of Windows (it is correct in NT 6.0 and 6.1):
RegistryKey colourKey = Registry.CurrentUser.CreateSubKey(@"SoftwareMicrosoftWindowsDWM");
uint colour = (uint)(int)colourKey.GetValue("ColorizationColor");
(We can’t cast directly to uint despite it being a REG_DWORD, hence the first cast to int…)
For those who feel more adventurous, Rafael went to the trouble of finding a function in dwmapi.dll which returns the base colour (amongst other things). He describes it here.
Winreview.ru’s latest Office 15 screenshots reveal application-specific border colours and drop-shadows. Word gets a dark blue border and shadow, Excel gets a green border and shadow, etc.:
Microsoft in fact applied for a patent for per-window glass colourisation in late 2005 (‘Glass appearance window frame colorization’; discovered by Long Zheng in 2007). While there isn’t any glass in the Office 15 windows shown here (despite the DWM being enabled), the idea is similar.
Office 15 and Windows 8 seem to be moving in similar UI directions – it seems like square corners are in and transparency is out (at least for the ‘Aero Lite’ theme).
Some early screenshots of Windows 8 have leaked recently, providing some clues as to what changes we might see in the user interface.
- User Account Pictures in the Taskbar
Two screenshots show a 32×32 px (actually 28×32 px in the second screenshot) user account picture in the taskbar, located between the clock and ‘show desktop’ button:
- Updated Language Bar
Assuming the ‘ENG’ in the second screenshot above refers to ‘English’, an updated language bar may be part of Windows 8. (The three letter language code would mark a change from ISO 639-1 found in previous versions of Windows to ISO 639-2.)
- Centred Window Titles
Rafael Rivera spotted this in Sinofsky’s Windows 8 ARM demo at CES earlier this year. (Photo by Long Zheng.)
A new screenshot seems to confirm this:
Windows has had left-aligned window title text since Windows 95 – in Windows 3.1 and earlier it was centred. Office 2007 and 2010 notably broke that convention, however, using centred text as part of their custom-drawn title bars (make a Microsoft Word window narrow enough and you can see the custom chrome replaced with the OS standard).
Refreshed DWM-less New Theme
While the resolution of the screenshot immediately above leaves a lot to be desired, we can still see some clear differences from Aero Basic as it appears in Windows Vista and Windows 7 (update: in fact, this theme might be a DWM-enabled theme). The window border colour is almost flat (there is a very subtle gradient), the window corners appear to be square at the top as opposed to just the bottom, and the ‘X’ on the close button is coloured black, not white (the window appears not to be active). Additionally, it looks like the close button is flush with the window border (as in Aero), in contrast to Aero Basic where a 7 pixel border is drawn above the caption buttons. Finally, the button control seems to have a new theme.
View source on GitHub.
Ken Silverman’s PNG compression tool PNGOUT (complemented nicely by the free .NET frontend PNGGauntlet) can be remarkably effective at trimming the size of PNGs without altering the image described within.
However, in its quest to remove anything non-essential, PNGOUT by default strips out the image’s DPI (in fact PPI) information. PNGs without PPI information will be treated differently by different software.
WPF either uses a default of 96 or the current system DPI with such images (I’m not sure which, but the latter makes more sense). Sometimes this can have nice side-effects, as Scott Hanselman discovered – images that were designed for 96 PPI but set to 72 PPI were suddenly ‘fixed’ (at least when the application was run in a 96 DPI environment). Better than relying on WPF’s interpretation of PNGs without PPI information is to correctly set the PPI in the first place. For example, if an image is designed for 120 DPI but has its PPI set to 96, WPF will (correctly) try and scale the image, which is clearly not desirable.
PNGOUT features a command line option /k# for removing or keeping optional chunks. The pHYs chunk holds the PPI information, which is what we want to leave alone. Using the command line option /kpHYs with PNGOUT will thus preserve PPI information. (Information from WulfTheSaxon.)
Sometimes, though, it is useful to have a utility that sets PPI information for lots of images at once (the PPI information in the PNGs may not be correct before using PNGOUT, for instance, rendering the /kpHYs switch pointless).
Josip Medved had the same thought and created a tool for setting the PPI to 96 for many images at once.
I decided to slightly extend his tool to take the desired horizontal and vertical PPI as command line arguments. The source and binaries can be downloaded here (SHA-1: 800D83A390F2AD80772D79D7FB45C7EAAB0D4294). The usage is SetDPI dpiX dpiY filepattern1 [filepattern2 […]].
- SetDPI 96 96 *.png (sets all PNG files to 96 PPI)
- SetDPI 120 120 a.png b.png c.png (sets a.png, b.png and c.png to 120 PPI)
- SetDPI 144 144 C:Images*.png (sets all PNG images in directory C:Images to 144 PPI)