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:

int 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:

  • The two times it would be theoretically useful (the GEO_FRIENDLYNAME and GEO_OFFICIALNAME SYSGEOTYPE values), it is not used;  instead, the strings are loaded using FindResourceExW with a 0 in the wLanguage parameter.
  • One of the times it actually is used is when you are passing GEO_RFC1766, and it is actually used to try and build an RFC1766 code based on the ISO-639 code of that LANGID and the ISO-3166 code of the GEOID. In other words, don't pass a GEOID and LANGID that do not match!
  • The other time it is actually used is when you are passing GEO_LCID. It will then treat it as an LCID and work to try to return that LCID if it is associated with the given GEOID in some way. So once again, not-matching parameters would not make too much sense.

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:

wLanguage

[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)