by Michael S. Kaplan, published on 2005/10/12 03:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2005/10/12/479817.aspx
Remember back when I was going on in time zones and locations and keyboards about how we could use GEOID values for everything? And then Mihai helped me realize that GEOID support is not quite done?
Well, we were digging into things again and realized there are some more problems here.
Let's take a look at the prototype for GetGeoInfo:
GEOID GeoId, // location identifier
GEOTYPE GeoType, // type of information requested
LPTSTR lpGeoData, // buffer for results
int cchData, // size of buffer
LANGID language // language id
Now obviously the GeoId parameter is the GEOID you are querying about. That part is fine.
The language parameter is basically broken:
Now these latter two cases, if you pass 0 then it does not use the user default UI language (as GetUserDefaultUILanguage would return) -- it uses the user default langid (as GetUserDefaultLangId would return). In other words the default user locale. This is usually not noticed since actual resources are loaded with that FindResourceExW call, which I think might pick up the thread locale if that FindResourceEx text is accurate:
[in] Specifies the language of the resource. If this parameter is MAKELANGID(LANG_NEUTRAL, SUBLANG_NEUTRAL), the current language associated with the calling thread is used.
But we all know how I feel about the thread locale, don't we? :-)
Ok, we have one useless parameter and at least four useless SYSGEOTYPE values. I am going to go out on a limb and suggest that this is a good function to steer clear of, unless you are using one of the other SYSGEOTYPE values. And avoid the language parameter if you can....
This post brought to you by "ش" (U+0634, a.k.a. ARABIC LETTER SHEEN)
# Nick Lamb on 12 Oct 2005 6:39 AM:
# Michael S. Kaplan on 12 Oct 2005 6:43 AM:
go to newer or older post, or back to index or month or day