NaN as default value for a numeric edit control

[menchar]

Using VS2010 and C#, trying to get a numeric edit control to use default value of NaN for simple double format.

While I can set the control's value to NaN using the control's properties window (set value = NaN), when the form is loaded is seems to me that it gets coerced to 0.0.

I've tried setting the range to -inf to +inf, and -50 to +50.  Doesn't seem to matter.  I have the control's out of range mode set to CoerceToRange rather than ThrowException.

If, at form load time, I set the control's value to NaN, it displays as such, and won't increment / decrement until the user enters a numeric value with numeral keys on the keyboard (whccih is the bhavior I want).

My question is, why doesn't the numeric edit control retain the NaN default value I place into it using the poperties window?    Does range coercion force NaN to 0.0?  If so, why can I set the control value to NaN after the form's loaded (range is the same) ?

[JD_war_eagle]

Hi menchar,

I have been able to replicate this behavior as well.  Even with coercion mode set as none the value is initialized as 0.0 when NaN is set in the properties window.  This could be a bug where the NaN case is simply not handled properly when it is set in the property window.  I will look into it and see if something incorrect is indeed happening.  For now, I would suggest just setting the control's value during initialization as a work around.

[menchar]

Looks like incomplete implementation of NaN handling to me.  No documentation of this behavior in any event that I can find - MS 2010 doesn't appear to have any help info for the numeric edit control itself.

If you set a numeric edit control value to NaN and then save the file and close it, when you reopen the file all of the NaN's are converted to 0's.

You might wonder why anyone would want NaN as the default value for a numeric edit control - one reason is that this forces the operator to make an entry, in the case where there is no reasonable default value that you want to allow.  If you use some "funny number" in lieu of NaN, it begs the question of using out of range coercion - you wouldn't be able to distinguish between a legitimate value and the "funny number".

Setting the "coercion mode" to none doesn't turn off out of range coercion as far as I can tell - is there any way to turn off range coercion?   I suspect it's the range coercion that forcing the NaN value to zero, not the value coercion (seeing as how that's turned off).

I suppose it could be there's no way to reconcile value coercion and out of range coercion for NaN.  Seems to me that maybe NaN should always be an exception to cercion.  If the control value has become NaN somehow, it's hard to explain that it should be automatically coerced to a legitimate (in range) value.  It's a similar semantic as with NaN in an expression - any expression that uses NaN always evaluates to NaN.

[JD_war_eagle]

Hi menchar,

I am inclined to agree with you, and there is definitely mutiple use cases where initializing to NaN can be beneficial.  I do not believe range coercion can be turned off.  Essentially, all that happens when that property is set in the control editor is that a line is auto generated in the InitializeComponent method which reads this.NumericEdit1.value = double.NaN.  It appears that when this line is executed it does not actually set the value to NaN, but instead leaves it at 0.0.  However, as expected setting it to any other valid double or infinity at this point works as expected.  It seems that the value is unable to be set as NaN until after the EndInit method of the control has been executed.