Ich habe ein Office-Add-In erstellt, das eine Instanz einer WPF-Anwendung enthält. Wenn der Benutzer auf Schaltflächen im Add-In klickt, starte ich verschiedene Fenster, indem ich Folgendes tue:
%Vor% Beim Erstellen von Ansichtsmodellen vor meinem Aufruf von wpfApp.Run() habe ich später mit dem aktuellen SynchronizationContext Probleme festgestellt. Die Antwort hier erklärt warum. Gibt es eine bessere Möglichkeit, WPF-Fenster von einem Office-Add-In aus zu starten?
Obwohl Arthurs Antwort darauf hinwies, warum das Problem auftrat, antwortete er nicht darauf, wie Daten von einer Host-Anwendung an ein Ansichtsmodell übergeben werden, während der Aufruf des Aufrufs des Modellmodellkonstruktors nach dem Aufruf von App.Run() erfolgt. Ich habe seitdem eine (sehr einfache) Lösung gefunden! Für jeden, der interessiert ist.
In App.xaml.cs:
%Vor%Beim Starten der App:
%Vor%Beachten Sie, dass der Start-URI in App.xaml entfernt werden muss. Diese sehr einfache Lösung ermöglicht es mir, Informationen an meine App zu übermitteln, erfordert aber gleichzeitig nicht, dass das Ansichtsmodell in einer "Nicht-WPF-Umgebung" erstellt wird und daher den Dispatcher usw. verwenden kann.
Ich habe noch nie ein Office-Add-In erstellt, aber ich habe WPF-Fenster in anderen Arten von Nicht-WPF-Anwendungen verwendet (Windows Forms, Bibliotheken zum Generieren von .XPS-Dateien aus WPF-Visuals usw.). Sie könnten den Ansatz versuchen, den ich in diese Frage vorgeschlagen habe . Es zeigt, wie ein Thread konfiguriert wird, damit die WPF-App ausgeführt werden kann. Wenn Sie sich den Code einer generierten App ("App.g.i.cs") einer WPF-App ansehen, scheint es so zu sein:
%Vor%Ich habe versucht, eine App aus einem Komponententest mit dem folgenden Code zu starten, und es funktionierte gut:
%Vor%BEARBEITEN
Wenn ich Ihren Code betrachte, glaube ich, dass die für den SynchronizationContext sinnvolle Aussage die Erstellung der Window-Instanz und nicht die Erstellung Ihres ViewModels ist (es sei denn, Ihr ViewModel beschäftigt sich mit View-Logik und instanziiert Controls, etwas, was es nicht tun sollte) . Sie können also versuchen, die Instanziierung des Fensters in den Thread der App zu verschieben. Etwas wie das:
%Vor%Hier ist eine Version, die eine Anwendungsdomäne verwendet, um die wpf-Anwendung mehrere Male unter separaten Anwendungsdomänen und UI-Threads zu öffnen. Benutzte dies in einem Büro Addin. Jedes Mal, wenn der Startup aufgerufen wird, erhalten Sie eine neue Anwendung. Habe nicht überprüft, wie gut die Threads beim Schließen der wpf-App heruntergefahren werden.
öffentliche Klasse WpfHelper {
%Vor%}
Tags und Links wpf c# mvvm ms-office office-addins