![]() |
Programmablauf Protokollieren
Hallo,
bin auf der Suche nach einer Möglichkeit den Ablauf meines Programms zu Protokollieren. Dh. bestimmte Zugriffe auf Objekte, Rückgabewerte und Zustände die kritisch sind. Gibt es hierfür eine fertige Lösung die einfach zu integrieren ist? Danke |
AW: Programmablauf Protokollieren
Welche Delphi-Version hast Du denn?
Im XE sind CodeSite und AQTime enthalten. Damit kann man komfortabel Informationen ausgeben und Zeitanalysen durchführen. Als Billiglösung kannst Du Infos in ein Memo oder Textdatei schreiben. Ich könnte bei Bedarf eine alte Unit raussuchen, in der ich so etwas in Funktionen verpackt habe. Ganz einfach ist auch folgende temporäre Lösung für kurze Infos: Application.MainForm.Caption := 'Kurzinfo' + ' ' + Application.MainForm.Caption; Und zur Designzeit natürlich auch OutputDebugString... |
AW: Programmablauf Protokollieren
Callbacks? Mit Compilerdirektiven eingesetztes Logging?
|
AW: Programmablauf Protokollieren
Ich hab ne Weile
![]() Letztendlich habe ich das aber erst in eigener Unit gekapselt (300 $ sind ja kein Pappenstiel), und dann ersetzt durch diverse eigene Möglichkeiten (Logfile, OutputDebugString, AllocConsole + WriteLn, etc.). Gerade OutputDebugString ist für die Arbeit im Debugger schön einfach. Wichtig: wie Aphton schon schrieb, am besten mit Direktiven, um im kompilierten Release keine Laufzeiteinbußen dadurch zu haben. |
AW: Programmablauf Protokollieren
wie wäre es mit log4delphi?
![]() Das gibt es auch für andere Sprachen: log4net log4java log4php |
AW: Programmablauf Protokollieren
Zitat:
Zitat:
|
AW: Programmablauf Protokollieren
Zitat:
Ein möglichst umfassendes Logging klappt zum Beispiel nur mit Kompilaten, die Debug-Informationen beinhalten. Dann kompiliert man ein Logging-Build natürlich auch nicht mit Runtime Packages. Und schon lieferst Du auf einmal die fünffache Datenmenge aus. Das kannst Du vielleicht für Individualsoftware machen, aber nicht für die breite Masse. Außerdem steht da wieder die Performance-Frage. Wenn Du bis ins feinste Detail präpariest, also jeder einzelnen Methode/Funktion/Prozedur Enter- und Leave-Aufrufe hinzufügst, ist der Performance-Einbruch dadurch nicht mehr hinnehmbar, sobald es um irgend welche rechenintensiven Geschichten geht. Selbst wenn das logging komplett inline sein sollte, bedeutet "standardmäßig deaktiviert" immer noch etliche Abfragen. Nichts gegen eine ordentliche Fehlerbehandlung im Public Release, die ist im Gegenteil extrem wichtig, aber das komplette Logging gehört da - mMn nach - auf keinen Fall rein. Zumindest nicht so "absolut", wie Du es darstellt. |
AW: Programmablauf Protokollieren
Ohne Logfiles ist man immer darauf angewiesen einen Fehler reproduzieren zu können. Das funktioniert aber eigentlich nur, wenn die einzigen Beteiligten der Nutzer und Software sind. In dem Fall braucht man eigentlich nur Abweichungen von der Norm zu protokollieren.
Wer schon mal ein Projekt in der Automatisierungstechnik gehabt hat, weiß das Reproduzieren da schwierig bis unmöglich ist. Besonders wenn sämtliche Komponenten neu sind, schiebt sich da jeder gerne gegenseitig die Schuld zu. Hat man da ein Logfile, das sauber protokolliert, dass für die angelegten Eingangssignale / Barcodes / Config-Dateien / Serverrückgaben die richtigen Ausgangssignale gesetzt wurden, kann man sich zurücklehnen. Ansonsten ist erst mal immer die Software schuld. |
AW: Programmablauf Protokollieren
Zitat:
|
AW: Programmablauf Protokollieren
Zitat:
Zitat:
Delphi-Quellcode:
Das sollte nicht viele Zyklen brauchen.
if Assigned(MyLogFunction) then
... Es ist eher die Frage was geloggt wird. Und welche Informationen davon für den laufenden Betrieb relevant sind, wenn es zu einem Fehler kommt. Das Loggen an sich sollte in nahezu allen Fällen von der Rechnerzeit her kaum relevant sein, wenn man es auf diese Weise einbaut und deaktiviert hat. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 01:43 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz