Rationale for QIntValidator behaviour
-
I have hit the issue with
QIntValidatorthat others have reported in the past whereby what seems to be an obviously out of range value is treated asIntermediate. However, other than people pointing out that this is as documented, I haven't seen a rationale for it.If I set a lower value of 100 and an upper value of 900, why is 999
Intermediate? The rationale in the documentation is that I haven't necessarily finished typing and I could add another digit to make it correct:"This is intended because the digit that prevents a number from being in range is not necessarily the last digit typed."
So what digit could I add to 999 to make it correct? Surely any further digit will make it greater than 999.
-
I have hit the issue with
QIntValidatorthat others have reported in the past whereby what seems to be an obviously out of range value is treated asIntermediate. However, other than people pointing out that this is as documented, I haven't seen a rationale for it.If I set a lower value of 100 and an upper value of 900, why is 999
Intermediate? The rationale in the documentation is that I haven't necessarily finished typing and I could add another digit to make it correct:"This is intended because the digit that prevents a number from being in range is not necessarily the last digit typed."
So what digit could I add to 999 to make it correct? Surely any further digit will make it greater than 999.
@Bob64
IIRC it's because you could change, say, the first of those digits to8to make it899.I don't defend Qt's validators/intermediates, they seem "odd" to me, but I think you will find they work as they do and you have to live with them as they are not going to get changed. I don't know that you will get a terribly good "rationale" :)
-
@Bob64
IIRC it's because you could change, say, the first of those digits to8to make it899.I don't defend Qt's validators/intermediates, they seem "odd" to me, but I think you will find they work as they do and you have to live with them as they are not going to get changed. I don't know that you will get a terribly good "rationale" :)
@JonB Thanks. Glad it's not just me!
What you suggest sounds more like a significant edit rather than just typing another digit as implied by the docs. You have to move around in the string, delete a digit, and add a new one. In that case, you might as well make something like "101q"
Intermediateas it only needs a single backspace from the current cursor position. -
@JonB Thanks. Glad it's not just me!
What you suggest sounds more like a significant edit rather than just typing another digit as implied by the docs. You have to move around in the string, delete a digit, and add a new one. In that case, you might as well make something like "101q"
Intermediateas it only needs a single backspace from the current cursor position. -
It is really annoying (as a user) if you could not type in
999and then change it to899later. If you're in the flow it is not directly obvious why this should fail, even if the upper limit is900. We have some checks of floating point input fields in our software ported several times from other GUI frameworks that get really annoying at times. So, I am advocating for this kind of editing behavior. Yes, it makes the programmer's job harder, but it is worth it for the end user.
