SetLocaleInfo really stinks

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


Yes, I said it. The SetLocaleInfo function, which has been around since NT 3.1, really stinks.

Why would I be so disparaging about an API that has been around so long?

Well, I'll start on the outside and work concentrically in....

First of all, it is an enabler. In a world where it's all about making sure developers respect the user's preferences, anyone who wants to change those preference settings is really out of step on the whole respect issue. And a function whose main purpose in life is to enable that user to make such a change is essentially an enabler encouraging the bad behavior.

(Of course there are exceptions to this, as sometimes an application is basing the change on user feedback. So maybe it is not gun's fault if someone shoots another person. If that person aimed the gun and fired it at someone intentionally, then it if the fault of the person. But the gun still enabled the crime to happen. It could be made safer, at least!)

Alright, let's ignore that one for a moment. It also stinks because of the way the documentation is laid out. It lists 32 LOCALE_* LCTypes that it can affect:

LOCALE_ICALENDARTYPE
LOCALE_ICURRDIGITS
LOCALE_ICURRENCY
LOCALE_IDIGITS
LOCALE_IDIGITSUBSTITUTION
LOCALE_IFIRSTDAYOFWEEK
LOCALE_IFIRSTWEEKOFYEAR
LOCALE_ILZERO
LOCALE_IMEASURE
LOCALE_INEGCURR
LOCALE_INEGNUMBER
LOCALE_IPAPERSIZE
LOCALE_ITIME
LOCALE_S1159
LOCALE_S2359
LOCALE_SCURRENCY
LOCALE_SDATE
LOCALE_SDECIMAL
LOCALE_SGROUPING
LOCALE_SLIST
LOCALE_SLONGDATE
LOCALE_SMONDECIMALSEP
LOCALE_SMONGROUPING
LOCALE_SMONTHOUSANDSEP
LOCALE_SNATIVEDIGITS
LOCALE_SNEGATIVESIGN
LOCALE_SPOSITIVESIGN
LOCALE_SSHORTDATE
LOCALE_STHOUSAND
LOCALE_STIME
LOCALE_STIMEFORMAT
LOCALE_SYEARMONTH

And then it jumps to the full list of all of the LCTypes under the heading of Locale Information. What is that about, a tease? And wouldn't you expect more customized information about the setting of this info then would be provided in the getting of it?

Ok, let's ignore that too and look at the LCTypes. Thirteen of them are numbers, but you still have to pass the parameter as a string. There is a LOCALE_RETURN_NUMBER flag you can use in GetLocaleInfo to return this field as a number. So where is the LOCALE_SPECIFY_NUMBER flag? Don't bother looking, it's not there.

Let's ignore that one too and look at the LCID parameter. The API validates that it is an actual LCID (so you cannot pass some random invalid number). But then after verifying that is normal, it proceeds to ignore the value and sets the values for the current user default locale, the only locale that persists the user overrides. So what was the reason for including the LCID if it was not going to use it? Because the function stinks, that is why.

Now how many APIs do you know that encourage inappropriate application behavior, do not get documented conveniently/completely, force the caller to make needless conversions, validate parameters that they do not even use, and then only work with the user default, that don't stink? Not many, I would wager. It is pretty hard to ignore the smell of unrefrigerated fish that this function exudes, if you know what I mean.

As the man says, Please don't use SetLocaleInfo. It is a bad, bad, function.

 

This post brought to you by "ק" (U+05e7, a.k.a. HEBREW LETTER QOF)
Because this post is קשר לפסח in anticipation of the festivities that start less than 24 hours from now)


no comments

referenced by

2008/07/10 What's the sharp and nasty, smooth and greasy, barbed and two-pronged f***ing point of SetCalendarInfo?

2007/10/18 LocalSystem is people, too!

2006/05/21 SetLocaleInfo works without notification

2006/04/28 DEFAULT_GUI_FONT really stinks

2005/08/22 Why I think the thread locale really stinks

2005/05/29 Pass the string, please

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