The problem with maximizing the minimizing issues (by which I mean minimizing the maximizing ones)

by Michael S. Kaplan, published on 2010/05/17 07:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2010/05/17/10013731.aspx

So, where do I start?

Oh yes, I remember.

The .Net Framework's first and in the minds of some still respectable to be using right now UI technology, WinForms.

Windows Forms.

There is a particular feature they have, an AutoSize feature. When used (and used properly) it tremendously lightens the burden on localization since it will resize forms and controls to fit the text they contain.

Note the  "used properly" notation there. This is important as I know of a project or two (or ten, or twenty!) that are part of a tiny little product you have never heard of called Windows that didn't really tend to do it right.

Which is not the end of the world. Not for you, or for me, or for the developers who created the forms, or for the localizers who had to do some resizing when text would truncate.

Everyone continued to function normally.

I guess the localizers had to work a little harder.

So no big deal right?

Right.

Oh wait, I forgot something.

Something about this AutoSize feature.

Now obviously a developer who was trying to use this feature might want to exert a little control over what it does, right?

I mean, letting people do stuff with no safety controls over how much they do leads to derivative market inspired economic collapse or unprecedented oil spills.

We know we don't want our WinForms to be all bankrupt and oily. So some ability to rein in the way that things might want to grow can make a little sense.

Of course the complexity of those ways to control the unprecedented growth is one of the big reasons why the AutoSize feature was so poorly utilized.

Why Windows became the son and heir to more than just a shyness that is criminally vulgar; it also inherited a whole bunch of oily, bankrupt WinForms applications.

The Smiths would be so disappointed.

But that is not the principal issue I wanted to discuss.

I really wanted to talk about the localization process, and then a couple of the properties that the original developers have to help rein in AutoSize if they believe they have a need to, and how all of that fits together.

The process, in a nutshell:

• Developer makes the form "Localizable" by setting the property of that name;
• Visual Studio creates a bunch of language-specific ResX files with all of the form/control size and other data;
• Localizers can resize the dialogs and controls as they put in the translated text and see what it will look like using WinRes;
• Windows ships those localized components with their localized product.

Easy, right?

Well, there was a problem or two.

Or more.

But for the moment I'll just talk about one or two of them.

Now one way that the developer can exert some control over the AutoSize beast is by use of the Control.MaximumSize and Control.MinimumSize properties.

These properties can be used to keep the difference between the original Control.Size and the eventual size from going way beyond what the developer ever really wanted.

That really does make sense (well, the Control.MaximumSize more than the Control.MinimumSize, but they both make at least some sense). And I would never want to imply otherwise.

Everything still looks okay, right?

Well, let me include the spanner in the works.

Those two properties? Control.MaximumSize and Control.MinimumSize?

They are not included in the localizable .ResX.

This leads to three specific problems:

• The dialog that the localizer sees in WinRes may or may not match the actual dialog's layout, since there is another couple of properties affecting the Control.Size that WinRes knows nothing about. Before the localizer even touches the dialog or its controls, they may be looking at an inaccurate representation of the layout.

• Any time the localizer resizes a dialog or a control (a common occurrence due to the difficulty in implementing the AutoSize feature properly and the known fact that many target languages are, on the average, 30-40% bigger in terms of the amount of text), the localizer's resizing may be partially or fully ignored due to the Control.MaximumSize and/or Control.MinimumSize in the main form modifying the sizes at runtime, something that the localizer (using WinRes) never sees. Note that WinRes, also from .Net, does recognize the properties, so someone was thinking this scenario oughtta work!

Now the combination of these first two factors often leads (as you can perhaps imagine) to the kind of bug that goes back and forth several times between the localizer fixing the truncation bug and the tester reporting it with the kind of "the problem is fixed"/"no it isn't" kind of argument that so often can come from looking at two different things and thinking they are the same.  

• Even once the localizer finally gets wise to the underlying problems, the fact that the Control.MaximumSize and Control.MinimumSize properties are not exposed to them means that they cannot fix the bug except by perhaps unreasonably/unreadably truncating the text themselves to avoid the unreasonable/unreadable truncation that the code will do itself later.

Or make it a core bug -- perhaps only found after everything has been frozen and no one is willing to make changes.

Okay.

Fair enough.

Now with all that said, in the world of Visual Studio, this bug is not such a big deal.

I mean, from their point of view it is really quite unreasonable to even set Control.MaximumSize or Control.MinimumSize to a size that could break localization; in fact, one of the more senior people I talked to about this bug couldn't even see why anyone would set either property in a form meant to be localizable.

Of course I don't know of any other reason why one would set it, which means that someone was admitting to me that the property was a bad idea! But that can be a subject for another day... :-)

Now the WinForms people are not being arbitrary about this judgment; the bug, which has existed since the very initial 1.0 version of the .Net Framework and WinForms, has (I am told) never ever been reported by any other customer external or internal to Microsoft.

Just Windows.

Now to Windows it led to hundreds of bugs (and no, this is not an exaggeration; the actual number is even higher though the "even higher" part is due in part to other problems that I'll talk about in some future blog).

Pain in the butt bugs with all those back and forth problems and difficulty pinning the problems down. And so forth.

Windows actually shipped with many of these bugs only partially fixed or worked around.

And some of the worst of the offenders in the dialogs are known by name to people on the localization team, since they know how many bugs they can expect to have to deal with any time one of them is changed.

But reportedly no one else has ever complained about the problem. Ever.

So, okay.

Eventually there will be a fix for this problem, a fix that I guess no one outside of the internal Windows team even cares about, since no one else apparently ran into the problem.

And there will be a KB article describing it (I'll link to it once I find it exists). In case it turns out anyone wants it.

From a social engineering standpoint I wish I had the time, resources, and knowledge to study the factors that can cause a bug to so hugely impact multiple developers spread across teams and groups and divisions and even continents within one large product while never affecting any other project in the entire world.

I can't even try and fathom that one; in fact I get a headache just thinking about it....

John Cowan on 25 May 2010 9:48 AM:

Michael S. Kaplan on 25 May 2010 9:56 AM:

Mihai on 25 May 2010 11:55 AM:

Miral on 25 May 2010 4:31 PM:

Mihai on 27 May 2010 10:10 AM:

John Cowan on 26 Nov 2010 11:52 AM:

Michael S. Kaplan on 26 Nov 2010 11:59 AM:

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