Akzeptanz des Wertes im TField eines TDataSet

[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).