I am binding a float property to my TextBox control. Thats working correct if I am using "en" as my language Preference.
Entering a number "1.123" is correctly parsed.
If I Switch mur culture to "de" nothing changes in the TextBox (and TextBlocks). Still everything is formatted with a ".".
Entering a number via the "Numeric" Keyboard of WinRT is using the "," as a seperator. But the Training Digits will not be part of the number after Focus lost (and the bound property is updated.
So "1,234" should be parsed internaly as "1.234". But ist converted to "1".
The app.xaml.cs contains some more initialisation for ensuring the culture is set to the right language. The allowed languages are ("en" and "de" (*,proj file.
The CultureInfo.CurrentCulture is correctly set to "de" if you break into debugger.
public App()
{
Windows.Globalization.ApplicationLanguages.PrimaryLanguageOverride = CultureInfo.CurrentCulture.Name;
CultureInfo.DefaultThreadCurrentCulture = CultureInfo.CurrentCulture;
CultureInfo.DefaultThreadCurrentUICulture = CultureInfo.CurrentCulture;
Setting PrimaryLanguageOverride, DefaultThreadCurrentCulture, and DefaultThreadCurrentUICulture in the Application constructor has no effect, since they only apply to new threads. However, your main UI thread has already been created an had its culture set by the time the constructor is entered.
To force a change to the existing UI thread, you'd have to set Thread.CurrentCulture as documented in CultureInfo.CurrentCulture; however, WinRT does not support the Thread class.
This leads to the question of why any manual cultural changes are required at all. The app should automatically pick up the user's Windows culture at startup or upon resuming from hibernation.
To get the InvariantCulture settings we can use,
"ApplicationLanguages.PrimaryLanguageOverride = CultureInfo.InvariantCulture.TwoLetterISOLanguageName;"
This worked for me.
Related
I'm working on an old project that supports Windows Forms.
This project contains some ResourceManager for the support of a few localizations. The idea is that you call ResourceManager["SomeResource"] instead of Resource.SomeResource and it returns you a localized string.
And these localized strings are used in the code of the initialization of the form. For example, you have Form1, and in Form1.Design.cs there is some code like this:
Label label1 = new Label();
label1.Text = ResourceManager["SomeResource"];
So the label will be created with an already localized string in the Text.
And we need to add the functionality of changing the UI language without reloading the Form.
We can just set the every Text property of every controls again. But it's a lot of code, the form contains a lot of controls.
We can call the Form.InitializeComponents(), this method will recreate all controls with new localized strings, but in some cases, it works slowly because it reloads some big data again.
Is there some other way to refresh all UI controls and get the new localized strings? Do Windows Forms support some mechanism like Binding in the WPF to create the "connection" between the Text properties and localized resources?
I think that you can achieve this by use of Invalidate() either on the form itself or on a container control that your other controls may be encompassed by.
I've just upgraded an old .NET 1.1 Winforms app that uses CSLA to .NET 4.0 and a later version of CSLA which supports the use of the INotifyPropertyChanged interface.
A large part of the reason for doing this is the databinding improves - e.g. being able to update on change when binding instead of when validating (tabbing off).
I have custom user control, NumberBox. Essentially it's just a textbox with a few properties such number type, decimal places etc.. I have exposed a public property of type object called BindableValue. It was this property that I was binding my CSLA classes (standard .NET classes inheriting validation rules, property changed and various stuff) integer property to, in this particular case it the class property is integer.
My problem having upgraded are the following:
If I enter a value, e.g. 1234, into my number box control it doesn't push the value back into the class' property it is bound to until I tab off, even though I have configured an object binding source to the custom BindableValue property with the update mode set to Property change.
Having entered value as in (1) if I go back and delete the value I am then prevented from tabbing off or clicking off the number box. I have set VS2010 to throw when .NET exception is thrown but it's not breaking.
It's been a while since I did WinForms stuff so I'm at a bit of a loss where to start. Any tips as well as a solution would be much appreciated.
EDIT:
I've tried a number of different things and am getting nowhere fast, it's getting really frustrating now:
I followed the info on MSDN, i.e. I added a ComplexBindingProperties attrib, slightly different in the textbox's private keyUp event handler I raise the event as indicated by the linked article OnBindableValueChanged(). However in all cases my event BindableValueChanged is always null.
I read similar articles to (1) but instead of declaring the event using EventHandler they used PropertyChangedEventHandler, tried this same result.
I added the DefaultBindingProperty attrib.
[You can read about this experience on my companies blog too - OCC Blog - Binding woes ]
I finally figured it out so thought I'd share it here to save someone else the tedium of trawling through Google reading lots of responses that say they work but in .NET 4.0 no longer seem to apply.
Okay, a lot of stuff I was reading on Google kept telling me my usercontrol had to have a Changed event using either EventHandler or PropertyChangedEventHandler delegates - different pages indicated different delegate. I tried both - fail!
What I had to do in .NET 4.0 is actually much nicer. Simply put just like my class that I was binding my usercontrol to does I had to implement the INotifyPropertyChanged interface. Then in my usercontrol when I wanted to pushback into my source object I just raised the PropertyChanged event (e.g. PropertyChanged("BindableValue"); ) the interface defined and hey presto all was well with the world again.
This above is a lot more elegant but unfortunately articles, forums and posts that are indexed by Google have not caught up with this yet for .NET 4.0 so all the existing stuff will lead you down dead ends and much frustration. I hope this saves someone else a lot of time.
I have a question about how to best perform the validation in the setup below.
I have a small WPF-based UI (using the WAF framework). This particular dialog contains a DecimalUpDown control (this is from the WPF extended toolkit) in which the user may modify the value by using the up/down arrows or typing or pasting.
The user should not be allowed to continue (the Next button should be disabled) until a valid number (format and range) is supplied. The user should also be aware that it is this field's value from preventing them to continue. How do I perform this validation?
I have a pretty simple View Model -- it contains a float FooValue property (bound to the up/down control) and implements an bool IsValid() which the parent container binds to (for the Next button's enabled state).
I notice some other web sites suggest that I should throw an exception in the setter (e.g. http://www.codeproject.com/Articles/15239/Validation-in-Windows-Presentation-Foundation). It doesn't really make sense here because my property is a float. Should that instead bind to the "Text" value of the numeric up/down and do the parsing (and throwing the exception) at the View Model level?
On waf.codeplex.com there is actually an example that shows how to do data input validations - http://www.codeplex.com/Download?ProjectName=waf&DownloadId=282750 . It is using the BookLibrary sample app which is included in the framework source code.
Basically you will be using data annotations on your properties and the ValidatesOnDataErrors=true attribute on your XAML elements.
I experience strange things when setting the "Language" property in WPF:
Set FlowDirection to "RightToLeft" on a Window or textbox/textblock
Set the Language property to "fa-IR"
Set the text to one of the sample texts below (A, B)
A. This text does not render correctly in WPF 3.5:
فاکس: +44 1908 215040
It works with WinForms and Silverlight. Note that it contains a 'LEFT-TO-RIGHT MARK' (U+200E)
Here is a HTML version of the above with numeric character references to LRM, to visualize where the LRM is inserted:
فاکس: +44 1908 215040
B. This text does render correctly in WPF:
فاکس: +44 1908 210210
But it contains (I believe) unncessary LRM characters. I put together the text in a trial-and-error fashion.
Here is the HTML version with the extra LRM characters
فاکس: +44 1908 215040
Why are the extra characters needed / what am I doing wrong with the original text?
Note: The problem occurs IFF setting the Language property, either explicitly in XAML or code (like Language="fa-IR") or by overriding the default value of the Language property in code (assuming current culture being "fa-IR") as so:
FrameworkElement.LanguageProperty.OverrideMetadata(typeof(FrameworkElement),
new FrameworkPropertyMetadata(XmlLanguage.GetLanguage(CultureInfo.CurrentCulture.IetfLanguageTag)));
If I leave the language property as en-US, the text renders correctly in WPF, but I really need to set the Language to have value conversions work without having to set the ConverterCulture explicitly on each and every data binding that could be binding to some culture dependent data.
There are also other problems, like LRO ('LEFT-TO-RIGHT OVERRIDE' (U+202D)) being ignored.
I really need help understanding what is going on, as this could turn out to be a show stopper for localizing my application to Persian and Arabic.
I suspect that I am the one doing something wrong, as I fail to google for the problem.
Here is a a related post on MS Connect, but no one has so far confirmed the behaviour as a bug:
http://connect.microsoft.com/WPF/feedback/details/682784/incorrect-unicode-bidi-behaviour#
Note: I am not that familiar with the BiDi algorithm in general and know even less of the actual implementation in WPF. I have a basic understanding of Unicode.
My RIA enabled Silverlight Application is setting the thread culture in the App constructor (this is absolutley okay since it is an intranet application and will never ever be used by someone who is not german):
public App() {
InitializeComponent();
Thread.CurrentThread.CurrentCulture = new CultureInfo("de-DE");
}
It does what it should, the DataForms are displaying datetime values in german notation. BUT: it is spontaneously changing to en-US notation when navigating between items in the data source that is bound to the DataForm. Why?
It seems that the thread culture is not inherited by every control. Just for fun I displayed the Language of the control, and it was alwas set to en-US. To solve this, I hard coded the language de-DE in the style for the DataForm.
The same problem was described by Hannes (in german). Surprisingly in this case it was exactly the other way round: the DataForm was german, but the grid was english.
As Marc Wittke said, the thread culture is not inherited by every control (why on earth???)
Any way, you do not need to hardcode the values, this put this line in your Control constructor:
Language = XmlLanguage.GetLanguage(CultureInfo.CurrentCulture.Name);
And you control will use the CurrentCulture.
Cheers,
André