Hallo,

bin mir nicht so recht sicher, ob das nicht besser im "Controls"-Teil aufgehoben wäre... aber irgendwo muss ich es ja reinschreiben.

ich habe einige Zusatzfunktionen in's DBEdit eingebaut (eigene Komponente, die von DBEdit abgeleitet ist). ZB. Datumsvervollständigung - man gibt ein "010199" und er macht 01.01.1999 draus. Das Problem ist dass ich das am liebsten in der OnExit handhaben würde - doch leider ist das "zu spät". Die drunterliegende TField - Klasse macht seine eigene Abprüfung - weshalb bei obiger Beispieleingabe die Fehlermeldung kommt "..bla.. ist kein gültiges Datum". Erst danach springt er in die OnExit rein. Es bringt also auch nichts, meine Sachen vor den "inherited"- Aufruf zu bringen, weil das "Exit"-Ereignis an sich eben erst zu spät ausgelöst wird.

Ich habe im Original-Quelltext gesehen wo diese Prüfungen stattfinden - in der Klasse TDataLink. Diese abzuleiten und den Fehler zu unterdrücken geht aber nicht, weil die entscheidenden Propertys bzw. Prozeduren (die ich überschreiben müsste) private sind. Genauso wenig sollte ich den gesamten Quelltext zu nehmen und die Klasse neu zu erstellen.

Glücklicherweise hat die Software als "Standardtaste", um auf das nächste Feld zu springen, die <ENTER>-Taste, weshalb ich das ENTER-Tastaturereignis abfangen kann und meine Konvertierungen VOR der anderen Prüfung kommen. Aber sobald der Nutzer dann doch mal den "windows-"konformen Weg geht (z.B. Tab, oder per Maus rausgehen) kommt diese dämliche Fehlermeldung.

Wie also lässt sich diese Fehlermeldung unterdrücken bzw. geht das überhaupt?

Zitat:

weil die entscheidenden Propertys bzw. Prozeduren (die ich überschreiben müsste) private sind.

Wahrscheinlich bekomme ich jetzt Prügel ...
Wenn du Klasse "ClassA" ableitest kannst du in deiner neuen Klasse "ClassB" auch mit einem Typecast auf die ursprüngliche Klasse solche Sperren umgehen ... ClassA()...

Zitat von little-x:

...
Die drunterliegende TField - Klasse macht seine eigene Abprüfung - weshalb bei obiger Beispieleingabe die Fehlermeldung kommt "..bla.. ist kein gültiges Datum".
...

Danke für den Faden! Genau das gleiche Problem hatte ich auch längere Zeit.
Dabei habe ich bei Datumsfeldern mit EditMask gearbeitet, so dass ein leeres Datum halt immer noch im Eingabefeld die beiden Punkte '. .' hat. Mit der folgenden Ereignisroutine für OnSetText habe ich mir helfen können:

markieren

Code:

procedure TDataModule.DateSetText(Sender: TField;
  const Text: string);
begin
  if trim( Text ) <> '. .' then Sender.AsString := Text
  else                          Sender.AsString := '';   // Damit die Eingabe eines leeren Datums möglich ist!
end;

Lästig und etwas Fehleranfällig ist dabei, dass diese Routine für jedes Datumsfeld mittels "OnSetText" eingebunden werden muß. Gibt es da eine elegantere Möglichkeit?