Forum Replies Created
-
Posts
-
It appears to be a more general problem. The introduction of TacShadowForm has broken popup windows all together. They won’t go away if clicking outside the window. They won’t go away after that, even if you click some close button inside the popup form. I presume that’s because they have become an image i.s.o. a real form.
Have a look at the GIF.
The value in Min/Max is 1000 – 20000. The first time the user tries to change the value to 400 the OnValidateError is thrown. The dataset stays in dsEdit mode. Then the user tabs out of the edit field: no OnValidateError any more.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.
I think function TsCustomNumEdit.CheckValue should should start off like this:
begin Result := NewValue; if not Modified then Exit; // Accept any value if field is not entered by user if FMaxValue <> FMinValue then . . .That would not cure the Conversion error above, but would once and for all get rid of unmanageable data errors.
I think the procedure should read:
procedure TsCustomNumEdit.SetText(const AValue: string); var Val: String; begin if not (csReading in ComponentState) then begin Val := TextToValText(AValue); if Val <> '' then FValue := CheckValue(StrToFloat(Val)) else FValue := 0; DataChanged; SkinData.Invalidate; end; end;But again: this stems from a TsDBCalcEdit control that’s being filled from the database. Not by the user. Why do you want to do a CheckValue in that case? What possible correction can the user make if the Min/Max message pops up? He/she is not editing the field at that time, program logic may even prohibit editing of the field!
I found it: Right click the Object Inspector and select View – All
That’s all 🤣
Please close this topic.It’s a problem with my Delphi installation. Don’t know what causes it.
It definitely is not an AC problem.Maybe as a last resort you could make a new TsHintStyleController that inherits from TcxHintStyleController. That’s a good idea anyway, because if a TcxHintStyleController is present, hints are not skinned at all.
Yes, I mean the timing. It is so terrible, that I disabled hints on disabled controls all together.
A user cannot put the mouse cursor in any field without getting a hint immediately. That’s very awkward behavior. Screen2Gif16 shows that very clearly.The value will not be changed automatically if AutoValueCorrect is False. You should specify a required behavior in the OnValidateError event.
The point is, that the OnValidateError does not occur in this case!
