results loggen

[venice2]

Hat vielleicht jemand eine Logger unit mit der ich Resultate in eine Datei schreiben kann?
Falls nicht muss ich selbst was schreiben.

Delphi-Quellcode:

procedure Log(Text:string);
var
  F : TextFile;
  FileName : String;
  dt:string;
begin
  FileName := ExtractFilePath(ParamStr(0)) + 'Log.txt';
  AssignFile(F, FileName);
  if FileExists(FileName) then
    Append(F)
  else
    Rewrite(F);
    dt:=DateToStr(Date);
    dt:=dt+' / '+TimeToStr(Time);
  WriteLn(F, dt, ' : ', text);
  CloseFile(F);
end;

Das ist mir etwas zu einfach. (vielleicht mit mehr Möglichkeiten)
Vielleicht hat ja jemand etwas besseres (keine Komponente) und D2010

[himitsu]

DUnitX enthält eine Logger-Klasse, auch Indy liefert was mit (IdLog) und dann findest du im GetIt auch noch mit CodeSite Express eine Logging-Suite.

Und dann findet man noch viele andere Komponenten, auf diversen Plattformen, wie z.B. Log4Delphi.

[TurboMagic]

Wenn CodeSite nicht nach Geschmack sein sollte, dann gäbe es unter Windows noch OutputDebugString,
die Texte kann man z.B. auch mit der IDE in der Ereignisanzeige sehen.

Und nutzt man FMX gibt's noch d.log, welches cross platform fähig ist. Unter Windows nutzt die
wohl OutputDebugString unter Android kann man die Meldungen mit Monitor.bat aus dem SDK anzeigen
lassen.

[venice2]

Zitat:

Und dann findet man noch viele andere Komponente

Ich hatte betont das ich keine der vielen Komponenten verwenden möchte

Zitat:

Vielleicht hat ja jemand etwas besseres (keine Komponente) und D2010

Kein FMX Delphi 2010

DUnitX ist nicht für D2010 geeignet.
CodeSite Express 399 Dollar für ein Freeware Projekt?
Log4Delphi = Komponente.

Ok. Werde mich mal selber umsehen dachte jemand hatte etwas hier.
Über Google kann ich selber suchen da muss sich hier niemand drum bemühen.

[Lemmy]

schau dir mal Mormot an
https://github.com/synopse/mORMot

das sollte auch in D2010 laufen, da gibt es SynLog, den ganzen anderen Rest musst Du nicht nutzen...

[Jasocul]

Zitat von venice2:

Das ist mir etwas zu einfach. (vielleicht mit mehr Möglichkeiten)

Welche Möglichkeiten brauchst du denn?

[KodeZwerg]

Wie wäre es total oldschool, so in etwa:

Delphi-Quellcode:

procedure LogResult(const Text: string; const LogFile: string);
var
  myFile : TextFile;
begin
  AssignFile(myFile, FileName);
  if not FileExists(FileName) then
    ReWrite(myFile);
  Append(myFile);
  WriteLn(myFile, Text);
  CloseFile(myFile);
end;

Ps: Nur hier im Editor "entwickelt" ohne zu testen. Aber was ich damit meine/mache sollte hoffentlich klar sein.

//edit
Ups, jetzt erst gesehen das Du da Code rangepappt hattest, ich hatte Browser über Nacht offen...

[Moombas]

@venice2: Definiere generell mal deine Anforderung "mehr Möglichkeiten" und was du dir darunter vorstellst. Generell macht ja dein Code und der von Codezwerg das was du willst, das Result in einer Datei loggen.

Ich vermute mal du willst zusätzlich noch so etwas mit loggen, wie z.B.:

1. Welche Funktion hat das Logging aufgerufen?
2. Welche Variablen wurden übergeben?
3. ...

Jedoch solltest du das dann exakt definieren, dann kann dir sicherlich auch geholfen werden.

Je nach dem empfiehlt es sich auch im CSV-Format zu loggen (z.B.: Datum/Zeit;Funktionsname;Variablen;Result), dann kannst du das Log später (falls gewünscht) schöner in Excel auswerten.

[venice2]

Zitat:

Definiere generell mal deine Anforderung "mehr Möglichkeiten"

Hätte vielleicht fragen sollen was ist so am gebräuchlichsten um Anwendern mitzuteilen was gerade welche
Funktion aufgerufen und welches Ergebnis erzielt wurde.
Vielleicht ist dann doch mein kleines Schnipsel ausreichend.

Wollte keine Unruhe hier einbringen.

Zitat:

schau dir mal Mormot an

Habe ich.
Es sind Abhängigkeiten zu anderen Units nötig.
Man kann nicht einfach nur SynLog.pas verwenden.
Danke für den Tip.

Eventuell reicht einfach schon OutputDebugString wie TurboMagic schon sagte.

[Jasocul]

Ich glaube nicht, dass wegen deiner Frage hier Unruhe aufkommt.

Das Fehlerprotokoll ist ja üblicherweise nicht für den Anwender gedacht. Daher auch die Frage, welche Möglichkeiten DU haben möchtest.

Ich trage in meine Protokolle üblicherweise bei Excpetions auch den Text der Exception mit ein. Bei kontrollierten Fehlern ist natürlich eigener Text drin. Ich arbeite da gerne mit strukturierten Fehlernummer und kurzen Klartexten, falls das doch mal telefonisch übermittelt werden muss. Über die Fehlernummer weiß ich dann, an welcher Stelle das Problem aufgetreten ist. Man kann natürlich Unit, Prozedur, Funktion, etc. ausgeben. Alles Geschmackssache, aber für den Anwender eher verwirrend (ist zumindest meine Erfahrung).
Ein Zeitstempel ist natürlich selbstverständlich. Aber den hast du ja schon berücksichtigt.

Wenn Anwender die Protokolle auswerten können sollen, muss das ausführlicher und für Anwender verständlich geschrieben sein.