|
Akzeptanz des Wertes im TField eines TDataSet
Folgende Situation:
Ich arbeite mit dem QuantumGrid und nutze das EditRepository, um eine Eingabe zu validieren. Das Besondere ist, dass das zugrundeliegende Feld ein Datumsfeld ist (auch in der DB), aber die Eingabe so umgebogen ist, dass maximal nur 4 Ziffern eingegeben werden können. Diese werden im Validate geprüft und aufbereitet, damit ein gültiger Datumswert entsteht, der im DataSet dem Feld zugewiesen werden kann. Im Fehlerfall (kann nicht zum Datum aufbereitet werden) natürlich nicht. Das funktioniert soweit gut, sofern man beim Validate den Datensatz nicht wechselt. Stehe ich aber im betroffenen Feld und will von dort den Datensatz wechseln, wird das Validate genauso abgearbeitet, wie gewünscht. Allerdings gibt es dennoch eine Exception (nicht meine Fehlermeldung), dass die 4-stellige Eingabe kein DateTime ist, was ja auch stimmt. Soweit ich das sehen kann, liegt es am Field des DateSets, das zwar bereits den korrekten Inhalt hat, aber noch nicht als Wert akzeptiert hat. Wechsel ich programmatisch ins nächste Feld und wieder zurück, also so eine Art Zwangsakzeptanz, gibt es keinen Fehler. Da aber der Anwender steuern kann, in welcher Reihenfolge die Felder stehen und welche editierbar sind, kann ich nicht einfach ein Feld weiter und wieder zurück, um die Akzeptenz auszulösen. Vermutlich habe ich nur ein Brett vor dem Kopf (oder ich finde das Schlüsselwort für die Suche nicht) aber es muss doch ein Möglichkeit geben, diesen Vorgang auszulösen, ohne das Feld zu wechseln. Kann mir bitte mal jemand auf die Sprünge helfen? |
AW: Akzeptanz des Wertes im TField eines TDataSet
Es wird also irgendwo validiert, aber das nicht mit der überschriebenen "ValidierungsUndAnpassungs"-Erweiterung?
Oder wird doch deine Methode an der "richtigen" Stelle aufgerufen und die Daten kommen dennoch nicht richtig zurück? Dann mußt du eben schauen, wo das schief geht und dann versuchen dort auf die richtige Funktion zu gehen. Also erstmal ab der Exception, oder z.B. bei einer MessageBox manuell den Debugger anhalten, und dann im Stacktrace zurück, bis der Verursacher gefunden wurde. Eventuell stückchenweise zurück, also mehrmals in den Fehler laufen. Da du nicht gesagt hast, wie/wo deine Validierung/Anpassung arbeitet, würde ich jetzt auch mal ganz einfach davon ausgehen, dass dein Code auch an der falschen Stelle sein könnte und eben bei diesem Fall garnicht greifen kann. Genauso kann auch grundsätzlich der Fehler wo anders liegen, wenn im hauseigenen Delphi-Code irgendwo etwas vergessen wurde. |
AW: Akzeptanz des Wertes im TField eines TDataSet
Probier mal:
Delphi-Quellcode:
DeinDataSet.UpdateRecord;
|
AW: Akzeptanz des Wertes im TField eines TDataSet
@Papaschlumpf73:
Klingt gut, hatte aber keine Auswirkung. Der Fehler besteht weiterhin. Zitat:
Zitat:
Zitat:
Zitat:
Delphi-Quellcode:
procedure TMeineForm.DATUMPropertiesValidate(Sender: TObject; var DisplayValue: Variant; var ErrorText: TCaption; var Error: Boolean);
// Dieses Validate bezieht sich auf ein TcxEditRepositoryMaskItem var Datum: TDateTime; begin inherited; Error := not IsDatumValid(DisplayValue, Datum); // Datum ist ein "out" if not Error then begin MycxGridDBTableView.DataController.DataSet.FieldByName('DATUM').AsDateTime := Datum; // MycxGridDBTableView.DataController.DataSet.UpdateRecord; // Keine Wirkung // MycxGridDBTableView.DataController.SetEditValue(FieldIndex, Datum, evsText); // Auch ohne Wirkung // Diese Springerei zwischen den Feldern wirkt, ührt aber unter Umständen zu einem erneuten OnValidate und ist auch Sch... if not MycxGridDBTableView.Controller.EditingController.EditingItem.IsFirst then begin MycxGridDBTableView.Controller.FocusNextCell(True); end else begin MycxGridDBTableView.Controller.FocusNextCell(False); end; end else begin ErrorText := 'Ungültiges Datum!'; AShowInfoMessage('Ungültiges Datum!'); end; end; |
AW: Akzeptanz des Wertes im TField eines TDataSet
Du könntest dich in das OnSetText des Fields einklinken und dort die Validierung ausführen.
|
AW: Akzeptanz des Wertes im TField eines TDataSet
Zitat:
|
AW: Akzeptanz des Wertes im TField eines TDataSet
Wenn die Exception nicht in EURER Funktion ausgelöst wird, bzw. nicht durch etwas, was ihr darun aufruft, dann sind sie natürlich nicht darin aufgelistet.
Wie gesagt, * entweder einen Haltepunkt in eure Funktion und dann Schrittweise von da bis zur Exception * oder ab der Exception rückwärts, jeweils schauen was in den aufrufenden Methoden vorher (im Code darüber) ausgeführt wurde und ob da irgendwo eure Funktion auftaucht, bzw. ob sie dort hätte auftauchen müssen (aber vergessen wurde). Taucht diese Exception z.B. im BeforePost oder vor dem Changed des Fields auf, dann wäre es ja verständlich, dass die Daten noch nicht gespeichert sind. Im Validate außerhalb dem Feld etwas zuweisen und dann hoffen es würde an der richtigen Stelle nicht wieder vom VAR DisplayValue überschrieben? Und außerhalb am Fokus rumfummeln, ohne den aktuellen Prozess ordentlich abzubrechen? (z.B. Abort) Außerdem mit einem Dioalog (ProcressMessages) innerhalb die Verarbeitungsreihnenfolge (andere Aktionen) reinzuholen, damit der nachfolgende Code eventuell quer schlägt. Wenn kein Abort, dann den Dialog voa PostMessage oder ForeceQueue nach hinten verschieben. nja, da wundert es kaum jemanden. |
AW: Akzeptanz des Wertes im TField eines TDataSet
Zitat:
Zitat:
Zitat:
Zitat:
Zitat:
Zitat:
Zitat:
|
AW: Akzeptanz des Wertes im TField eines TDataSet
Problem behoben.
Uew Raabe hat mich auf den richtigen Weg gebracht. Danke dafür. Die Kompontenten arbeiten alle korrekt. Eines unserer Konzepte hat in einem besonderen Fall immer wieder dafür gesorgt, dass der Wert zurückgesetzt wurde. Das war allerdings nicht über den Callstack ersichtlich. Nachdem ich dieses unsinnige Verhalten im Konzept berücksichtigt habe, kann ich das Validate ganz normal ausführen und muss dort auch nicht mehr direkt den validierten Wert ins DataSet eintragen. Nächste Woche werde ich erstmal ein Refactoring des Konzepts beantragen.:tongue: |
AW: Akzeptanz des Wertes im TField eines TDataSet
Sorry, war nur ein leicht schnippiger Hinweis darauf, dass man sich über ungünstigen Code
(beim Application.ProcessMessages wird von Vielen oft davor gewarnt, aber auch Dialoge sind diesbezüglich nicht besser / noch schlimmer) Vieles sinnlos zusätzlich kaputt machen kann. ShowMessage im Form.OnClose/OnDestroy ist auch so ein geiler Fall. (hier nur andersrum, weil man sich gern wundern darf, wenn der Dialog oft nahezu sofort wieder geschlossen wird, da das gehende Fenster ihn mit nimmt) Es geht selten gut aus, wenn sich in komplexere Abläufe, welche eine bestimmte Reihenfolge haben müssen, plötzlich Pausen und die Verarbeitung von Messages ala Repaint, Timern, Tastatur, Maus usw. reindrängeln vordrängeln. Der Stacktrace ist auch nicht "was aufgerufen wurde", sondern "wie es zurück geht". Man darf also nicht vergessen, dass dort die Rücksprungadresse drin steht und es eigentlich einer der Befehle davor war. (der Debugger vertut sich auch manchmal und zeigt auf eine Codezeilen weiter unten)
Code:
Der CallStack sagt A-B-E-F-G aber wenn man C und D wissen will, muß man manuell im Code nachsehn
A
B C D < hier der eigentliche Gund für den Fehler E < hier ging es wegen dem Fehler rein F G < hier knallt es E < wird nie aufgerufen oder sich über nochmaliges/mehrermaliges Auslösen und Haltepunkte+F7/F8 durcharbeiten. Hier also irgendwann beim Aufruf von E im B zum Anfang und von da dann schrittweise weiter, bis spätestens, wo es kallt) Auch Fehler anzeigen mit ShowMessage rächt sich nicht nur hier, sondern auch anderswo, z.B. wenn man versucht eine Funktion von wo anders aufzurufen (Code wiederverwenden), da mit try-except versucht auf Fehler zu reagieren, um optional was Anderes zu machen. Außer wenn in einer wirklich endgültigen Funktion ein Fehler ausgegeben werden muß, um anschließend weiter zu arbeiten, am Besten grundsätzlich Fehler immer per RAISE abgeben. |
| Alle Zeitangaben in WEZ +1. Es ist jetzt 01:58 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz