- This topic has 24 replies, 2 voices, and was last updated 4 years, 1 month ago by
.
-
Posts
-
There is a case in which the Text property of the TsDBCalcEdit control does not reflect the actual field’s value:
1. Insert a record
2. Place a new vale in the TsDBCalcEdit control
3. Cancel the insert (dataset.Cancel)Now Text still shows the entered text, where it should show the actual field’s value.
This is a serious bug 😲
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
- You must be logged in to reply to this topic.