SplashScreen mit Feedback

    • WPF

      SplashScreen mit Feedback

      An einen SplashScreen stellt man folgende Anforderungen:
      • er soll im Nebenthread laufen, damit der vollständig mit Startup beschäftigte MainThread ihn nicht blockiert.
      • Es soll einen Kommunikations-Mechanismus geben, über den der MainThread Nachrichten über den Fortschritt des eigentlichen StartVorgangs der Anwendung senden und anzeigen kann.
      Ich stelle hier eine Lösung vor, die im Codebehind der Application.Xaml angesiedelt ist, in der Application.OnStartup-Überschreibung:

      VB.NET-Quellcode

      1. Imports System.Threading
      3. Class Application
      4. Private _Splash As Splash
      5. Private _SplashVM As SplashVM
      7. Protected Overrides Sub OnStartup(e As StartupEventArgs)
      8. MyBase.OnStartup(e)
      9. StartSplash()
      10. Thread.Sleep(1300) '"aufwändige Initialisierung"
      11. TrySplashMessage("erste Meldung vom LadeProzess")
      12. Thread.Sleep(1000)
      13. TrySplashMessage("oh, ich muß noch bisserl überlegen")
      14. Thread.Sleep(1000)
      15. Dim w = New MainWindow()
      16. AddHandler w.ContentRendered, Sub(s, cre) _Splash.Dispatcher.BeginInvoke(DirectCast(AddressOf CleanUpSplash, Action))
      17. 'AddHandler w.ContentRendered, Sub(s, cre) _Splash.DispatchInvoke(AddressOf CleanUpSplash)
      18. MainWindow = w
      19. w.Show()
      20. End Sub
      21. ''' <summary> splashMessage will be omitted, if the splash isn't ready yet </summary>
      22. Private Sub TrySplashMessage(splashMessage As String)
      23. If _Splash Is Nothing Then Return
      24. If _SplashVM Is Nothing Then
      25. _SplashVM = DirectCast(_Splash.Dispatcher.Invoke(DirectCast(Function() _Splash.DataContext, Func(Of Object))), SplashVM)
      26. '_SplashVM = DirectCast(_Splash.DispatchInvoke(Function() _Splash.DataContext), SplashVM)
      27. End If
      28. 'implement your own Progress-Reporting, e.g. with Progressbars, slide-shows or whatever
      29. _SplashVM.Text = splashMessage
      30. End Sub
      31. Private Sub StartSplash()
      32. Dim thr = New Thread(Sub()
      33. _Splash = New Splash()
      34. _Splash.ShowDialog()
      35. End Sub)
      36. thr.Priority = ThreadPriority.Highest
      37. thr.SetApartmentState(ApartmentState.STA)
      38. thr.Start()
      39. End Sub
      40. Private Sub CleanUpSplash()
      41. _Splash.Close()
      42. 'making objects inaccessible from code enables the GarbageCollector to clean them up
      43. _Splash = Nothing
      44. _SplashVM = Nothing
      45. End Sub
      46. End Class
      Um das zu verwenden muß man von der üblichen Architektur bisserl abweichen - vor allem kann man nun nicht mehr im Application.Xaml den StartupUri angeben. Dies deshalb, weil man ja codeseitige Kontrolle braucht über beide Windows: SplashWindow und MainWindow, damit man im MainWindow.ContentRendered-Event Zugriff auf den Splash hat, um ihn zu schließen.

      Erläuterung zum Code
      Im OnStartup() wird logischerweise als erstes der Splash gestartet, dann folgt die aufwändige Initialisierung mit gelegentlichen Meldungen an den Splash, dann wird das MainWindow erzeugt.
      In dessen ContentRendered-Event (Zeile#16) wird der SplashScreen dann geschlossen und aufgeräumt.
      Der Splash wird übrigens durch 2 Variablen repräsentiert: durch Splash (das in Xaml erstellte Window) und durch SplashVM, das codierte ViewModel des Splashes.
      Die Kommunikation läuft übers Viewmodel, und wie daran gebunden wird steht auf einem anneren Blatt (im Xaml, um genau zu sein ;)).
      Heikelster Punkt ist vlt. Zeile#25: da wird über den Dispatcher des Splashes mittels anonymer Function sein DataContext abgerufen, damit das Splash-Viewmodel hier verfügbar ist für die Kommunikation.
      Invoking über den Dispatcher ist von Microsoft bisserl misdesigned, sodass immer einen Cast erforderlich ist. (Ich vermute ja, die haben da intern eine "Behörde für umständliches Design" - ähnlich dem britischen Ministry of Silly Walks ;).)
      Jedenfalls habich gleich paar Extensions geproggt, mit denen man auch einfacher dispatchen kann (aber hier auskommentiert).

      Eine noch eigenartigere Eigenart ist, dass im Application.OnStartup() die Resourcen der Application-Klasse u.U. noch gar nicht initialisiert sind. Das ist problematisch, denn dann kann das MainWindow nicht angezeigt werden, falls es eine der Application-Resourcen benötigt.
      Lösung: Auslagern der Application-Resourcen in ResourceDictionaries:

      XML-Quellcode

      1. <Application x:Class="Application"
      2. xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
      3. xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
      4. <!-- hier kein StartupUri! -->
      5. <Application.Resources>
      6. <ResourceDictionary>
      7. <ResourceDictionary.MergedDictionaries>
      8. <ResourceDictionary Source="ResourceDicts/Other.xaml"/>
      9. </ResourceDictionary.MergedDictionaries>
      10. </ResourceDictionary>
      11. </Application.Resources>
      12. </Application>
      Keine Ahnung, warum das hilft, aber es hilft ?(. Ist auch garnet schlecht, denn einen SplashScreen brauchen eh nur umfangreichen Anwendungen, bei denen es sowieso geraten ist, die vmtl. mannigfaltigen Anwendungs-Resourcen sinnvoll in ResourceDictionaries zu strukturieren.
      Dateien

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „ErfinderDesRades“ ()

    Facebook
    Telefonspende