Sie sind aktuell nicht angemeldet.

Funktionen: Einloggen  |  Neu registrieren  |  Suchen

Re: Möglichkeiten zur Protokollierung
Autor: Manfred X
Datum: 09.10.12 17:35
Du kannst in einer globalen Variable der Protokoll-Klasse bei jedem Benachrichtigunsereignis den aktuellen Zeitpunktnotieren. Sollte ein Benachrichtigungsereignis weniger als z.B. eine Sekunde nach diesem notierten Zeitpunkt erforderlich werden - wird es nicht ausgelöst und der zugehörige Zeitpunkt wird nicht notiert. Eventuell kann man die Benachrichtigungsereignisse auch über einen Timer auslösen lassen (etwa 1x/Sekunde), falls seit letztem Tick mindestens ein Protokolleintrag hinzugefügt worden ist. Nach Abschluss der Operationen sollte in dem Fall die Bindung noch einmal aktualisiert weden, um sicher zu stellen, dass die angebundenen UI-Controls die aktuellen (zuletzt protokollierten) Werte anzeigen. Für solche Zwecke nutze ich derzeit SQL CE 3.5, (weil ich für diese DB mal eine einfache Verwaltungsklasse erstellt habe). Beitrag wurde zuletzt am 09.10.12 um 17:36:47 editiert.

Möglichkeiten zur Protokollierung
Autor: keco
Datum: 06.10.12 10:07
Hallo, ich überlege derzeit, wie man ein Protokollierungsverhalten implementieren könnte. Ich möchte dem Anwender eine Möglichkeit bietet einen Überblick über alle automatisiert (parallel) abgelaufenen Aufgaben und (parallel) verarbeiteten Daten zu bekommen. Erforderliche Kriterien: - Protokoll sollte Objekte entgegennehmen, die die Nachricht enthalten (bei Bedarf auch Bilder, usw.) - Protokoll sollte DataBinding unterstützen zur Darstellung in einem DataGridView - Protokoll sollte als Datei mit variablem Pfad gespeichert werden können (Serialization, Xml, ...) - Protokoll sollte threadsicher sein Bisher war ich so weit eine Klasse zu erstellen, die eine Shared Eigenschaft bereit stellt, damit ich von überall aus auf dieses Protokoll zugreifen kann. Das Problem stellt hierbei Multithreading dar. Da ich mehrere Tasks erstelle, die darauf zugreifen, werden so viele Einträge erstellt und hinzugefügt, dass der UI-Thread davon geflutet wird und keine sonstigen Windows-Meldungen entgegennimmt, also einfriert. Welche Möglichkeiten zur Protokollierung mit genannten Kriterien stellt das Framework zur Verfügung? Welche Ansätze zur Protokollierung wären geeignet, wenn es keine fertige Implementierung dazu gibt? Danke für Hinweise und Anregungen.

Re: Möglichkeiten zur Protokollierung
Autor: keco
Datum: 09.10.12 15:58
Ich möchte nochmal auf den Beitrag hinweisen und hoffe, dass jemand Antworten auf meine Fragen hat.

Re: Möglichkeiten zur Protokollierung
Autor: Manfred X
Datum: 09.10.12 16:26
Hallo! Unklar! Du schreibst, der UI-Thread wird von Meldungen geflutet. Warum? Wenn ein Thread irgendwo (Protokoll-)Werte einträgt, hat das mit UI eigentlich nix zu tun. (Eventuell Datenbindung zeitweise suspendieren.) Warum so viele Protokolleinträge? Sollte man diese Infos nicht in per ADO.Net über eine Datatable per gelegentlichem Update in eine Datenbank eintragen? Beschreibe die Zielstellung etwas genauer ... MfG Manfred

Re: Möglichkeiten zur Protokollierung
Autor: keco
Datum: 09.10.12 16:57
Der UI-Thread wird von Meldungen daher geflutet, weil die Protokolleinträge bisher im UI-Thread erzeugt werden. Die Tasks sollten schließlich unabhängig von einer Protokollierung sein, weshalb ich Events dafür erstellt habe, die im UI-Context aufgerufen werden. Ich hatte auch schon versucht die DataSource-Eigenschaft des DGV auf Nothing zu setzen, solange wie die Aufgaben ausgeführt werden, aber ohne Erfolg. Die Protokolleinträge kommen daher, dass relativ viele Operationen ausgeführt werden, die protokolliert werden sollen (je nach Detailstufe der Protokollierung). Das können bei höchster Stufe mehrere tausend sein. Ob man das über ADO.Net in eine Datenbank eintragen sollte weiß ich nicht, daher die Frage. Im schlimmsten Falle muss ich die Protokollierung stark zurücknehmen. Im Endeffekt sollen die Einträge in einer Datei auf der Festplatte liegen, die der Benutzer in einem einfachen Texteditor öffnen und nachvollziehen kann, was passiert ist. Die Datei wird bisher beim Beenden der Anwendung in entsprechender Formatierung erstellt.

Re: Möglichkeiten zur Protokollierung
Autor: Manfred X
Datum: 09.10.12 17:09
Die Threads sollten ihre Protokoll-Einträge falls möglich direkt in der Protokoll-Klasse anhängen. Innerhalb der Protokoll-Klasse kannst Du vielleicht dafür sorgen, dass zwischen den einzelnen Benachrichtigungsmeldungen an die Datenbindung eine Mindestzeitspanne eingehalten wird. Falls im Einzelfall mehrere tausend Protokolleinträge vorkommen können, würde ich eine Datenbank nutzen und dem User ein Formular zur Verfügung stellen, mit dem Filtern und Sortieren (eventuell auch Editieren einzelner Spalten oder Füllen einer Notizspalte) der Protokolltabelle möglich ist.

Re: Möglichkeiten zur Protokollierung
Autor: keco
Datum: 09.10.12 17:20
Dann muss ich mir eine geschickte Implementierung einfallen lassen, dass jeder Task Kenntnis von dem Protokoll hat. Beim Protokoll müsste ich in der Add-Methode SyncLock verwenden. Ich weiß aber nicht, was du mit folgendem Satz meinst: Zitat: Innerhalb der Protokoll-Klasse kannst Du vielleicht dafür sorgen, dass zwischen den einzelnen Benachrichtigungsmeldungen an die Datenbindung eine Mindestzeitspanne eingehalten wird. Denkst du da an einen Sleep-Befehl? Filtern und Sortieren ist für die zugrundeliegende Auflistung bereits vorhanden. Welche Datenbank könntest du dafür empfehlen? SQLLite?

Re: Möglichkeiten zur Protokollierung
Autor: keco
Datum: 10.10.12 17:30
Danke für deine Hilfe. Ich werde das erst einmal so versuchen. Wenn ich scheitere, dann werde ich schauen, dass ich das mit der Datenbank erledigen kann.

Sie sind nicht angemeldet! Um auf diesen Beitrag zu antworten oder neue Beiträge schreiben zu können, müssen Sie sich zunächst anmelden. Einloggen  |  Neu registrieren

Funktionen:  Zum Thema  |  Gesamtübersicht

Suchen