Larry Osterman's WebLog : Nifty Win32 tricks.

Building a flicker free volume control

LarryOsterman — Thu, 17 Sep 2009 00:50:09 GMT

When we shipped Windows Vista, one of the really annoying UI annoyances with the volume control was that whenever you resized it, it would flicker.

To be more specific, the right side of the control would flicker – the rest didn’t flicker (which was rather strange).

Between the Win7 PDC release (what we called M3 internally) and the Win7 Beta, I decided to bit the bullet and see if I could fix the flicker. It seems like I tried everything to make the flickering go away but I wasn’t able to do it until I ran into the WM_PRINTCLIENT message which allowed me to direct all of the internal controls on the window to paint themselves.

Basically on a paint call, I’d take the paint DC and send a WM_PRINTCLIENT message to each of the controls in sndvol asking them each to paint themselves to the new DC. This worked almost perfectly – I was finally able to build a flicker free version of the UI. The UI wasn’t perfect (for instance the animations that faded in the “flat buttons” didn’t fire) but the UI worked just fine and looked great so I was happy that' I’d finally nailed the problem. That happiness lasted until I got a bug report in that I simply couldn’t figure out. It seems that if you launched the volume mixer, set the focus to another application then selected the volume mixer’s title bar and moved the mixer, there were a ton of drawing artifacts left on the screen.

I dug into it a bunch and was stumped. It appeared that the clipping rectangle sent in the WM_PAINT message to the top level message didn’t include the entire window, thus portions of the window weren’t erased. I worked on this for a couple of days trying to figure out what was going wrong and I finally asked for help on one of our internal mailing lists.

The first response I got was that I shouldn’t use WM_PRINTCLIENT because it was going to cause me difficulty. I’d already come to that conclusion – by trying to control every aspect of the drawing experience for my app, I was essentially working against the window manager – that’s why the repaint problem was happening. By calling WM_PRINTCLIENT I was essentially putting a band-aid on the real problem but I hadn’t solved the real problem, all I’d done is to hide it.

So I had to go back to the drawing board. Eventually (with the help of one of the developers on the User team) I finally tracked down the original root cause of the problem and it turns out that the root cause was somewhere totally unexpected.

Consider the volume UI:

The UI is composed of two major areas: The “Devices” group and the “Applications” group. There’s a group box control wrapped around the two areas.

Now lets look at the group box control. For reasons that are buried deep in the early history of Windows, a group box is actually a form of the “button” control. If you look at the window styles for a button in SpyXX, you’ll see:

Notice the CS_VREDRAW and CS_HREDRAW window class styles. The MSDN documentation for class styles says:

CS_HREDRAW - Redraws the entire window if a movement or size adjustment changes the width of the client area.
CS_VREDRAW - Redraws the entire window if a movement or size adjustment changes the height of the client area.

In other words every window class with the CS_HREDRAW or CS_VREDRAW style will always be fully repainted whenever the window is resized (including all the controls inside the window). And ALL buttons have these styles. That means that whenever you resize any buttons, they’re going to flicker, and so will all of the content that lives below the button. For most buttons this isn’t a big deal but for group boxes it can be a big issue because group boxes contain other controls.

In the case of sndvol, when you resize the volume control, we resize the applications group box (because it’s visually pinned to the right side of the dialog). Which causes the group box and all of its contained controls to repaint and thus flicker like crazy. The only way to fix this is to remove the CS_HREDRAW and CS_VREDRAW buttons from the window style for the control.

The good news is that once I’d identified the root cause, the solution to my problem was relatively simple. I needed to build my own custom version of the group box which handled its own painting and didn’t have the CS_HREDRAW and CS_VREDRAW class. Fortunately it’s really easy to draw a group box – if themes are enabled a group box can be drawn with DrawThemeBackground API with the BP_GROUPBOX part and if theming is disabled, you can use the DrawEdge API to draw the group box. Once I added the new control that and dealt with a number of other clean-up issues (making sure that the right portions of the window were invalidated when the window was resized for example), making sure that my top level control had the WS_CLIPCHILDREN style and that each of the sub windows had the WS_CLIPSIBLINGS style I had a version of sndvol that was flicker free AND which let the window manager handle all the drawing complexity. There are still some minor visual gotchas in the UI (for example, if you resize the window using the left edge the right side of the group box “shudders” a bit – this is apparently an artifact that’s outside my control – other apps have similar issues when resized on the left edge) but they’re acceptable.

As an added bonus, now that I was no longer painting everything manually, the fade-in animations on the flat buttons started working again!

PS: While I was writing this post, I ran into this tutorial on building flicker free applications, I wish I’d run into it while I was trying to deal with the flickering problem because it nicely lays out how to solve the problem.

What’s the difference between GetTickCount and timeGetTime?

LarryOsterman — Thu, 03 Sep 2009 00:31:17 GMT

I’ve always believed that the most frequently used multimedia API in winmm.dll was the PlaySound API. However I recently was working with the results of some static analysis tools that were run on the Windows 7 codebase and I realized that in fact the most commonly used multimedia API (in terms of code breadth) was actually the timeGetTime API. In fact almost all the multimedia APIs use timeGetTime which was somewhat surprising to me at the time.

The MSDN article for timeGetTime says that timeGetTime “retrieves the system time, in milliseconds. The system time is the time elapsed since the system started.”.

But that’s almost exactly what the GetTickCount API returns “the number of milliseconds that have elapsed since the system was started, up to 49.7 days.” (obviously timeGetTime has the same 49.7 day limit since both APIs return 32bit counts of milliseconds).

So why are all these multimedia APIs using timeGetTime and not GetTickCount since the two APIs apparently return the same value? I wasn’t sure so I dug in a bit deeper.

The answer is that they don’t. You can see this with a tiny program:

int _tmain(int argc, _TCHAR* argv[])

    int i = 100;

    DWORD lastTick = 0;

    DWORD lastTime = 0;

    while (--i)

        DWORD tick = GetTickCount();

        DWORD time = timeGetTime();

        printf("Tick: %d, Time: %d, dTick: %3d, dTime: %3d\n", tick, time, tick-lastTick, time-lastTime);

        lastTick = tick;

        lastTime = time;

        Sleep(53);

    return 0;

If you run this program, you’ll notice that the difference between the timeGetTime results is MUCH more stable than the difference between the GetTickCount results (note that the program sleeps for 53ms which usually doesn’t match the native system timer resolution):

Tick: 175650292, Time: 175650296, dTick: 46, dTime: 54
Tick: 175650355, Time: 175650351, dTick: 63, dTime: 55
Tick: 175650417, Time: 175650407, dTick: 62, dTime: 56
Tick: 175650464, Time: 175650462, dTick: 47, dTime: 55
Tick: 175650526, Time: 175650517, dTick: 62, dTime: 55
Tick: 175650573, Time: 175650573, dTick: 47, dTime: 56
Tick: 175650636, Time: 175650628, dTick: 63, dTime: 55
Tick: 175650682, Time: 175650683, dTick: 46, dTime: 55
Tick: 175650745, Time: 175650739, dTick: 63, dTime: 56
Tick: 175650792, Time: 175650794, dTick: 47, dTime: 55
Tick: 175650854, Time: 175650850, dTick: 62, dTime: 56

That’s because GetTickCount is incremented by the clock tick frequency on every clock tick and as such the delta values waver around the actual time (note that the deltas average to 55ms so on average getTickCount returns an accurate result but not with spot measurements) but timeGetTime’s delta is highly predictable.

It turns out that for isochronous applications (those that depend on clear timing) it is often important to be able to retrieve the current time in a fashion that doesn’t vary, that’s why those applications use timeGetTime to achieve their desired results.

Delay Load is not a good way to check for functionality

LarryOsterman — Fri, 06 Mar 2009 23:19:26 GMT

On my previous post, Koro made the following comment:

“Don't ever check windows versions. Instead check for functionality being present or not."

You can't always do that.

Do I want to add a __try/__except to catch delay-load exceptions around every UxTheme call or just do:

g_bTheme=(g_bWinNT&&(g_nWinVer>0x00050001));

Then check that flag before calling OpenThemeData?

In some other cases too (all the Crypt Hash functions - trying to compute an MD5) the functions is documented as working fine in Win98 but it just fails - there is no way to know except of checking the version beforewards.

At least, as implied earlier, I just pack the Windows version in a DWORD at program startup to avoid nasty version comparision errors.

IMHO Koro’s misusing the delayload functionality.

DelayLoad is primarily a performance tool – when you DelayLoad a function, a tiny stub for the DelayLoad function is inserted into your application which calls LoadLibrary/GetProcAddress on the function. That then means that when your application is launched, the loader doesn’t resolve references to the DelayLoaded function and thus your application will launch faster.

For example many components in the OS delay load WINMM.DLL because all they use in WINMM is the PlaySound API, and even then they only use it on relatively rare circumstances. By delayloading WINMM.DLL they avoid having the performance penalty of having WINMM.DLL loaded into their address until it’s needed.

As Koro mentioned, DelayLoad can also be used as a mechanism to check to see if a particular piece of OS functionality is present, but the challenge is that now you need to wrap every API call with an exception handler (or you need to specify a delay load handler that provides a more reasonable default behavior). Personally I wouldn’t do that – instead I’d manually call LoadLibrary/GetProcAddress to load the required functions because it allows you to have complete control over when you access over your error handling. It also allows you to avoid using structured exception handling (which should be avoided if at all possible).

If you DO have need to use DelayLoad as a functionality check, you could try this trick (which works only for Koro’s problem). Instead of wrapping all the theme API calls with SEH, you just add code to your app like this (I haven’t compiled this code, it’s just an example):

BOOL g_EnableThemes = FALSE;
__try
{
    g_EnableThemes = IsThemeActive();
}
__except(<Your Exception Filter>)
{
}

if (g_EnableThemes)

{
    g_ThemeHandle = OpenThemeData(…)





}

In other words check for functionality being enabled once with an exception handler and later on use just the EnableThemes global variable to key off the behavior.

But this doesn’t change the fact that (IMHO) you’re abusing the DelayLoad functionality and using it as a versioning mechanism.

Fixing an accessibility bug with the trackbar common control

LarryOsterman — Wed, 28 Jan 2009 04:17:00 GMT

The trackbar common control is a strange beast.

The trackbar can be oriented either horizontally or vertically. On LTR language machines, when the trackbar is horizontal, it works much as you’d expect it to: The minimum value of the trackbar is on the left, the maximum value is on the right (it’s reversed for RTL languages so it works consistently).

When the trackbar is vertical, it’s a different beast entirely. For whatever reason, the trackbar control designers set the minimum value of the trackbar at the top, the maximum value at the bottom. If you think about how the trackbar designers actually implemented the trackbar this makes sense. If you orient the trackbar so that the minimum value is at the top, then when you need to draw the trackbar you can use the same drawing code to draw the horizontal trackbar – you just swap the X and Y axis (I have absolutely no idea if that’s how it works internally, it just seems to make sense that way).

While this works great for the implementer, for the consumer of the trackbar, it’s a pain in the neck. That’s because the users who interact with the control expect the maximum value to be at the top of the control, not the bottom.

As a result, when you look at code that uses the trackbar control, you end up seeing a lot of:

LRESULT MyDialog::OnNeedTTText(int idCtrl, LPNMHDR pnmh)
{
    LPTOOLTIPTEXT pTT = (LPTOOLTIPTEXT)pnmh;
    if (idCtrl == IDD_TRACKBAR)
    {
        int nPos = (int)SendMessage(TBM_GETPOS, 0, 0);

        StringCchPrintf(pTT->szText, ARRAYSIZE(pTT->szText), TEXT("%d"), 100 - nPos);
    }
    return 0;
}

In other words, retrieve the position from the trackbar, convert it from 0..100 to 100..0 and return that as a tooltip text.

All of this works great – you have a lot of 100 - <n> scattered throughout your code, but it’s not the end of the world. And then one day a tester comes to you and says that when he uses the narrator tool to read the contents of your tool, it reports that the value reported by the control is wrong – when the slider’s at the top (tooltip 100), it reports that the value is 0, when it’s at the 1/4 point (tooltip 75), it reports that the value is 25.

Crud. At this point many developers start scratching their heads and start thinking about subclassing the trackbar to replace the reported position. However that’s way more work than they need to do.

It turns out that the designers of the trackbar control thought of this problem. If you’re using version 5.8 or higher of the common controls, you can specify the TBS_REVERSED trackbar control style to your trackbar. If you do, the visuals of the trackbar are unchanged as is the trackbar functionality, but the Microsoft accessibility framework will look for the presence of the TBS_REVERSED style and if it is found, it assumes that the control is “backwards” and it reports the position for the toolbar as if the maximum and minimum values were reversed.

And no, I didn’t know about this before today. But it was too good a trick not to share.

Fixing a customer problem: “No Audio Device is Installed” when launching sndvol on Windows Vista

LarryOsterman — Tue, 06 Jan 2009 22:26:03 GMT

Yesterday someone forwarded me an email from one of our DirectShow MVPs – he was having problems playing audio on his Windows Vista machine.

Fortunately David (the MVP) had done most of the diagnostic work – the symptoms he saw were that he was receiving a “No Audio Device is Installed” error launching sndvol (and other assorted problems).

David tried the usual things (confirming that the driver for his audio solution was correctly installed (this probably fixes 99% of the problems)). He also tried reinstalling the driver to no avail.

He next ran the Sysinternals Process Monitor tool to see what was going on. He very quickly found the following line in the output from process monitor:

"RegOpenKey", "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\MMDevices\Audio\Render\{e4ee1234-fc70-4925-94e9-4117395f7995}", "ACCESS DENIED", "Desired Access: Write"

With that information, he looked for the ACL on that registry key:

He then looked at the configuration for the Windows Audio service:

Woah – the Windows Audio service doesn’t have access rights to that registry key – the Windows Audio service is running as LocalService and the LocalService account doesn’t have any access to the registry key.

At this point he decided to contact Microsoft with his problem.

I looked at his info and quickly realized that the problem was that somehow the ACL on the registry key had been corrupted: something had removed the entries for the audio services. On a normal Windows Vista installation this registry key’s ACL should look something like:

Something that ran on David’s machines went in and reset the permissions for this registry key to the ACL that is on the root node of the HKEY_LOCAL_MACHINE\Software registry hive. I have no idea what did this, but messing with the ACLs on the registry is a known cause of various compatibility problems. That’s why Microsoft KB 885409 has such strong warnings about why it’s important to not apply blind modifications to files or registry keys in Windows. It’s unfortunate, but the warnings in the KB articles that say that modifying registry keys or permissions can cause your machine to malfunction are absolutely right – it’s not hard to make modifications to registry keys that can really screw up a machine, if you make the right ones. From the KB article:

For example, modifications to registry ACLs affect large parts of the registry hives and may cause systems to no longer function as expected. Modifying the ACLs on single registry keys poses less of a problem to many systems. However, we recommend that you carefully consider and test these changes before you implement them. Again, we can only guarantee that you can return to the recommended out-of-the-box settings if you reformat and reinstall the operating system.

The good news is that it should be relatively simple to fix David’s problem – As far as I know, he has two options. The first is to reinstall Windows Vista – that should reset the ACLs on the property key to their default values (because it will recreate the property keys), which should resolve the problem.

The second solution is to add an ACL to the registry keys under the MMDevices registry key to allow the LocalService account to have permissions to modify this registry key.

What really happens when you shutdown Windows?

LarryOsterman — Thu, 09 Oct 2008 20:47:53 GMT

About a year or so ago, I wrote a post that talked about the Windows shutdown experience.

A couple of the people reading the post asked for more details, and it turns out that the performance folks have just issued this paper which describes (in great detail) what happens during system boot and shutdown.

I skimmed over it before posting and thought it was pretty cool.

The common control library sometimes sends an NMCUSTOMDRAW message for the NM_CUSTOMDRAW notification.

LarryOsterman — Sat, 04 Oct 2008 02:37:55 GMT

I just fixed a bug in our UI that was caused by a misunderstanding of the API contract for the NM_CUSTOMDRAW handler for some of the common controls.

On of October 3rd, 2008 The common control documentation for the NM_CUSTOMDRAW message says:

lpNMCustomDraw
A pointer to a custom draw-related structure that contains information about the drawing operation. The following list specifies the controls and their associated structures.
List view
NMLVCUSTOMDRAW
ToolTip
NMTTCUSTOMDRAW
Tree view
NMTVCUSTOMDRAW
Toolbar
NMTBCUSTOMDRAW
All other supported controls
NMCUSTOMDRAW

While this is correct in general it is NOT true for the CDDS_PREPAINT draw stage. It turns out that some of the common controls only provide an NMCUSTOMDRAW structure when the drawing logic is in the CDDS_PREPAINT stage.

If you look VERY carefully at MSDN, you can find this page which mentions that the first NM_CUSTOMDRAW notification receives an NMCUSTOMDRAW structure and not an NMLVCUSTOMDRAW handler but that’s the only page I was able to find to indicate this.

I’ve notified the relevant documentation folks about this and hopefully the documents will be updated in the future. You can consider this blog post as a pre-update to the SDK documentation.

DrawThemeText doesn’t really support the DT_CALCRECT format value

LarryOsterman — Wed, 01 Oct 2008 02:49:00 GMT

I just noticed this while working on a bug fix.

We have some code that attempts to determine the size of a piece of text by calling DrawThemeText with the DT_CALCRECT format value.

According to this page (as of 9/30/2008) the DT_CALCRECT option determines the width and height of the display rectangle.

Unfortunately the DT_CALCRECT option doesn’t actually return the width and height of the display rectangle. Instead it doesn’t modify the input LPRECT field. I asked the developer and he indicated that the reason was that the pRect parameter to DrawThemeText is actually defined as a LPCRECT and thus the implicit contract for the API is that it doesn’t change the contents of the pRect field.

There are two ways of working around this problem. The first (and recommended) way is to call GetThemeTextExtent to retrieve the dimensions of the rectangle. The second (which works on Vista and later operating systems) is to call DrawThemeTextEx passing in the DTT_CALCRECT flag – in that case the DrawThemeTextEx API will return the size of the text in the pRect parameter.

I’ve sent emails to the SDK folks so it’s entirely likely that the page will be updated in the future but until it is, hopefully this will help someone using the search engines to find what’s going on.

Why specify SND_NODEFAULT when calling PlaySound?

LarryOsterman — Fri, 26 Sep 2008 00:46:34 GMT

Because the alternative is often much worse.

Several months ago, I got a bug report that if you launched mmsys.cpl then set the “Select” sound to a value, then cleared the sound, the reporters application would ding whenever you moved around their tree control.

I dug into the problem a bit and discovered that the problem was actually in the Windows common controls. Under some circumstances the common controls would call PlaySound specifying a sound alias and the SND_ASYNC and SND_ALIAS flags only.

The problem with this is that if you specify SND_ALIAS without also specifying SND_NODEFAULT, the PlaySound API decides that you really want the sound to be played and it will play the default “ding” sound instead.

From the PlaySound API’s point of view this makes sense. After all, you asked the API to play a sound, it doesn’t know that you meant “only play this sound when the sound file represented by the alias exists”.

In fact, that’s the entire reason for the SND_NODEFAULT flag – it lets the PlaySound API that you only want to play a sound when the sound has been defined.

Why call PlaySound(NULL, NULL, SND_NODEFAULT)?

LarryOsterman — Tue, 16 Sep 2008 03:18:17 GMT

Someone just wandered over to my office and he had noticed the following pattern in his code:

PlaySound(NULL, NULL, SND_NODEFAULT);
PlaySound(".Default", NULL, SND_SYSTEM | SND_ASYNC | SND_NODEFAULT);

He was wondering why on earth the code would do that call to PlaySound(NULL).

As I explained it to him, the reason is because you almost always want to cancel the current sound playing before you queue up the next sound.

The problem is that the current implementation[1] of PlaySound(…, SND_ASYNC) simply queues the request to a worker thread which blocks waiting on the currently playing sound to complete. So if you have a situation where you call PlaySound(…, SND_ASYNC) many times in succession, you’ll find that all the calls to PlaySound pile up behind each other, which means that you might end up playing sounds long after the action associated with the sound has completed.

Of course you might want this behavior – it’s certainly possible to string lots of system sounds together to produce any number of interesting effects.

But most of the time you just want to stop the current sound before you start playing the next.

[1] There are obviously no guarantees that the implementation of PlaySound won’t change – I’m just describing what the current code does. Even if the implementation is changed, it won’t change the underlying behavior.

Anatomy of a Heisenbug

LarryOsterman — Wed, 03 Sep 2008 20:43:12 GMT

I just spent a half an hour debugging a heisenbug and thought I’d pass on what was happening.

I was running my unit tests for one of my features and they were reliably failing. Unfortunately the instant I ran the test case under the debugger, the problem went away. Problems that disappear under the debugger are a classic symptom of a heisenbug, this was no exception.

If I attached the debugger AFTER the test started but before the failure hit, I was able to see the failure occur. The problem only occurred when launching the app under the debugger. At that point I realized what was happening.

As MSDN says:

Processes that the debugger creates (also known as spawned processes) behave slightly differently than processes that the debugger does not create.

Instead of using the standard heap API, processes that the debugger creates use a special debug heap. On Microsoft Windows XP and later versions of Windows, you can force a spawned process to use the standard heap instead of the debug heap by using the _NO_DEBUG_HEAP environment variable or the -hd command-line option.

It turns out that I had added a member variable to a class and failed to initialize it in the constructor of the class. When launched under the debugger, the debug heap initializes all allocated memory to a known value. That means that when launched under the debugger the member variable had that known value, when launched without the debugger it was uninitialized and happened to have the value of 0. For a number of reasons, this value caused the test to fail.

I hate heisenbugs, but I like it when they’re really easy to find like this one.

Gotchas associated with using WM_PRINTCLIENT…

LarryOsterman — Thu, 28 Aug 2008 19:47:17 GMT

Yesterday I mentioned WM_PRINTCLIENT and how awesome it is when trying to strictly control the drawing of your application.

Part of the reason it took over a week to change the drawing model is that there are a number of serious gotcha’s associated with using WM_PRINTCLIENT and controlling your own drawing story. The first is that not all controls support WM_PRINTCLIENT. It turns out that some controls don’t support the WM_PRINTCLIENT, however if you search the documentation for WM_PAINT, you’ll find the following comment:

“For some common controls, the default WM_PAINT message processing checks the wParam parameter. If wParam is non-NULL, the control assumes that the value is an HDC and paints using that device context.”

That means that if you find a common control that doesn’t support WM_PRINTCLIENT, you can use WM_PAINT specifying wParam as the HDC[1]. Fortunately I didn’t run into this in my control.

The next gotcha is that some controls (like buttons and toolbars etc) have animations that are launched when you mouse over the control. These are often subtle (like the glow when you hover over a scrollbar thumb). In order to continue to have these effects work, you need to let those controls paint themselves – in my experience it generally didn’t cause much of a problem with flickering, but your mileage might vary.

The last gotcha is a very big one and hung me up for about half a day. The WM_PRINTCLIENT message only paints the client area of a window. If you have a window with the WM_HSCROLL or WM_VSCROLL style then you won’t be able to paint the scroll bar. Instead you need to create your own scrollbar control (with CreateWindow) and use that instead of the built-in scroll styles. There are ways you can convince the window to paint it’s non client region to an HDC but they are fraught with peril (one senior developer I was talking to about this problem described them as “unnatural acts”) and simply not worth the effort.

[1] There’s also a corollary to that: If you ever send a WM_PAINT to a control you MUST ensure that wParam and lParam are 0 even though they’re documented as “not used”.

Larry’s new favorite windows message – WM_PRINTCLIENT

LarryOsterman — Thu, 28 Aug 2008 03:51:25 GMT

As I’ve mentioned before, I’ve been fuddling around doing UI programming recently – it’s a bit different from my usual work deep in the bowels of the <insert whatever subsystem Larry happens to be working on (redirector, audio stack, POP3 server, whatever)>.

I’ve been having a great deal of fun doing the whole “UI programmer” thingy (although my grandboss is right – once you start doing UI, everyone thinks that you’ve done it wrong) recently, and I’ve learned a ton of stuff.

Most of the UI I work with is written as dialog box applications – for various reasons, many of the audio UI elements are actually dialog boxes[1]. As such, the system controls the actual drawing of the UI elements, especially if you specify the WS_CLIPCHILDREN window style.

I recently had a bug where one of the UI elements wasn’t being painted correctly. For a number of reasons, the element was being overwritten by another element.

It took a lot of work to get to the scenario where the UI element got messed up, so I was going to ignore the problem (it was ugly but transient). But then I got to browsing the web and I ran into this article. The article had nothing to do with the order of painting in a dialog, but it DID mention a windows message that I hadn’t heard of before, WM_PRINTCLIENT.

Hmm, that’s interesting. WM_PRINTCLIENT says “The WM_PRINTCLIENT message is sent to a window to request that it draw its client area in the specified device context, most commonly in a printer device context.”. Ooh, that’s interesting. If I can just send a WM_PRINTCLIENT to each of the controls in the window, maybe I can control the order in which the controls are rendered, which would allow me to fix the problem (and remove a long-standing issue with the program in question).

On Monday of last week, I came in and decided that I’d dedicate a couple of days to see if my idea might work – worst case I’d lose a couple of days of work, but if it did work it would be really cool.

By mid-afternoon on Monday, I had come to the point where I realized that my crazy idea would actually work.

Skip forward one very long week of debugging and tweaking and I had fixed the problem – I had rebuilt the painting algorithm for this application and it worked!

Right now I’m highly enamored of the WM_PRINTCLIENT message simply because it’s so darned useful in scenarios like mine.

PS: It’s possible that I might be able to achieve similar results with the WS_EX_COMPOSITED window style but it’s not clear given some of the UI requirements for the application – I may play around with that idea over the next couple of weeks.

[1] One of the reasons for the apps being dialog box based is that it makes it easier for localizers if the application is built on dialog boxes because it gives the localizers greater flexibility when translating the OS – if the preferred text in the destination language doesn’t fit, they can adjust the layout of the dialog to make the text fit.

The SS_PATHELLIPSIS, SS_ENDELLIPSIS and SS_WORDELLIPSIS styles force static controls to disable word wrap.

LarryOsterman — Thu, 14 Aug 2008 21:08:00 GMT

I didn’t find this in the documentation for the static standard window so I figured I’d put it out in my blog in the hopes that someone else won’t get stuck on this problem.

The Windows “static” control has a number of styles that control how the control draws text. They can be extremely useful when controlling how the control lays out text.

I recently had to write code that draws the name of an audio endpoint into a relatively size constrained static text control. No problem, right[1]?

Speakers

Well what happens if the name of the endpoint is somewhat longer? No problem, the SS_CENTER style will wrap the words.

Headset Microphone

But sometimes the endpoint name is longer than “Headset Microphone”. In fact the user can set the endpoint name to anything they want.

Long Headset M

Uck, that looks ugly.

Fortunately the static control has an option SS_WORDELLIPSIS that looks like it should be perfect for me:

“Windows NT or later: Truncates any word that does not fit in the rectangle and adds ellipses.”

That sounds exactly like what I want. But when I added SS_WORDELLIPSIS, I got:

Long He...

Hold on, that’s not right, what happened to the rest of my text?

After a bit of digging, I finally figured out what was going on (by trial an error removing all the various static control styles I specified).

It turns out that this behavior is by design, even though I couldn’t find any documentation of it. If you specify any of the ellipsis styles for the static control, the control becomes a single line control. The only way I’ve found to fix this is to make the static control an owner draw control and use the DrawThemeText (or DrawText) API specifying the DT_WORDBREAK | DT_ENDELLIPSIS option.

I’ve filed a documentation bug to ensure that this gets fixed sometime in the near future.

[1] I’ve approximated what was going on in my UI with HTML tables, this is a rough approximation to show more-or-less what was going on.

ETA: Thanks to Drew and Lindseth for reviewing this.

Edit: Fixed word wrap in edit control.

What’s wrong with this code, Part 22 – the answers

LarryOsterman — Mon, 04 Aug 2008 23:32:32 GMT

The other day, I wrote about measuring the dimensions of a piece of text using the DrawText API.

My code worked just great when I initially tested it (obviously it’s a part of a larger chunk of code that does more complicated work). The problem showed up when I started testing it on a machine running in High DPI mode (144DPI).

The code in question measured some text and then used that text to set the size of a button, when working in low DPI mode (96DPI), the font that is chosen had font metrics that closely matched the font that was used when painting the button. The problem was that the button font that was used in high DPI mode had dramatically larger font metrics than the low DPI font.

As a result, the rectangle returned by the initial DrawText call didn’t match the rectangle that was used when the button was painted. That meant that the button text overflowed the button.

The fix to the code is to retrieve the font that is going to be used to draw the button and to use SelectObject to set the font in the memory DC to match the button font. Once I made that change, the button drew perfectly.

Here’s the corrected code (new code in red):

   HDC hdc = CreateCompatibleDC(NULL); 

   RECT rcText = {0, 0, 88, 34}; 

   HFONT hFont = reinterpret_cast<HFONT>(SendMessage(m_hWndControl, WM_GETFONT, 0, 0)); 
   HFONT hFontOld = reinterpret_cast<HFONT>(SelectObject(hdc, hFont)); 

   DrawText(hdc, L"My Text String", -1, &rcText, DT_CENTER | DT_END_ELLIPSIS | DT_EDITCONTROL | DT_WORDBREAK | DT_NOPREFIX | DT_CALCRECT); 

   CAtlString string; 
   string.Format(L"Text String occupies: %d x %d pixels", rcText.right - rcText.left, rcText.bottom - rcText.top); 
   MessageBox(hWnd, string, L"String Size", 0); 

   SelectObject(hdc, hFontOld); 
   DeleteDC(hdc);

And yeah, I’m sure this is old-hat to experienced Windows UI programmers, but it stumped me for several hours so I figured I’d write it up for the blog in case someone else hits the same problem.

Kudos and omissions:

Aaron Ballman caught that I forgot to call DeleteDC when I was done with using the DC. Stupid boneheaded mistake.

Shog9 and Ivo caught the root cause (selecting the wrong font).

And Eldan caught the Large Fonts implication. There are other ways of catching this, but HighDPI is the easiest.

I also agree with his assertion that font handling of GDI is “complicated”. On the other hand, the alternative is adding a dozen parameters to the DrawText API (you’d have to add foreground color, background color, font, etc to the call, which would complicate the API dramatically).

PS For those who care about such things: When I’m testing UI changes, I start with standard DPI, then I retest the changes in HighDPI and again using high contrast mode. Testing in high contrast mode also tests the code in a non themed mode, which helps to catch bugs where I accidentally depended on the theming logic.