NumericTextBox binding bug

Hi,

I've got a NumericTextBox control which is bound to a dependency property containing a Double type. If I set the culture of my UI thread to be something other than english (e.g. de-DE) the numeric text box does the right thing and shows the text, and accepts input, with a comma as the decimal point seperator (which it is in German).

The problem I have is that the Text property on the text box resolves its initial value from the binding and displays it with english formatting (i.e. instead of displaying 1,37 it displays 1.37). If you try to edit that value it only lets you use a comma as a decimal seperator and it starts by removing the point seperator (turning 1.37 in to 137).

Simply placing a binding converter in the middle and returning a ToString() of the value parameter fixes the problem, but it feels dirty. Can you guys do something about this?

I've written a sample project for you, but since there's no upload facility on the forums and I couldn't find any published email addresses you'll have to give me an email address I can send it to, if you want it. If you can reproduce the bug without it, sweet.

Regards,

Josh.

Hi Josh,

It would be useful for us if you could provide the sample project -- thanks!  You can upload a zip file on these forums using the Options tab (yeah, go figure), or mail me on ivan @ the obvious domain (please strip out all binaries first).

Attached, without the binary and license files.

Hi Josh,

Thanks for taking the time to create and post the sample.

This behaviour, although admittedly it appears a bit odd, is sorta-kinda by design.  Let me explain and you can give us your feedback if you still think it is wrong.

You are specifically binding the Text property of the NumericTextBox.  By doing this, you are effectively saying "Here is the text I want you to display; I've figured out the formatting."  You are effectively overriding the NumericTextBox's normal formatting rules.  When the user changes the text, the box re-evaluates the text as a value.  In your case this leads to bad things because WPF's implicit number-to-string converter doesn't seem to respect culture, which is why it initially shows 1.37; then when the user edits the text, we try to reinterpret that text using the actual culture, at which point the . gets discarded because it is not the decimal point separator in the German locale.

If, however, you bind the Value property of the NumericTextBox, then the box treats the bound value as a number and formats it according to the culture in effect (or the control's Culture property).  You are effectively saying "here is the value I want you to display; you figure out the display."  This should be the more normal case because usually you are interested in a numeric text box for its numeric value rather than for the textual expression of that value.  You will find that if you change your sample to bind Value rather than Text, it is correctly formatted from the start.

Hopefully this makes sense.  Like I say I know it can lead to odd and seemingly buggy behaviour.  So we would be open to your feedback on whether we should change it to enforce value interpretation even when the user explicitly binds Text rather than Value.  In the meantime, changing your binding from Text to Value should address your immediate issue.

 Hi Ivan,

 Thanks for the reply, and for looking into the issue. It seems like strange behaviour to intentionally build into the control, especially since the first time the user tries to do anything with its contents the default value will be messed with anyway (and not actually in a very nice way either - removing the decimal seperator turning my 3.15 into 315 doesn't strike me as useful).

The workaround you gave me is suitable to a point, however how about making the value property nullable and only setting it if the user changes it from the default (or at least making that a flip on switch). Binding to the text property is nice since to my code an empty string == null, anything else is a number, and in some situations that extra state is required (in the specific scenario I'm using this in that textbox is being used to calibrate a medical monitor and 'not callibrated/null' has a very important meaning). Sure I could write my own code that tracked the state, or force the user to deal with a value like -1 that means 'not configured', but it would be much nicer from my side of the fence if the control could deal with that situation.

Regards,

Josh

Fair enough.  We'll see if we can address this issue.

We can't really make Value nullable at this point because that would be a breaking change for code that reads the Value property.  We could look at adding a HasValue property, which would return true if the box was empty, but I am not sure if this would work nicely with the way you want to databind the control.  Would that be useful to you?  If so, does it need to be built into the control or you handle the empty-string case via a value converter on the Text binding?

Hi Ivan,

To me, it seems best as if the fix would be to have the Text binding respect the culture.

I can understand your reluctance to make the Value property nullable but I think the API would start to look strange if there was a Value property on the control that wasn't nullable, and a HasValue property alongside that. I fear that the implementation could be a bit strange too.

I understand your agument for having the binding behaviour ignore the user's Culture, however I still find that behaviour so strange that I don't believe it would ever be desirable. Your opinion may differ here.

If you would be prepared to change the behaviour of the Text property binding, that would be my preferred fix, if not, I don't really like the alternative so you don't need to implement that for me - I'll just use the workaround I currently have of placing a binding converter in the middle that returns a .ToString() of the passed in value - which will take the culture into account.

Regards,

Josh.