Getting a list of locales in the Compact Framework

No idea why the CF omitted the GetCultures method.  The info it returns is clearly supported in the OS, and it’s not like it’s a lot of work (plus if you’re doing globalization, it really is helpful.

Here’s a quick implementation I put together this morning that we’ll likely add to the SDF:

using System;
using System.Collections.Generic;
using System.Globalization;
using System.Runtime.InteropServices;

namespace OpenNETCF.Globalization
  public class CultureInfoHelper
    private delegate int EnumLocalesHandler(string lpLocaleString);
    private static EnumLocalesHandler m_localesDelegate;
    private static List<CultureInfo> m_cultures;

    private static int EnumLocalesProc(string locale)
        int.Parse(locale, NumberStyles.HexNumber)));
        // failed for this locale – ignore and continue

      return 1;

    public static CultureInfo[] GetCultures()
      if (m_localesDelegate == null)
        m_cultures = new List<CultureInfo>();
        m_localesDelegate = new EnumLocalesHandler(EnumLocalesProc);
        IntPtr fnPtr = Marshal.GetFunctionPointerForDelegate(
        int success = EnumSystemLocales(fnPtr, LCID_INSTALLED);

      return m_cultures.ToArray();

    private const int LCID_INSTALLED = 0x01;
    private const int LCID_SUPPORTED = 0x02;

    [DllImport(“coredll”, SetLastError = true)]
    private static extern int EnumSystemLocales(
    IntPtr lpLocaleEnumProc, uint dwFlags);

4 thoughts on “Getting a list of locales in the Compact Framework”

  1. Hy Ctacke
    I would be so cool if you guys finally begin to comply to the coding standards broadly used in the C# domain such as Phillips Coding Guidelines or even better Microsoft Coding Guidelines. I can really recommend the StyleCop Plugin for Visual Studio or if you have resharper the style cop plugin for resharper. This would make your code much more easier to read 😉

    For example prefixing local fields with m_ is way out of history 😉

    I don’t want to offend you



  2. There is nothing wrong with the m_ prefix! 😦
    It helps get around the ctor param naming issues without resorting to: this.

    True that Resharper would catch this for you though.


  3. Hello Quarrelsome
    It’s not that prefixing is completly wrong in a common sense, but for example if you’re using StyleCop then I would be a style cop rule validation. See SA1308 (Validates that the name of a member variable does not begin with the ‘m_’ syntax.)

    A violation of this rule occurs when a field name is prefixed by m_ or s_.

    By default, StyleCop disallows the use of underscores, m_, etc., to mark local class fields, in favor of the ‘this.’ prefix. The advantage of using ‘this.’ is that it applies equally to all element types including methods, properties, etc., and not just fields, making all calls to class members instantly recognizable, regardless of which editor is being used to view the code. Another advantage is that it creates a quick, recognizable differentiation between instance members and static members, which will not be prefixed.

    Regards Daniel


  4. I’ve been using m_ prefixing for a long time, and honstly I have no plan to change that. Unlike most hungarian notation, which I agree is passe, it adds value. It tells me at a glance that it’s a member field of the class and not a local variable in the method. It’s an important distinction, and until Studio does something like coloring them in some way that gives me the same visual cue, the prefixes will remain. I don’t see how removing it would make things easier to read – in fact I’d posit that removing them makes it *harder* to read.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s