Akzeptanz des Wertes im TField eines TDataSet

[Jasocul]

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.

[himitsu]

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:

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

Der CallStack sagt A-B-E-F-G aber wenn man C und D wissen will, muß man manuell im Code nachsehn
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.

[Jasocul]

Von mir auch ein Sorry.
Du hast bei mir in dem Moment das Fass zum überlaufen gebracht, weil ich bereits fast 3 Arbeitstage verbraten habe, um diesen Fehler zu beheben. Dazu mit dem QuantumGrid, das derartig komplex ist, dass ich mich bei der Fehlersuche immer wieder in die falsche Richtung bewegt habe.

Ich kämpfe hier in diesem Zusammenhang gegen einen konzeptionellen Fehler. In diesem speziellen Fall wird das Exit eines anderen Eingabefeldes verwendet, um Fachlogik abzubilden. Dazu muss ich hoffentlich nichts weiter sagen. Jedendfalls wird das heute noch für Diskussionen sorgen.

Zitat von himitsu:

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)

Dafür ist doch OnCloseQuery da. Ich wäre gar nicht auf die Idee gekommen, sowas im OnClose oder OnDestroy zu machen. Deswegen hatte ich es auch ins OnValidate gelegt, damit man eine Chance hat, den weiteren Ablauf zu steuern/abzubrechen. Ich kann mich nicht mal erinnern, wann ich das letzte Mal Application.ProcessMessages eingesetzt habe. Das muss zu Zeiten gewesen sein, als die Progressbar sich beim Step noch nicht selbst refresht hat.

Zitat von himitsu:

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.

Oh ja, eine MessageBox im OnPaint genau an der Stelle, wo gerade ein Repaint erfolgt, kommt immer gut.

Zitat von himitsu:

Der Stacktrace ist auch nicht "was aufgerufen wurde", sondern "wie es zurück geht".

Ich interpretiere das meisten also "von wo komme ich denn her, um hier gelandet zu sein". Dass die Rücksprungadresse drin steht sollte klar sein. Ist ja schließlich der Stack.

Zitat von himitsu:

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.

Im aktuellen Fall bekomme ich von der Funktion ja ein Boolean zurück, ob es funktioniert hat. Die Message ist dann nur eine Info für den Anwender und der Rest ist wieder korrekt gesteuert. Ein Raise kann ich nicht ohne weiteres machen, da dann das hausinterne Exceptionhandling greift und das ist nicht wirklich optimal (Details spare ich mir).