@tim and I are working on updating some old problematic C++ dialogs to Eto on Mac Rhino and were wondering if you had an input control that only allowed for numbers. We know about the NumericUpDown control, but were looking for something without the up/down buttons.
We also need to make sure that these controls always take periods for decimal points in all languages (instead of commas). This is the specific issue that we are working around right now. Rhino has always used period for decimal point in all languages.
Just for reference, this is one of the issues that we are working on
There isn’t one specifically, but you could probably subclass the TextBox control and strip out any invalid characters when the text changes.
This is a pretty standard control that we use all over the place in Rhino. Over the years we ended up with integer input box and a floating point input box controls in MFC. If you think it is too specific for Eto, we could add the control to Rhino.UI.
Any help on getting this pieced together would be appreciated.
Sure, I can help with that after the StackLayout/PropertyLayout are finished.
This might be a good reason to implement a MaskedTextBox for Eto (using System.ComponentModel.MaskedTextProvider in the backend) which should be able to handle these types of things (and so much more).
Although, the MaskedTextProvider might not allow for a variable length input, so it might not be suitable in this case… Though implementing something similar to that might work…
Maybe you can make the spinner buttons on NumericUpDown optional, similar to WPF Toolkit’s IntegerUpDown and DoubleUpDown
@menno That is definitely an option… though if a platform in particular did not support hiding the spinner, you’d have to swap out for a TextBox anyway and do the same sort of keystroke/input filtering that a MaskedTextBox would allow for.
We’d also have to add options to change the localization for the NumericUpDown so that you can force it to use a decimal instead of comma for regions like Germany.
Either way will work - though a MaskedTextBox that can handle this scenario might be much more valuable. I have ideas to abstract the input filtering that would make it work for both fixed and variable width inputs. (;
Thanks @stevebaer. I’ll move on to that later today. It took me a wee bit longer to finish up the ancillary changes for the StackLayout/PropertyLayout (changed old HorizontalAlign to TextAlignment, etc) and dealing with the migration to the wip branch.