A picture that can't be easily described with words

by Michael S. Kaplan, published on 2007/04/19 05:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2007/04/19/2185812.aspx

If only you could include screen shots in Microsoft Knowledge Base articles.

I mean, could you imagine being in Product Support and trying to write up the text description for the following for a KB article?

Actually, a customer named Pavel had the same problem trying to describe the above when trying to find out about the situation in s newsgroup posting from a month or two ago.

After I expressed some confusion about the description, he finally put up a screen shot and we started digging....

It was not too long before we had a repro -- only on some machines, there was no indication yet as to the cause.

Of course here we have access to checked builds; it turns out that just before this bug comes up, two asserts with huge callstacks come up -- they look something like this:

Wow, now that is disturbing.

But that assert gives just the hint that was needed -- if you look at the item third from the bottom, we are actually near the end of the main form's InitializeComponent call -- this is the method that Visual Studio puts in that does all the grunt work of creating all of the controls and setting all of the properties of the form.

It seems there is a specific case where the Resize event is being called long before any of the code in MSKLC runs -- like before the code initializes the "start size" of a bunch of controls. So those values are zero and when calculating the ratio between the new size and the original one, we divide by zero (since the uninitialized value is zero).

Further digging, and we found that this only occurs with certain DPI values (120dpi or thereabouts), and only when the "XP compatible" mode is specified for the DPI.

In fact, if you make sure not to click the "Disable display scaling on high DPI settings" for MSKLC or a shortcut to it (on the Compatibility tab):

And then you can also avoid the problem too.

As to why this event is being called prematurely (yes, technically resizing happens in InitializeComponent but this code has been around since 2001 without ever hitting this problem before so it appears to be legitimate regression either in Vista or in WinForms in a set of circumstances narrow enough to mean that most people will never see the problem!), who knows?

That will be followed up on in due course -- it might even make a KB article at some point, since it is much easier to put into words.

Anyway, once you make sure you aren't using the XP compatible setting for MSKLC, everything looks good even on a machine that repros the problem:

But I am suddenly really not liking DPI settings for some reason. :-(

Anyway, with a whole bunch of workarounds available (and the relative paucity of reports -- just one so far! -- of the bug despite the huge number of MSKLC downloads), an immediate fix is presumably a hard sell. Especially since the real bug is in an event that is firing long before it is ever supposed to in a circumstance it is not documented as being supposed to fire.

But even if it isn't going to be fixed until a future version of MSKLC or WinForms or whatever, it seemed worth a blog post, if only to show off that cool "keyboardless" MSKLC screen shot:

It isn't like the KB could do much without adding screen shot support. :-)


This post brought to you by (U+3243, a.k.a. PARENTHESIZED IDEOGRAPH REACH)

# dmurillo on 19 Apr 2007 3:46 PM:

Hi Michael,

Oh... just this week we had this same kind of behaviour but in VB6 with Windows XP SP2!

It's not the first time I've seen it, but it was a repeat of a similar problem that we first saw last year.

We've introduced a new VB6 ActiveX control that did some processing in the "UserControl_Resize" event and got this kind of behaviour because the event got triggered twice, the first time being before some variables were initialized.  But this event was only triggered if the Large Fonts option was set in the Advanced options of the Display Settings.

I always thought that this was specific to VB6, I guess not! :-)

Have a nice day!


# Serge K on 11 May 2007 11:55 PM:

Hi Michael,

I have the same issue with MSKLC on a notebook (Windows XP SP2).

The display DPI setting is at 150% (144 dpi) - in order to make 15" 1920×1200 screen usable.

Never thought seriously about reporting this bug - because of doubts that anyone cares.

But now I have 22" 3840×2400 monitor connected to my desktop PC...

# Roland Fumey on 9 Apr 2008 9:05 PM:

I have exactly that problem of a "keyboardless" MSKLC screen in Windows XP SP2, with a display setting of 120 DPI (125%).

Unfortunately it does not seem to be possible to change anything about "Disable display scaling on high DPI settings" in the Compatibility tab.

Is there any way to overcome this problem?


# Michael S. Kaplan on 10 Apr 2008 2:19 AM:

There is no setting in XP -- you have to lower the DPI to work around the bug.

# Roland Fumey on 11 Apr 2008 1:34 AM:

Thanks! I thought so.

It would be a great help if this problem could be overcome some time as more and more people will probably have high resolution screens, where they normally have a greater than 100% DPI setting.

Anyway, thank you very much for MSKLC!

# Michael S. Kaplan on 11 Apr 2008 2:30 AM:

It is on the list of things to fix in a future version, so I assume that it will evenually be fixed. I'll forward this conversation on to the owners so that they know about it....

# Konstantin P on 12 May 2008 9:41 PM:

I just installed MKLC 1.4 on a Vista Business machine. I have desktop compositing and high DPI enabled. The "Disable display scaling on high DPI settings" box on the executable's Compatibility Settings tab is *unchecked* (as instructed). However, the layout still appears invisible.

# Michael S. Kaplan on 12 May 2008 9:47 PM:

You might still have the main setting for DPI in that XP mode -- it is not just the shortcut (which does per app behavior), the overall setting also has a say here....

Konstantin P on 14 May 2008 11:36 PM:

"the overall setting also has a say here...."

Ah, but turning that off would make all non-high-DPI-aware apps too blurry for comfort. Guess I'll just wait for the next version of the layout creator.

Michael S. Kaplan on 14 May 2008 11:56 PM:

I don't have an ETA on that one though. Sorry. :-(

Vlado Jamnicky on 15 Nov 2008 8:59 PM:

MSKLC 1.4 gives me same grey screen with XP (MediaCenter Edition, version 2002, SP3). In Properties selecting 96 or 120 DPI made no difference.

Vlado Jamnicky on 16 Nov 2008 8:34 AM:

Re my comment yesterday: Today I tried again (reducing DPI) and this time it worked, so thanks awfully for the tip. No idea why Ii failed yesterday. Cheers.

Michael S. Kaplan on 16 Nov 2008 10:28 AM:

Have you logged off or rebooted in the interim? Glad you are working again, at least!

referenced by

2015/05/21 No words seem to make the picture any clearer

2010/06/24 A picture that *still* can't be easily described with words

go to newer or older post, or back to index or month or day