Einzelnen Beitrag anzeigen

mensch72

Registriert seit: 6. Feb 2008
838 Beiträge
 
#13

AW: Programmhelferlein...Logger

  Alt 17. Mär 2017, 18:22
wir verwenden lokal intern unter Windows was eigenes, was als KernelTreiber mit UserModeApi (multi)threadsafe und echtzeitfähig Messages beliebiger Art von verschiedenen Prozessen entgegen nimmt, und diese "serialisiert" loggt und/oder an eine MonitorAnwendung weitergibt. Wir haben uns das sehr stark am PCAP Treiberkonzept von WireShark orientiert.

Da wir aber bei Kundensystemen und bei FMX mit dem "Treiberkonzept" nicht mehr weiterkommen, haben wir uns weil wir eh alles von TMS haben, für deren Logging entschieden.
http://www.tmssoftware.com/site/tmslogging.asp
-> einzeln 75€!, sorry dafür kann das auch ein Hobbyentwickler nicht selbst programmieren, da lohnt allein der Kauf um mal in diese Sourcen schauen zu können

"Idee 1":
Das einzige was wir bei TMS aktuell vermissen, ist ein ThreadSafeTrigger, wo das MonitorProgramm vorab "regelbasiert/variabel" sowas wie SoftBreakPoints definieren kann.
Also im Prinzip kommen stets alle LogAufrufe möglichst schnell zurück, ausser das LogModul erkennt eine TriggerBedingung und hält wenn so aktiviert damit das LaufendeProgramm(bzw. einen Thread) an, bis per GUI-Interaktion im MonitorProgramm die "Weiter" Freigabe (manuell) erfolgt.

"Idee 2":
Aufrufe des LogModuls als "Logger.Msg(LogLevel,LogString)" kosten wenn nicht benötigt sehr viel Zeit, da man ja stets alle "Strings" schon zusammensetzt und erzeugt, ohne zu wissen ob diese überhaupt gebraucht werden... besser man realsiert stets es per "if Logger.IsActive(LogLevel) then begin LogString:=....; Logger.Msg(LogLevel,LogString); end;"

"Idee 3":
RemoteDesktop,Teamviewer,VNC,... alles schön und gut, aber wir bauen in unsere Software mittlerweile stets eine eigene Lösung ein, um ScreenShots von unserem Programm zusammen mit LogDaten zu bekommen. Nicht alle Anwender/Kunden wollen&nutzen das, aber wer uns per zeitlich begrenztem OptIn im Programm die Erlaubnis erteilt, profitiert von schnellerem und einfacherem Support und spart seine wie unsere Zeit


=> ja, es macht bei RealTime Anforderungen Sinn, eine LogLösung auch mit viel Zeit selbst "optimal" zu realisieren und zu implementieren
=> nein, es macht keinen Sinn für 0815 Desktopanwendungen sowas nochmal selbst zu basteln, wenn es da über jahre gewachsene Tools mit Erfahrung über OS-Versionen hinweg gibt, welche mit unter 100€ auch für Hobbyentwickler sich über die Zeitersparnis und garantiertem Support rechnen
  Mit Zitat antworten Zitat