- This topic has 24 replies, 2 voices, and was last updated 5 years, 4 months ago by
.
-
Posts
-
These are two devastating samples of this bug.
In ScreenToGif7 you see that an inserted record does not receive the entered text at all. In stead the value is set to 0 which is even below the minimum value property.
In ScreenToGif8 you see a record being inserted, which is rejected because of duplicate key and then the insert is cancelled. After cancellation the key value shows the wrong value, making the record shown in the grid different from the record in the edit field!!
I have not tested it yet, but comparing current and new source, I came across the statement in line 203 which is more than 200 characters long. That’s not readable anymore. Here’s the alternative:
if ( CharInSet(Key, [#32..#255]) ) and ( FDataLink.Field <> nil ) and ( not CharInSet(Key, ['0'..'9']) ) and ( Key <> {$IFDEF DELPHI_XE}FormatSettings.{$ENDIF}DecimalSeparator) and ( Key <> '-' ) then beginHere it is clear that you accept any characters not present in a number.
Line 256 is another example.
This is how it could look like:
Result := ( Assigned(FDataLink) ) and ( Assigned(FDataLink.DataSource) ) and ( not readonly ) and ( not(csDesigning in ComponentState) ) and ( FDataLink.Active ) and ( FDataLink.CanModify ) and ( FDataLink.Editing or FDataLink.DataSource.AutoEdit ) ;The first test already failed.
I had no problem inserting a record with the key value empty or 0. The minvalue for that field was 1000.
Here is a gif to show the problem:‘0’ is not checked because “Modified” is False there.
Value has not been changed by user and was not checked.
Searching a solution..<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.
What to do, if value was changed from the DB and cursor leaves the field by a user action?
If value is checked there, then will be checked value assigned from the DB, that you wanted to avoid in this topic.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.On leaving the field, check whether the underlying dataset is in Edit or Insert mode. Then apply strict min/max rules.
User was in the field but he didn’t change it.
Value was initialized not by user in this case, it’s received from DB engine there.
Check and change it if smaller than MinValue?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!!Value of the control in the bsEdit mode may be specified by other control, also. If we will change it automatically it will look strange for user.
And, when record is inserted, the value of field is null usually, but this value may be specified by the DB engine, also. What to do in this case? We can’t automatically change data which was specified by the DB.
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.
Sorry, many things are not clear there still.
What if new record is created, but value is out of limits, specified in the control?
It’s not changed by user, it’s defined by DB. What to do? Do not allow exit a control?
Such hardcoded behaviour will be unwanted for many people, I’m sure.
Imagine situation, we have two such controls for two different fields. New record has incorrect value for both fields. Which control should not allow to exit? I can imagine many such situations..There exist the OnValidateError event. Developer can define a behaviour which required (if the AutoValueCorrect property is False). I think, this behaviour should not be hardcoded.
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 value>> Even if modified is False and the focus moves away from the control, minmax checking should occur.
So, we should cancel all checking of the
Modifiedproperty in code and ignore it now?Or, as another solution, maybe just change Modified to True when new record is inserted?
Don’t get mad. Just trying to formulate the cause of action.
If the OnExit occurs, the user has been in the control. Therefore it stands to reason to check the fields validity then. Even if modified is False.
Changing Modified to True when a new record is inserted is definitely wrong. Records may stem from different sources. The values of the fields may be well be beyond their min/max values.For instance, the program may show the user a list of records where the values are wrong, with the purpose of letting him change the values to valid ones. Therefore the situation in the attached GIF should not be possible: the first time the user entered a wrong value, he got an error message. Then just Tabbing outside the TsDBCalcEdit control with the wrong value was possible. Why was this possible? Because the user did not modify anything, so Modified was False. That situation should not be possible. So, I suggested to check the min/max values in an overridden DoExit procedure.
- You must be logged in to reply to this topic.