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…
Paweł
9 gru 09 at 11:57
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ł
7of9
9 gru 09 at 22:29
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ą).
Paweł
10 gru 09 at 10:20
Trzeba się zatem logować na Connecta i głosować jako ważne.
7of9
10 gru 09 at 20:13
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.
Bartek Szafko
11 gru 09 at 08:33
mi też rozwiązanie z OnStartup wydaje się najsensowniejsze