wir sind am überlegen in jede größere Routine unserer GUI folgenden Code einzubauen um dem Benutzer ein Feed Back über den Stand der Dinge zu liefern
Ist dies guter Programmierstil, gibt es eine bessere Lösung

zusammenfalten · markieren

Delphi-Quellcode:

procedure TMyForm.OpenWindowClick(Sender: TObject);
var ....

begin
  StatusBar.simpletext := ' jetzt gehts los ....'
  MyClass := TClass.Create;
  try
    try
        { *******    }
        {   hier steht dann code ...  irgend einen Klassenaufruf  }
        MyClass.DoSomething( ...);
        StatusBar.simpletext := 'alles ging gut ';

        AddtoLogdata('routine erfolgreich', 'Name der Routine');
        { *******  }   
    exception

    on e : Exception
           begin
            AddtoLogdata('routine leider nicht erfolgreich', 'Name der Routine');
           end;
  finally
  MyClass.Free;
  StatusBar.simpletext := 'jetzt fertig ';
  end;
end;

end;

Ich finde es akzeptabel, wenn Du diese Information in einem Logfile ausgibst. Ottilie Normalbenutzerin will eine Aufgabe erledigt haben, da reichen zwei Nachrichten "Fertig" oder "Fehler aufgetreten weil .....".
Im übrigen hat das mit gutem Code wenig zu tun sondern gehört eher zur Gestaltung der Benutzeroberfläche.

Gruß
K-H

Zitat von bernhard_LA:

wir sind am überlegen in jede größere Routine unserer GUI folgenden Code einzubauen um dem Benutzer ein Feed Back über den Stand der Dinge zu liefern
Ist dies guter Programmierstil, gibt es eine bessere Lösung

Das ist "graphisches Debugging", an dem, wenn das so ausgeliefert werden sollte, auch die Anwender ihren herzlichen Anteil haben werden. Wenn es nicht zu oft "anschlägt", wohl akzeptabel, ansonsten riecht der Kunde womöglich Lunte, daß er eingespannt wird.

Auf der anderen Seite: Investiert lieber in die Fehlerdetektion und -beseitigung! Dazu kann der geplante zusätzliche Code natürlich sehr helfen.

Das ist in der Tat des UI-Konzepts. Mit Blick auf die Software-Ergonomie sind Rückmeldungen an den Benutzer absolut wichtig. Nur so nimmt man ihn mit und gibt ihm die Gewissheit, dass er die Software und die ausgelösten Vorgänge steuert - und nicht umgekehrt. Eine spätere Ausbaustufe wäre aus Usability-Sicht die Option, Vorgänge abbrechen und rückstandsfrei zurücksetzen zu können (geht nicht immer, gibt dem Anwender aber eine große Sicherheit, keine unkorrigierbaren Fehler zu machen).

In der Entscheidung, dem Anwender (sinnvolle sind hilfreiche) Rückmeldungen zu geben, kann man Euch nur bestärken. Mit „graphischem Debugging“ hat das nichts zu tun.

kann man dieses Problem mit Anonymen Methoden besser lösen , in der Art wie ....

zusammenfalten · markieren

Delphi-Quellcode:

procedure ShowHourGlass(Proc: TProc);
 var
 OldCursor: TCursor;
 begin
  OldCursor := Screen.Cursor;
  Screen.Cursor := crHourGlass;
  try
    Proc;
  finally
   Screen.Cursor := OldCursor
  end;
 end;

man müsste dann eine Unmenege An Functionsprototypen deklarien und hätte lange ÜbergabeListen ..... ist dies nicht sehr unschön
anderseits immer den selben code in eine UI Funktion eintippen ... auch nicht schön

Zitat von bernhard_LA:

kann man dieses Problem mit Anonymen Methoden besser lösen , in der Art wie ....

Wir benutzen dafür ein Interface.
Wird dieses Freigegen (oder auf nil gesetzt) wird der alte Curser wieder hergestellt.

Hatte dazu mal mit dem Ansatz AOP (Aspect-oriented programming) experimentiert. Delphi bietet dazu den System.Rtti.TVirtualMethodInterceptor http://docwiki.embarcadero.com/RADSt...-Interzeptoren
Gerade zum Loggen Ideal.

Gibt ein paar schöne Videos dazu z.B. von Jeroen W. Pluimers https://wiert.me/2015/06/24/aspect-o...ing-in-delphi/

Gruss
Nathan

Hallo,

kennt jemand das Programm Calibre zur Ebook-Verwaltung? Da finde ich ist sowas ganz schön gelöst. Da kann man verschiedene Aufgaben anstarten und unten in der Statusleiste dreht sich ein kleines Zahnrad, dabeben eine Zahl mit der Anzahl der Aufgaben, die gerade im Hintergrund abgearbeitet werden.
Klingt man dann auf das Zahnrad, geht ein Fenster mit Detail-Infos auf.

Vieleicht kann man sowas ähnlich umsetzen, hier geht es ja nicht um Aufgaben o.ä., sondern um normale Funktionen/Prozeduren über deren Status informiert werden soll?

Vorhersehbare Fehler sollten eigentlich durch den Anwendungsfall verarbeitet werden.
Für sonstige Fehler gibts Tools wie madExcept oder Eurekalog.

Der Anwender erwartet aber nicht nur eine Rückmeldung zu Beginn oder Ende einer Funktion, sondern insbesondere wenn eine Funktion über längere Zeit läuft.