WPF: DataBinding nie używa ustawień narodowych

Na ten problem natknąłem się całkiem przypadkiem. W xamlu napisałem coś takiego:

<TextBlock>
    <TextBlock.Text>
        <Binding Path="CurrentDate">
            <Binding.StringFormat><![CDATA[{0:dd MMMM yyyy}]]></Binding.StringFormat>
        </Binding>
    </TextBlock.Text>
</TextBlock>

W wyniku czegoś takiego można by się spodziewać, że pojawi się tekst ?8 grudnia 2009?. Nic bardziej mylnego pojawiło się ?8 December 2009?. Wynik całkiem zaskakujący ponieważ zarówno CurrentCulture jak i CurrentUICulture zawierały poprawne ustawienia dla pl-PL.

Okazuje się, że tak zachowuje się DataBinding w WPF-ie. Jedynym obejściem jest albo napisanie własnych implementacji IValueConverter, które zamiast przekazanego Culture używają CurrentUICulture, albo podanie przy wywołaniu convertera parametru ConverterCulture:

<TextBlock.Text>
    <Binding Path="CurrentDate" ConverterCulture="pl-PL">
        <Binding.StringFormat><![CDATA[{0:dd MMMM yyyy}]]></Binding.StringFormat>
    </Binding>
</TextBlock.Text>

Może ktoś zna bardziej globalen rozwiązanie tego problemu ? Tak żeby nie trzeba było określać ConverterCulture przy każdym Bindingu albo definiować własnego IValueConvertera?

Tagged , ,

5 thoughts on “WPF: DataBinding nie używa ustawień narodowych

  1. Paweł says:

    Jeśli ustawisz obiekt Language na obiekcie rodzicu np. Window to wydaje mi się, że wszystkie Bindingi wewnątrz będą już tego języka używać.

    Możesz też stworzyć swoją klasę Bindingu w której to z automatu podstawiasz konwerter i jej używać. Wtedy nie musisz o tym pamiętać, ale twój kod będzie wyglądał trochę inaczej/dziwniej gdy zamiast Binding masz CultureBinding.

    Pozdrawiam,
    Paweł

  2. 7of9 says:

    Niestety?
    https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=442569
    Tak jest i będzie, bo to zgodnie z planem (a przynajmniej tak to teraz tłumaczą).

  3. Paweł says:

    Trzeba się zatem logować na Connecta i głosować jako ważne.

  4. 7of9 says:

    Uważam, że mają rację w tym co zrobili, ale szkoda, że nie było tak od samego początku (tzn. także w xxx.Parse oraz xxx.ToString), bo już nie raz spotkałem się z aplikacjami rzucającymi FormatException przez to, że autor nie pomyślał o innych ustawieniach regionalnych.
    Wątpię, żeby to poprawili, bo ważniejsza dla nich jest kompatybilność wstecz (tak samo jak przy zabugowanych Int32Converter.IsValid itp.)
    Poza tym łatwym rozwiązaniem jest wrzucenie do App.OnStartup linii
    “FrameworkElement.LanguageProperty.OverrideMetadata(typeof(FrameworkElement), new FrameworkPropertyMetadata(XmlLanguage.GetLanguage(CultureInfo.CurrentCulture.IetfLanguageTag)));” tak jak napisał autor na stronce.

  5. mi też rozwiązanie z OnStartup wydaje się najsensowniejsze

Leave a Reply

Your email address will not be published. Required fields are marked *