Konzept: Eigene Warnungen erzeugen

[himitsu]

Eine StringList hat doch ein OnChange?

Da kann also ein Event angegeben werden .. eventuell ein Porperty in der Basisklasse, welches das dann bei der internen StringListe einträgt.
Oder die StringListe meldet Änderungen an die Basisklasse und diese wiederum leidet das Event weiter.
Oder man baus in seine Klasse eine interne SetzeWarnung-Prozedur, welche die Warnung in die StringList einträgt und das Event auslöst.
...

[Xong]

Zitat von Alfi001:

Genau das hatte ich im vorherigen Beitrag vorgeschlagen.

Ich wollte nicht unterschlagen, dass du mir sehr bei der Suche nach einem passenden Konzept geholfen hast.

Also ein dickes Dankeschön!

[Ralf Kaiser]

Zitat von himitsu:

Eine StringList hat doch ein OnChange?

Stimmt! Ist mir auch jetzt gerade erst aufgefallen. Wann wurde das denn eingeführt? Eventuell sollte ich mir von Delphi-Version zu Delphi-Version mal die Neuerungen (genauer) ansehen...

Damit wäre die TStringList auch schon "intelligent" genug als Container für die Warnungen.

[nahpets]

Hallo,

mal so aus dem Bauch:

Die Klasse TDtausDataType bekommt eine Stringliste, in die sie die Warnungen reinschreibt.
Wenn sie mit ihrem Job fertig ist und es sind Warnungen vorhanden, schmeißt sie eine Ausnahme vom Type EWarnungenGefunden (oder so). Das aufrufende Programm muss diese Ausnahme abfangen und die Liste (wie auch immer) ausgeben.

Wird das Abfangen dieser Ausnahme vom Programmierer "vergessen", ärgert sich der Anwender und der Programmierer muss nachsitzen.

Bei einem Event muss sichergestellt sein, dass die "Nichtzuordnung" einer entsprechenden OnEvent-Methode zu einem Fehler führt.

[s.h.a.r.k]

Zitat von nahpets:

Hallo,

mal so aus dem Bauch:

Die Klasse TDtausDataType bekommt eine Stringliste, in die sie die Warnungen reinschreibt.
Wenn sie mit ihrem Job fertig ist und es sind Warnungen vorhanden, schmeißt sie eine Ausnahme vom Type EWarnungenGefunden (oder so). Das aufrufende Programm muss diese Ausnahme abfangen und die Liste (wie auch immer) ausgeben.

Wird das Abfangen dieser Ausnahme vom Programmierer "vergessen", ärgert sich der Anwender und der Programmierer muss nachsitzen.

Bei einem Event muss sichergestellt sein, dass die "Nichtzuordnung" einer entsprechenden OnEvent-Methode zu einem Fehler führt.

genau das hätte ich auch auch vorgeschlagen. schreib doch einfach ein interface für deine klasse, die die entsprechenden methoden und internen variablen schon integriert hat. dann kannst du das system auch bei anderen klassen verwenden. kurz und knapp brauchst du halt das folgende:

• container für die warnungen (was da am besten ist, sei mal dahin gestellt!)
• push-methode
• pop-methode
• clear-methode
• eine methode, die du am ende einer entsprechenden methode aufrufst, die prüft, ob mind. ein eintrag in der warnungs-liste vorhanden ist, und dann eine exception wirft.

[Blup]

Ich bin der Meinung, daß die Anwendung die Möglichkeit haben sollte, auf jedes Ereignis noch im laufenden Prozess zu reagieren. Dafür muss diese über das Ereignis benachrichtigt werden, wenn es stattfindet und nicht erst wenn der gesamte Prozess beendet wurde. Damit die Anwendung differenzieren kann, sollte neben dem Meldungstext auch ein Code mitgeliefert werden. Damit hat die Anwendung auch die Möglichkeit mit einer eigenen Exception zu reagieren.

Delphi-Quellcode:

type
  TDtausOnError = procedure (Sender: TObject; ACode: TErrorCode; const AMsg: string) of Object;
  TDtausOnNotify = procedure (Sender: TObject; ACode: TErrorCode; const AMsg: string; var AExcept: Boolean) of Object;

  TDtausDataType = class()
  private
    FOnError: TDtausOnError;
    FOnNotify: TDtausOnNotify;
  protected
    procedure DoOnError(ACode: TErrorCode; const AMsg: string); virtual;
    procedure DoOnNotify(ACode: TErrorCode; const AMsg: string; AExcept: Boolean = False); virtual;
  public
    property OnError: TDtausOnError read FOnError write FOnError;
    property OnNotify: TDtausOnNotify read FOnNotify write FOnNotify;
  end;

procedure TDtausDataType.DoOnError(ACode: TErrorCode; AMsg: string);
begin
  if Assigned(FOnError) then
    FOnError(Self, ACode, AMsg);

  raise TDtausExcetpion.Create(ACode, AMsg);
end;

procedure TDtausDataType.DoOnNotify(ACode: TErrorCode; AMsg: string; AExcept: Boolean = False);
begin
  if Assigned(FOnNotify) then
    FOnNotify(Self, ACode, AMsg, AExcept);

  if AExcept then
    raise TDtausExcetpion.Create(ACode, AMsg);
end;


procedure TDtausDataType.SetValue(v: String); 
var i: Integer; 
begin 
  // convert to upper case 
  fValue := UpperCase(v); 

  // lower case characters detected 
  if StrComp(PAnsiChar(v), PAnsiChar(fValue)) <> 0 then
    DoOnNotify(1, 'Klein- zu Großbuchstaben konvertiert!'); 

  // check each character 
  for i:=1 to Length(v) do 
  begin 
    { Hier folgt eine weitere Überprüfung jedes einzelnen Zeichens, 
      ob es im "DTAUS-Zeichensatz" erlaubt ist. 
      Nicht erlaubte Zeichen sollen dabei mit Leerzeichen ersetzt werden. 
      Bei bestimmten Daten (wie z. B. Kontonummer) ist das ein Fehler, 
      bei anderen (wie z. B. Verwendungszweck) lediglich eine Warnung. 
    } 
    {immer Exception auslösen}
    DoOnError(2, 'Ungültige Zeichen im Feld xxx');

    {oder normalerweise Exception auslösen, es sei den die Anwendung sagt das ist ok}
    DoOnNotify(3, 'Ungültige Zeichen im Feld yyy', True);

    {oder normalerweise keine Exception auslösen, es sei den die Anwendung sagt das ist nicht ok}
    DoOnNotify(4, 'Ungültige Zeichen im Feld zzz', False);

  end; 
end;

ErrorCode und Meldungstext sollten natürlich vordefinierte Konstanten sein, wobei der Text mit Format z.B. um den Feldnamen ergänzt werden könnte.