Hello Divya,

sorry for the confusion. Even though my MaskInput has 'double' in it, the underlying data is actually a System.Decimal, which does support this:

> decimal d = 1.12345678901234567890m;

> d

1.12345678901234567890

> decimal d = 1.12345678901234567890123m;

> d

1.12345678901234567890123

Regardless of whether such precision is actually preserved, though, it is an odd behavior that all decimal places get cut off / floored to zero.

Is there a different MaskInput I should be using?

You could set NumericType on the MaskEditor to Decimal. But I am pretty sure the control deals with the value as a double internally, so that might not help. 

There's no other masked input control. But perhaps with numbers this precise, you would be better off just using unmasked text? 

Mike Saltzman said:

But I am pretty sure the control deals with the value as a double internally, so that might not help. 

Ah, I see.

(I still find it a little odd that it silently cuts off all digits rather than the remaining digits.

Mike Saltzman said:

But perhaps with numbers this precise, you would be better off just using unmasked text? 

Yeah, I suppose so.

Really, my primary goal wasn't so much masking as formatting — the mask is just a nice cherry on top that reassures the user their data won't be thrown away.

Am I correct to assume that I should use UltraTextEditor instead for such special cases? I can't seem to find a configuration that will use UltraNumericEditor, apply formatting (e.g., thousands separators), and support such precise numbers.

I've been working here at Infragistics for over 20 years and I've never encountered anyone with an application that actually NEEDED that kind of accuracy in terms of significant digits. So it seems like you could probably just round those numbers off to 17 significate digits. But, of course, I have no idea what your application is doing so I could be wrong. :) 

Mike Saltzman said:

Although, UltraTextEditor works with strings, to there's no way to format them automatically.

Right. That's why I was hoping to move this code to UltraNumericEditor in the first place — to get rid of finicky parsing/formatting code. :-)

Mike Saltzman said:

If you are binding the control to a data source, you can use the Parse and Format events of the Binding. 

Hm, that could be another approach! Thanks.

Mike Saltzman said:

Out of curiosity, what kind of application are you working on that requires SO many significant digits? :)

It's a legacy thing. I'm guessing the colleague didn't think about it much when creating a numeric(23, 20). (They're storing geo coordinates. Float would probably have been a better choice.)

But now that I'm trying to move this code to UltraNumericEditor, I'm running into the weird edge case, and I'm trying to do my best to accommodate them.

(Which, right now, it looks like I need to 1) check if the precision is >= 17, switch to UltraTextEditor, and 2) look into using bindings for that so the actual data is properly kept separate.)

Yes, personally, I would use UltraTextEditor.
Although, UltraTextEditor works with strings, to there's no way to format them automatically. You will basically just have to let the user enter a string and then use decimal.TryParse or something like that to retrieve the numeric value from the string. If you are binding the control to a data source, you can use the Parse and Format events of the Binding. 

Out of curiosity, what kind of application are you working on that requires SO many significant digits? :)