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)
referenced by
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