Wichtig! Bevor man diesen Ansatz jedoch verfolgt, sollte man versuchen die "Arbeit", die hier den Hauptthread belastet, auszulagern.
Bei meiner Untersuchung zu dem Thema bin ich auf einen Post von Dwayne Need gestoßen, der die Probleme und einen Lösungsansatz sehr gut erklären: Multithreaded UI: HostVisual
Damit wäre eigentlich schon alles gesagt..., aber: muss ich wirklich für jedes UI-Element, dass ich auslagern will so viel Code schreiben, bzw. muss ich immer den gleichen Code (Erzeugen des Threads und Kaskadieren der Visual Elemente) duplizieren, wenn ich ein MediaElement und eine Progressbar in verschiedenen Threads laufen lassen will? Vielleicht möchte man auch mal mehrere Elemente zusammen in einem Thread laufen lassen. - Mit anderen Worten: Ich will flexibler sein.
Meine Vorstellung ist also, ein Frameworkelement zu haben, das, egal was ich einbette, dies auf einem anderen Thread laufen lässt:
<VisualWrapper>
<Progressbar Value="{ProgressValue}" />
</VisualWrapper>
Und jetzt die Enttäuschung, für alle die bis hier gelesen haben: Eine saubere Lösung existiert meines Wissens dafür nicht... (jetzt wird's schmutzig),denn an und für sich wird der VisualTree rekursiv aufgebaut, d.h. der Content eines jeden Elements wird initialisiert, bevor dieser als Child an den Parent gehängt wird. Da wir diesen Mechanismus nicht kontrollieren können, müssen wir einen Weg finden, den Content zu übergeben, ohne diesen zu Initialisieren. Abhilfe schafft hier der XamlReader, dieser ermöglich es uns während der Programmlaufzet ein beliebiges Xaml zu instanziieren. Das Xaml übergeben wir dem Control dann als CDATA über ein Property:
<VisualWrapper>
<VisualWrapper.Content>
<![CDATA[
<ProgressBar
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
Height="20" Width="100" Value="{Binding ProgressValue}" />
]]>
</VisualWrapper.Content>
</VisualWrapper>
Im VisualWrapper erfolgt dann die Initialisierung in einem eigenen Thread über den XamlReader:
///Ich habe das ganze noch mit dem Code von Dwayne als Projekt zusammengefasst:/// Der Content als XAML-String, die Initialisierung erfolgt Postum /// public string Content { set { CreateThreadedChild(value); } } ////// erstellt das Child-Element (aus dem Content-String) auf einem seperaten Thread /// /// void CreateThreadedChild(string xaml) { // erstelle einen Thread für das Content-Element Thread thread = new Thread(new ParameterizedThreadStart(ContentWorkerThread)); thread.SetApartmentState(ApartmentState.STA); thread.Name = "GUI Thread"; thread.IsBackground = true; thread.Start(xaml); // warte bis der Thread signalisiert, dass er fertig ist mit der Initialisierung s_event.WaitOne(); } ////// XAML in WPF-Element umwandeln und auf die Oberfläche verlinken /// /// XAML-String des Content void ContentWorkerThread(object arg) { // erstelle das WPF-Element aus dem übergebenen XAML-String StringReader stringReader = new StringReader(arg.ToString()); XmlReader xmlReader = XmlReader.Create(stringReader); object content = XamlReader.Load(xmlReader); // nun wird die VisualTargetPresentationSource erzeugt (mit dem hier enthaltenen HostVisual als parent) VisualTargetPresentationSource visualTargetPS = new VisualTargetPresentationSource(_child); // der MainThread kann nun weiter arbeiten s_event.Set(); // nun wird der DataContext von der obersten Ebene auf das aktuelle Element geschleift // -> per Invoke, da beide Elemente auf verschiedenen Threads liegen // (alternativ kann man den DataContext übergeben, bzw. sich auch an das entsprechende event hängen) object parentContext = null; this.Dispatcher.Invoke(new Action(() => { parentContext = this.DataContext; })); // die PresentationSource bekommt nun den DataContext visualTargetPS.DataContext = parentContext; // hier wird nun der oberste Knoten im VisualTree gesetzt (unser Content) visualTargetPS.RootVisual = (Visual)content; // jetzt wird die (unendliche) Prozessschleife auf dem aktuellen Thread gestartet System.Windows.Threading.Dispatcher.Run(); }
Visual Studio Solution: TestGenericThreadedContainer
