How whining a whole bunch got a feature added

by Michael S. Kaplan, published on 2005/04/03 02:05 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2005/04/03/404931.aspx

Sometimes I am a real pain in the you-know-what.

You can ask people on my team, they will probably agree.

In fact, if any of them are reading I will not hold it against them if they wanted to verify this point. :-)

Anyway, I was going to tell you a story here, about how whining got a feature added. It is mostly from memory, though I did dig up my old newsgroup post from my archives....

A few years ago (back in November of 2000), I believe a little while before the original 1.0 version of the .NET Framework shipped, a problem came up that I was involved with.

You see, a customer had been using the System.Globalization namespace's HijriCalendar class on a machine that had Arabic - Saudi Arabia as its default user locale and Hijri was his Windows calendar choice (meaning that its CurrentCulture was ar-SA and that HijriCalendar was his CultureInfo object's Calendar). He noticed that when he changed the "day advance" setting of the Hijri calendar in Regional Options, applications like Outlook and Word had no problem picking up the change instantly. Yet his managed application had to be shut down and restarted to pick up the change. Wanting to figure out why, he sent me a piece of mail asking me about it.

Now I was working for the NLS team at the time (I believe this was before we were really GIFT, and Julie was a dev. lead who I reported to directly rather than indirectly through two other people). I was working on the Microsoft Layer for Unicode. I felt kind of weird about going to people on the team during working hours and trying to get special treatment for bugs that had nothing to do with what I was being paid to do there, so after asking this guy for permission I posted the issue in the C# newsgroup (microsoft.public.dotnet.csharp.general):

Attn: to someone at Microsoft? :-)

BACKGROUND: The Hijri calendar is a 100% lunar calendar that in addition all of its rules, requires a religious authority to spot the new moon for the month to start. Clearly, no algorithm can ever determine this with 100% accuracy, which is why WINDOWS supports (in the control panel) a way to offset the date based on that sighting. This is support by all Arabic localized and enabled versions of Windows, and all language versions of Windows 2000 and Whistler.

Applets such as the Windows date on the system tray and application such as Outlook support it.

However, the Hijri date support that was in COM and is in the CLR, and the HijriCalendar class does not support getting this offsert value. In addition, unless I do not have my druthers about me, HijriCalendar does not support it either.

You can confirm with people such as Assem Hijazi that this is important; Hijri dates need to respect this small bow to the fact that you cannot algorthmically determine the proclamations of religious authorities. Hijri dates need to adjust for this reg. key and ideally you should be able to at least GET (if not SET) this parameter.

If the CLR's System.Globalization class is the next iteration of Windows NLS support, then its time to support the things that have been missing to programming languages since VS first shipped. :-)

If anyone needs more info on how this info is stored in the registry, let me know.

The developer who owned the feature (who is actually now my manager and who has hopefully forgiven me for how I did all this!) came by to ask me about the message. It was all a little embarassing since he did not really understand why I would feel uncomfortable, but he let that pass after I explained (or maybe he just thought I was being weird, which I guess I was).

Then, after I explained how this all came about, he explained to me why it was actually a really hard bug to fix (he was aware of the fact that I had never even seen the source code that point). Those other applications "respected" the settings change by listening for the WM_SETTINGCHANGE message that Regional Options sends. But the .NET Framework had no message loop to listen for this message, and thus no way to really respond to it. A developer could create a brand new CultureInfo object to pick up the change, but any existing object would not get it, and there was no way to reset a CultureInfo, especially CurrentCulture.

At this point, I got really stubborn. I told him how crucial this functionality was. And it was not just about the Hijri calendar stuff; any update in Regional Options would not be picked up. Even though the very common end user pattern here is to notice that a setting is wrong while she is in an application, to fix the incorrect setting in Regional Options, and then go back to the application and see the update. I had written applications myself that do this, and like I said all of the big applications like Outlook handled things correctly. It would really make the .NET Framework look bad if nothing were done to improve the situation, since there was really no good remedy for the problem. Doing nothing would mean no way to even get parity with Window 95!

But my future boss was really worried about the cost of trying to add such a feature so late in the game. And he is right, that is a very real concern.

At the time, though, I was external enough to the .NET Framework team that I was not really looking at it that way (remember that I was not being paid to do anything in .NET at all; I was focused on just the user scenario). So I kept pushing. I pointed out how COM had actually fixed this bug in their own code, so much so that in the Windows 95/98/NT 4.0 days they created a hidden window (class name of "OLEAUT32") to listen for the message (in Windows Me and beyond they started listening for it as a thread message instead). Now this would be a big change, yes. But if not that, I asked, couldn't something be done to help here?

I finally pointed out one thing -- the way the code was now, even if I were developing a WinForms application and I actually received the WM_SETTINGCHANGE message, I would be powerless to do anything about it!

I swear I saw the lightbulb light up on top of his head when I said that. He said he would think about what I was saying and excused himself.

(anticipating a question some might have, I did not bill for the time that I was talking to him about the problem!)

And very soon after that he added the ClearCachedData method. So that any time a developer listened for and subsequently heard the WM_SETTINGCHANGE message, she could reset the object and pick up the change. And a WinForms application could have parity with a Win32 one (note that even on Win32 you would have to write code to listen for the message, so true parity was really accomplished since a developer could in either case choose to not update if they did not want to).

So, that's the story of how whining got ClearCachedData added. :-)

Just this last March in an article I wrote for MSDN Magazine, I gave the sample code you could use to accomplish all that in a WinForms application....

But lest you think that you, as a developer using the .NET Framework who runs into a problem, would not have the the same ability to whine and get changes made or bugs fixed or suggestions heard, use that link I have that points to the MSDN Product Feedback Center. Microsoft developers, testers, and program managers see the feedback and bugs posted there directly in the bug database, and they take the feedback seriously. If you look at some of the issues that have been fixed after beging reported there, you will know that you have same kind of direct access to the people who can solve the problems, whether they are international or not (I myself have fixed two bugs reported on the site for Whidbey RTM: String comparison (and sorting) for sr-SP-Latn (Serbian) culture is incorrect and CompareInfo.Name is incorrect for zh-CN and ka-GE alternative sort orders, and a ton of other bugs and suggestions have been posted there, across all aspects of the .NET Framework!).

Or you could always post the info here in Sorting It All Out, or on the BCL Team's, Achim Ruopp's, or Brad Abrams's blog. The advantage to one of our blogs is that you may get someone to post about it; the advantage to posting to the MSDN Product Feedback Center is that you get to track the issue and have people vote on it. And voting is something that can in some cases make all the difference in the world if you have either (a) a lot of people who agree with you or (b) a lot of developer friends you can bribe with Twinkies or beer!

This post brought to you by "۾" (U+06fe, ARABIC SIGN SINDHI POSTPOSITION MEN)

referenced by

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