wxFloatingPointValidator

[Bill Heitler]

I'm new to wxWidgets, and just starting to try to port a quite large MFC program. I'm trying to set up a simple floating point validator in a dialog. I want to allow the user to enter any value greater than 0.1 (up to some big number like a thousand), with 1 dp displayed. I'm using DialogBlocks for the interface design, and then adding my own code to bring in the validator. At the moment it looks something like this:

Code: Select all

// 
// code generated by DialogBlocks: m_TxtControl is the member variable for the text edit control
	m_TxtControl = new wxTextCtrl( itemPanel1, ID_MY_TEXT_CONTROL, wxEmptyString, wxDefaultPosition, wxSize(40, -1), 0 );
...
// my code:  m_fVal is a floating point variable
	m_TxtControl->SetValidator(wxFloatingPointValidator<float>(1, &m_fVal, wxNUM_VAL_NO_TRAILING_ZEROES));
	static_cast<wxFloatingPointValidator<float> *>(m_TxtControl ->GetValidator())->SetRange(0.1f, 1000.0f);

There are two problems with this, and I wonder if I am doing something wrong or if there is a work-around?
One: If the user wants to enter a valid number like 0.3 and starts by typing "0", the system dings as soon as the "0" is keyed in. If the first character entered is the decimal point ".", then entry can continue. But this is not very friendly - I think most of my users would expect to be able to enter a number less than 1 but greater than 0 by starting with "0.".
Two: if the user does start with "." to avoid the ding, but the enters ".1" it again fails, even though this should be within the allowed range. Looking at the source under debug, I think the problem is that the validator is checking:

Code: Select all

return m_min <= value && value <= m_max;

Even though my code is setting m_min to 0.1, in the debugger it is displaying as something like 0.10000000149. Then when the user keys in ".1", the <= condition fails because of the floating point inaccuracy. In this case the work around is to set the min in code to something like 0.099, but it would be better to tackle this in the source code with some sort of epsilon "slop" in the condition.
Does anyone have any thoughts about this? Is there something simple that I am missing? The failure to allow data entry starting with a 0 is a bit of a deal-breaker in terms of using this validator, at the moment.

[ONEEYEMAN]

Hi,
About point #2. Why not use 0 as the lower bounds? Because user may enter 0.001 and then the validation will fail for sure.
About point #1. Did you try to debug it? Remember the validator fires after every keystroke as you already discovered. So if you set the lower bounds to 0.1 and start with 0 - the validation will fail. Unless something else is going on...

In any case setting the lower bounds to 0 will hopefully resolve all of you issues.

Thank you.

[PB]

Mhm, it looks like the range issue is actually a serious one and not easy to work around, making user experience quite unpleasant.

Just imagine the range being is 15-100 and the current value 20. The users wants to change the value to 15, so he deletes 20 but now he seemingly cannot type the number, as when he tries typing 1, it gets rejected and nothing is displayed, depending on PC setup they may not even hear a warning bell. This would lead to a [confused + frustrated =] angry user.

I do not remember MFC, how was this issue dealt with there? Was there a tag that would allow different validating when typing and when edit loses focus / the dialog is closed with OK?

IIRC, the main wxWidgets maintainer (vadz) has relatively recently written that wxValidators are not designed well and compared to MFC people actually seems to not used them much...

When it comes to worst, you may be able to make it work with wxSpinCtrlDouble and/or overwritting the validate/transfer methods.

I advise asking the developers in the wx-users group, perhaps there is an easy solution....

[Bill Heitler]

Thanks for your replies. I don't really want to set the allowed min to 0 because later in my program that could lead to a divide-by-zero problem if the user actually entered zero. Anyway, if the interface/documentation claims that one can set a minimum value, it's a bit hard to remember to always set it below what you actually want - far better to do the appropriate adjustment in the validator code itself.
PB's point about the 15-20 data entry problem really does make range-checking in this validator pretty unusable. My hunch is that MFC does its validation only on completion, not on a char-by-char entry basis, but I've never looked into it because it just worked (usually!).
I'm not sure how to contact the developers (I'm new to this system), but I'll have a look at the links on the main website. At the moment it looks like I'll abandon the validator range-check setting, and just do post-transfer validation in my own code.
Thanks again for reacting so quickly!
Bill

[doublemax]

This probably won't help you porting a big MFC application, but FWIW: as a user i find validators that work as you type quite annoying. Validation on "kill focus" makes more sense to me in every aspect. You can then either programmatically fix the value or set the focus back to the control. In both cases you can use wxRichToolTip to inform the user non-intrusively. Don't use modal message boxes if the validation fails, or i will come and delete your hard drive

[PB]

As written above and all PC users have witnessed many times, as-you-type-validation is literally impossible to implement to work properly in all cases.

I can create a ticket on wxTracker about this (assuming there already is not one) but I would not expect the issue to be solved fast.

[ONEEYEMAN]

PB et al,
There are currently couple of pull request opened for rewriting the validators (generic and text ones).
You can try to apply them and verify if things are better.

https://github.com/wxWidgets/wxWidgets/pull/752
https://github.com/wxWidgets/wxWidgets/pull/749

Thank you.

[PB]

And there already is a ticket for range validation: http://trac.wxwidgets.org/ticket/12968

[Manolo]

I had to deal with those (among others) issues with wx' numeric validation. After some changes, the current implementation still has some flaws.

I coded my own, full featured, wxFormatValidator.
Find it at https://sourceforge.net/projects/wxcode ... omponents/

Note: As of January 2018 wxCode project has been retired. Does any body knows how its components will "survive"?

If you read the provided docs, you will find some interesting topics and how to handle them. Basically you define the "format" of the "while tipying" and "result" and the behaviour you wish.
Also, try the included sample.

By "full featured" I mean: while-typing validation, after-typing validation, exact or tolerant format match, range check, any number (not limited to double or whatever), special values (e.g. "inf") accepted, scientific and engineering notation, custom decimal separator and thousands separator, digit grouping, etc.