Forum Replies Created
-
Posts
-
Behavior should not be hard coded, I agree completely.
But you are looking at the control being changed. That’s not correct. You should look at the control being changed by the user. Even if modified is False and the focus moves away from the control, minmax checking should occur. That’s the moment for OnValidateError.
Of course, if a new record is inserted and its values are all wrong, only doing the right thing is at the data event can prevent this.
Have a look at https://www.alphaskins.com/forum/?topic=tsdbcalcedit-should-not-honor-min-and-max-on-displaying-values&paged=2#post-69656
It shows that effortless I can enter a wrong valueI still think you should come up with a solution for the placement of hints on grid headers with AutoAlignment set to True. Maybe don’t honor it if the hint is for a grid header?
It is changed, indeed. But I think those week numbers are very hard to read in any skin. The title “W” is almost invisible.
Have a look at these two GIF’s.
GIF Screen2Gif15 shows the timing if HandleDisabledCtrls is False. That timing look OK.
GIF Screen2Gif16 shows the timing if HandleDisabledCtrls is True. That timing is totally wrong. Having timing like that clobbers the screen with hints.
I strongly advise to redesign the timing of hints. Especially a hint timing that allows reading long hints (a timing dynamically adjusted to the amount of text) would be enormously beneficial.What also shows is the changed position of the hint. If HandleDisabledCtrls is True the hint is much more to the right.
The double activation of OnValidateError is eliminated 👍
The GIF below shows how to enter an invalid value (values must be >= 1000 in this case). It was no problem inserting a record with value 500
It shows the problem already discussed in #69607
Again this problem can be overcome with an extra check in DoExit.Don’t change it automatically. Don’t focus on the field being changed, focus on the field being changed by the user. Prevent leaving the field’s focus when the dataset is in Edit/Insert mode and the value is outside the limits. That’s all. Override the DoExit procedure.
No, don’t change. Just check and throw event. User was in the field while the dataset was in insert/edit mode. That’s a big difference!
In general, when the dataset is in insert/edit mode, any change must be checked against min/max values and even when no change was made: a field set with the wrong values must not be possible. The GIF shows the problem: a dataset with fields having an impossible value!!On leaving the field, check whether the underlying dataset is in Edit or Insert mode. Then apply strict min/max rules.
If the user action leaves the field, he was obviously in the field. Then the check should be made.
You saw the devastating effect of accepting a blank/zero value in the GIF. So, it must be solved.The property can be named SkinBW and it is active only for imagelists consisting of only B&W images. As soon as an image is added to the imagelist with more than two colors, the property is disabled. Images that are not transparent but still B&W can simply be inverted.
Please download it from Here
<p zoompage-fontsize=”14″>‘0’ is not checked because “Modified” is False there.
Value has not been changed by user and was not checked.
Searching a solution..When the cursor leaves the field by a user action, the min/max values should be checked.
