none
[UWP]Thousands Separator. Cannot get the DecimalFormatter functions FormatDouble(), ... to respnd to changes in language tag. How? RRS feed

  • Question

  • Snippet of example:

    double number = 12345678.87654;
    DecimalFormatter formatter;
    formatter.IsGrouped(true);
    formatter.SignificantDigits(3);
    wchar_t localeNameResolved[LOCALE_NAME_MAX_LENGTH];
    wchar_t tempWCHAR_T[50];
    ResolveLocaleName(Language::CurrentInputMethodLanguageTag().data(), localeNameResolved, LOCALE_NAME_MAX_LENGTH);
    wsetlocale(LC_ALL, localeNameResolved);
    hstring str = formatter.FormatDouble(number);


    This does not respond to a change in language tag when called in a click handler for me.

    While using _snwprintf_s the decimal point does change appropriately though there are no provisions for that function of a format specifier for a thousands separator that I know of.

    _snwprintf_s(tempWCHAR_T, 50, 49, L" % lf", number);  (GOOD, though no thousands separator)

    (localeconv()->_W_decimal_point) and (localeconv()->_W_thousands_sep) respond appropriately, though no thousands separator is returned for the language tag  fr-CA   . 

    I need the thousands separator for that locale and prefer that these types of values are obtained programmatically to allow the operating system to help provide the most current values. "
    I wonder if the case is that localeconv() is not a recommended function for a UWP. Hence, I would prefer to use DecimalFormatter.

    The Project Type is a Visual Studios 2019 C++ WinRT - Xaml UWP Blank App with no predefined layout. The Version of WinRT is Version 2.

    (I wrote a complete UWP that is specifically designed for evaluation of the problem: while changing the language tag using the WINDOWS - SPACE key combination and then clicking on a "button" to print the numerical results to a text box, the application displays the current language tag, displays the number using the various methods indicated above, and displays the Decimal Point and Thousands Separator associated with the method, though this post does not take a completed project solution. If there is a need of this, it is complete and available.)



    Saturday, September 21, 2019 3:31 AM

Answers

  • Hi,

    You can pass the language as a parameter when you initialize DecimalFormatter. Take "fr-FR" as an example below.

     

    double number = 12345678.87654;
    std::vector<hstring> languages{ L"fr-FR" };
    DecimalFormatter formatter = DecimalFormatter(languages, L"ZZ");
    formatter.IsGrouped(true);
    formatter.SignificantDigits(3);
    hstring str = formatter.FormatDouble(number);

     

    Best Regards,

    Fay


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Monday, September 23, 2019 7:13 AM

All replies

  • Hi,

    You can pass the language as a parameter when you initialize DecimalFormatter. Take "fr-FR" as an example below.

     

    double number = 12345678.87654;
    std::vector<hstring> languages{ L"fr-FR" };
    DecimalFormatter formatter = DecimalFormatter(languages, L"ZZ");
    formatter.IsGrouped(true);
    formatter.SignificantDigits(3);
    hstring str = formatter.FormatDouble(number);

     

    Best Regards,

    Fay


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Monday, September 23, 2019 7:13 AM
  • Your solution works for me completely. Thank you.

    There are other problems. Though it works completely in my target application, in the "tester application" the significant digits of the decimal point does not respond. I need to and am going to mark the answer as answered, though there are other issues as well. 

    The code that I am using is: 

    std::vector<hstring>languages{hstring(localeNameResolved) };

                 

    DecimalFormatter formatter = DecimalFormatter(languages, GeographicRegion::GeographicRegion().CodeThreeDigit()); 

    It looks like the parameter L"ZZ" is a default parameter for Geographic Region, and I tried searching the application including external files to locate the definition and was unsuccessful. I don't know how to reference that information. 

    Also, which is the most recommended value?? :

    L"ZZ" 

    GeographicRegion::GeographicRegion().CodeTwoTetter()

    GeographicRegion::GeographicRegion().CodeThreeLetter()

    GeographicRegion::GeographicRegion().Code()

    ******************************************************************************************

    Another greater issue that arises is that when taking the numerical output of FormatDouble(number): 

    hstring str = formatter.FormatDouble(number); and copying the output off of the application and using the value in code, is that the decimal point is lost. The function wcstod will take all Arabic, all Western, or a mix of Arabic and Western numerals together surprising, though universality terminates reading upon the Arabic decimal point returned by  FormatDouble(number) regardless of the language tag used to set the locale and geographic region. I rely on the use of wcstod to read data because it will stop and return a pointer to the character that terminated and this allows the convenience of multiple inputs. I also need the use of decimal points.  When I write a number, it may be to a file, and later I may need to read it from the file. (It appears that when I read from a file I will need to use a function from the Globalization file instead of wcstod.) I expect that when the native Arabic decimal point is typed from the keyboard into the text box of a running application that the wcstod read fails at the use of the native decimal point. I don't know if there is a Geographic initialization analog for wcstod. I assume that an error could be from wcstod becoming depreciated, though is has been updated to read Arabic. Could there be a problem with one or the other not being updated consistently in decimal point identification? Is it likely that wcstod is not going to be updated? Is there a Globalization  method that will read the numbers and various decimal points and return the character that terminates the read? 

    When coding, both work for numbers universally, though not for the decimal point: 

    double number = wcstod(L"912345.77889", nullptr);

    double number = wcstod(L" ٩١٢٬٣٤٥٫٧٧٨٨٩", nullptr);


    Again, thank you fully for the previous successful answer.


    Wednesday, September 25, 2019 12:20 AM