in Fenster einen Log live anzeigen

  • WPF

Es gibt 8 Antworten in diesem Thema. Der letzte Beitrag () ist von thefiloe.

    in Fenster einen Log live anzeigen

    Hallo,

    ich möchte für ein Programm in WPF ein extra Fenster haben, in dem ich einen Log anzeige, der von verschiedenen Funktionen ergänzt wird.

    Ich hätte da schon 2 Ideen wie ich das lösen könnte, aber mir kommen die nicht wirklich sauber vor:

    - Das LogFenster wird beim Programmstart initialisiert und überwacht ein Logfile und ließt dies bei einer Dateigrößenänderung aus und aktualisiert das Fenster.

    - Das LogFenster wird beim Programmstart initialisiert und dann als Parameter an die Funktionen die einen Log ausgeben übergeben und Per Logfenster.Dispatcher.Invoke werden dann das LogFile und der Listview ergänzt, hätte auch den Vorteil, dass es nicht zu gleichzeitigen Dateizugriffen kommt.


    Hättet ihr eine saubere Lösung dafür?

    Danke im Voraus!
    Nene viel zu kompliziert!
    Mach nen ViewModel und erstelle eine Instanz in deinem MainViewModel. Die Instanz wird an den DataContext des Fensters gebunden.
    Jetzt kannste von überal einfach über MainViewModel.LogViewModel.Log("Das ist ein Log eintrag") aufrufen. (wie du die nachrichten intern verwendest ist deine Sache)
    Ich würde einen DataGrid verwenden. Dort kannst du dann einfach eine ObservableCollection dranhängen und z.B. auch Spalten wie den Ort wo der Fehler oder was auch immer auftritt usw. (ähnlich wie bei Visual studio)


    Opensource Audio-Bibliothek auf github: KLICK, im Showroom oder auf NuGet.

    thefiloe schrieb:

    Jetzt kannste von überal einfach über MainViewModel.LogViewModel.Log("Das ist ein Log eintrag") aufrufen.
    "Von überall" geht das mitnichten, es sei denn, das MainViewModel liegt in einer Shared Instanz, oder alle Zugriffe laufen über einen Locator.

    Dann aber ists ungefähr, was auch ich vorgeschlagen habe, nämlich die Bindings reagieren ja auf die PropertyChanged-Events, die vom LogViewModel ausgelöst werden.


    high152 schrieb:

    Mit MVVM beschäftige ich mich erst noch, ...
    Das hat glaub kein Sinn. Es ist dringend geraten, von Anfang an nach MVVM zu entwickeln.
    Andernfalls kannste deine Anwendung neu schreiben, wenn du iwann mal mit MVVM anfängst.
    Da zu 95% davon auszugehen ist, dass du sie nicht neuschreiben wirst, wird dein Ergebnis also Schrott sein und bleiben.
    Bei dir vielleicht ;)
    Die Bedingung ist ja die Highlander-Bedingung: "Es kann nur einen geben" ;). Singleton reicht da für Wpf kaum aus, denn Xaml kann so ohne weiteres nicht einen Singleton abrufen (erst recht nicht "von überall") - wie gesagt: meist kommt noch der Locator-Pattern hinzu.
    Und ich habe mir noch ein anderes Modell zurechtgelegt, welches die Highlander-Bedingung in eine Basisklasse verlegt, sodaß bei mir jedes MainViewmodel nur davon zu erben braucht.
    Da bist du auf dem Holzweg. WPF kann auf Singleton gehen. Nur das Codebehind als Singleton wird kompliziert aber auch möglich.
    Laut MS sollten die ViewModels so aufgebaut sein, dass es ein MainViewModel mit EINER Instanz gibt welche wiederum die anderen ViewModels als Instanzen verwaltet.
    Z.B. Wenn du ein Fenster mit Import, Kalkulation und Einstellungen hast wirst du simpel ausgedrückt im MainViewModel jeweils für alle 3 Gebiete eine ViewModelInstanz vom entsprechenden Typ haben.

    Dann gibt es noch Kleinigkeiten wie z.B. die Instanzen über Lazyload usw. anzulegen oder jedem ViewModel eine ViewModelBase zu geben welche die MainViewModel Instanz behinhaltet usw...


    Opensource Audio-Bibliothek auf github: KLICK, im Showroom oder auf NuGet.