Unterstützte Szenarien bei der Interoperation von Windows Presentation Foundation und Windows Forms

Artikel
08/20/2008

Aktualisiert: November 2007

WPF und Windows Forms bieten zwei verschiedene Architekturen zum Erstellen von Anwendungsschnittstellen. Der System.Windows.Forms.Integration-Namespace stellt Klassen bereit, die allgemeine Interoperationsszenarien unterstützen. Bei den zwei Hauptklassen, in denen die Interoperationsfunktionen implementiert sind, handelt es sich um WindowsFormsHost und ElementHost. In diesem Thema wird beschrieben, welche Interoperationsszenarien unterstützt werden und welche Szenarien nicht unterstützt werden.

Tipp

Besondere Beachtung findet das Szenario hybrider Steuerelemente. Bei einem hybriden Steuerelement ist ein Steuerelement einer Technologie in einem Steuerelement der anderen Technologie geschachtelt. Dies wird auch als geschachtelte Interoperation bezeichnet. Ein hybrides Steuerelement mit mehreren Ebenen verfügt über mehrere Schachtelungsebenen hybrider Steuerelemente. Ein Beispiel für eine geschachtelte Interoperation mit mehreren Ebenen ist ein Windows Forms-Steuerelement, das ein WPF-Steuerelement enthält, das wiederum ein anderes Windows Forms-Steuerelement enthält. Hybride Steuerelemente mit mehreren Ebenen werden nicht unterstützt.

Dieses Thema enthält folgende Abschnitte.

Windows Forms-Steuerelemente für Windows Presentation Foundation-basiertes Anwendungshosting
Windows Presentation Foundation-Steuerelemente für Windows Forms-basiertes Anwendungshosting
Verwandte Abschnitte

Windows Forms-Steuerelemente für Windows Presentation Foundation-basiertes Anwendungshosting

Die folgenden Interoperationsszenarien werden unterstützt, wenn ein WPF-Steuerelement ein Windows Forms-Steuerelement hostet:

Das WPF-Steuerelement kann mit XAML ein oder mehrere Windows Forms-Steuerelemente hosten.
Es kann mithilfe von Code ein oder mehrere Windows Forms-Steuerelemente hosten.
Es kann Windows Forms-Containersteuerelemente hosten, die andere Windows Forms-Steuerelemente enthalten.
Es kann ein Master-/Detailformular mit einem WPF-Master und Windows Forms-Details hosten.
Es kann ein Master-/Detailformular mit einem Windows Forms-Master und WPF-Details hosten.
Es kann ein oder mehrere ActiveX-Steuerelemente hosten.
Es kann ein oder mehrere zusammengesetzte Steuerelemente hosten.
Es kann mithilfe von Extensible Application Markup Language (XAML) hybride Steuerelemente hosten.
Es kann mithilfe von Code hybride Steuerelemente hosten.

Layoutunterstützung

In der folgenden Liste werden die bekannten Beschränkungen beschrieben, die bestehen, wenn das WindowsFormsHost-Element versucht, das zugehörige gehostete Windows Forms-Steuerelement in das WPF-Layoutsystem zu integrieren.

In einigen Fällen kann die Größe von Windows Forms-Steuerelementen nicht angepasst oder nur auf bestimmte Abmessungen festgelegt werden. Ein Windows FormsComboBox-Steuerelement unterstützt beispielsweise nur eine einzige Höhe, die durch den Schriftgrad des Steuerelements definiert wird. In einem dynamischen WPF-Layout, bei dem davon ausgegangen wird, dass Elemente vertikal gestreckt werden können, wird ein gehostetes ComboBox-Steuerelement nicht wie erwartet gestreckt.
Windows Forms-Steuerelemente können nicht gedreht oder verzerrt werden. Wenn Sie z. B. die Benutzeroberfläche um 90 Grad drehen, behalten gehostete Windows Forms-Steuerelemente ihre aufrechte Position.
In den meisten Fällen unterstützen Windows Forms-Steuerelemente keine proportionale Skalierung. Obwohl sich die Gesamtabmessungen des Steuerelements skalieren lassen, wird die Größe von untergeordneten Steuerelementen und Komponentenelementen des Steuerelements möglicherweise nicht wie erwartet angepasst. Diese Einschränkung hängt davon ab, in welchem Maße jedes Windows Forms-Steuerelement die Skalierung unterstützt.
In einer WPF-Benutzeroberfläche können Sie die z-Reihenfolge von Elementen zur Steuerung des Verhaltens beim Überlappen ändern. Ein gehostetes Windows Forms-Steuerelement wird in einem separaten HWND gezeichnet, d. h., es wird immer über WPF-Elementen gezeichnet.
Windows Forms-Steuerelemente unterstützen die automatische Skalierung auf der Grundlage des Schriftgrads. Wenn Sie in einer WPF-Benutzeroberfläche den Schriftgrad ändern, wird nicht das gesamte Layout angepasst. Möglicherweise werden jedoch einzelne Elemente dynamisch angepasst.

Ambient-Eigenschaften

Einige der Ambient-Eigenschaften von WPF-Steuerelementen verfügen über Windows Forms-Entsprechungen. Diese Ambient-Eigenschaften werden an die gehosteten Windows Forms-Steuerelemente weitergegeben und als öffentliche Eigenschaften für das WindowsFormsHost-Steuerelement verfügbar gemacht. Das WindowsFormsHost-Steuerelement übersetzt jede Ambient-Eigenschaft von WPF in die zugehörige Windows Forms-Entsprechung.

Weitere Informationen finden Sie unter Eigenschaftenzuordnung von Windows Forms und WPF.

Verhalten

In der folgenden Tabelle wird das Verhalten bei der Interoperation beschrieben.

Verhalten	Unterstützt	Nicht unterstützt
Transparenz	Bei der Wiedergabe von Windows Forms-Steuerelementen wird Transparenz unterstützt. Der Hintergrund des übergeordneten WPF-Steuerelements kann zum Hintergrund gehosteter Windows Forms-Steuerelemente werden.	Einige Windows Forms-Steuerelemente unterstützen Transparenz nicht. Das TextBox-Steuerelement und das ComboBox-Steuerelement sind zum Beispiel nicht transparent, wenn sie von WPF gehostet werden.
Vorrücken zum nächsten Tabstopp	Die Aktivierungsreihenfolge für gehostete Windows Forms-Steuerelemente ist identisch mit der Aktivierungsreihenfolge, die gilt, wenn diese Steuerelemente in einer Windows Forms-basierten Anwendung gehostet werden. Das Vorrücken zum nächsten Tabstopp von einem WPF-Steuerelement zu einem Windows Forms-Steuerelement mit der TAB-TASTE und den Tasten UMSCHALT+TAB funktioniert wie üblich. Windows Forms-Steuerelemente mit dem TabStop-Eigenschaftenwert false erhalten nicht den Fokus, wenn der Benutzer in den Steuerelementen zum nächsten Tabstopp vorrückt. Jedes WindowsFormsHost-Steuerelement verfügt über einen TabIndex-Wert, der bestimmt, wann das WindowsFormsHost-Steuerelement den Fokus erhält. Windows Forms-Steuerelemente, die in einem WindowsFormsHost-Container enthalten sind, liegen in der von der TabIndex-Eigenschaft angegebenen Reihenfolge vor. Wenn Sie vom letzten Registerkartenindex zum nächsten Tabstopp vorrücken, wird der Fokus auf das nächste WPF-Steuerelement festgelegt, sofern eines vorhanden ist. Falls kein anderes WPF-Steuerelement existiert, auf das der Fokus festgelegt werden kann, erfolgt beim Vorrücken zum nächsten Tabstopp eine Rückkehr zum ersten Windows Forms-Steuerelement in der Aktivierungsreihenfolge. TabIndex-Werte für Steuerelemente in WindowsFormsHost sind relativ zu gleichgeordneten Windows Forms-Steuerelementen, die im WindowsFormsHost-Steuerelement enthalten sind. Beim Vorrücken zum nächsten Tabstopp wird das steuerelementspezifische Verhalten berücksichtigt. Wenn Sie die TAB-TASTE z. B. in einem TextBox-Steuerelement mit dem AcceptsTab-Eigenschaftswert true drücken, wird nicht der Fokus verschoben, sondern ein Tabstoppzeichen in das Textfeld eingegeben.	Nicht zutreffend.
Navigation mit Pfeiltasten	Die Navigation mit den Pfeiltasten im WindowsFormsHost-Steuerelement erfolgt genauso wie in einem normalen Windows Forms-Containersteuerelement: Mit der NACH-OBEN-TASTE und der NACH-LINKS-TASTE wird das vorherige Steuerelement ausgewählt. Mit der NACH-UNTEN-TASTE und der NACH-RECHTS-TASTE wird das nächste Steuerelement ausgewählt. Wenn Sie im ersten Steuerelement innerhalb des WindowsFormsHost-Steuerelements die NACH-OBEN-TASTE und die NACH-LINKS-TASTE drücken, wird dieselbe Aktion ausgeführt wie mit der Tastenkombination UMSCHALT+TAB. Falls ein WPF-Steuerelement vorhanden ist, auf das der Fokus festgelegt werden kann, wird der Fokus aus dem WindowsFormsHost-Steuerelement heraus verschoben. Dieses Verhalten weicht vom standardmäßigen ContainerControl-Verhalten ab, da kein Umbruch auf das letzte Steuerelement erfolgt. Falls kein anderes WPF-Steuerelement existiert, auf das der Fokus festgelegt werden kann, kehrt der Fokus zum letzten Windows Forms-Steuerelement in der Aktivierungsreihenfolge zurück. Wenn Sie im letzten Steuerelements innerhalb des WindowsFormsHost-Steuerelements die NACH-UNTEN-TASTE und die NACH-RECHTS-TASTE drücken, wird dieselbe Aktion ausgeführt wie mit der TAB-TASTE. Falls ein WPF-Steuerelement vorhanden ist, auf das der Fokus festgelegt werden kann, wird der Fokus aus dem WindowsFormsHost-Steuerelement heraus verschoben. Dieses Verhalten weicht vom standardmäßigen ContainerControl-Verhalten ab, da kein Umbruch auf das erste Steuerelement erfolgt. Falls kein anderes WPF-Steuerelement existiert, auf das der Fokus festgelegt werden kann, kehrt der Fokus zum ersten Windows Forms-Steuerelement in der Aktivierungsreihenfolge zurück.	Nicht zutreffend.
Zugriffstasten	Die Zugriffstasten funktionieren abgesehen von den in der Spalte "Nicht unterstützt" angegebenen Ausnahmen wie üblich.	Technologieübergreifende doppelte Zugriffstasten funktionieren nicht wie gewöhnliche doppelte Zugriffstasten. Wenn eine Zugriffstaste technologieübergreifend dupliziert wird und dabei mindestens eine Zugriffstaste für ein Windows Forms-Steuerelement und eine andere für ein WPF-Steuerelement vorhanden ist, wird die Zugriffstaste stets dem Windows Forms-Steuerelement zugewiesen. Beim Drücken der doppelten Zugriffstaste schaltet der Fokus nicht zwischen den Steuerelementen um.
Tastenkombination	Die Tastenkombinationen funktionieren abgesehen von den in der Spalte "Nicht unterstützt" angegebenen Ausnahmen wie üblich.	Windows Forms-Tastenkombinationen, die in der Vorverarbeitungsphase behandelt werden, haben immer Vorrang vor WPF-Tastenkombinationen. Wenn Sie beispielsweise für ein ToolStrip-Steuerelement die Tastenkombination STRG+S definiert haben und an STRG+S ein WPF-Befehl gebunden ist, wird der ToolStrip-Steuerelementhandler unabhängig vom Fokus immer zuerst aufgerufen. Die vom KeyDown-Ereignis behandelten Windows Forms-Tastenkombinationen werden in WPF zuletzt verarbeitet. Sie können dieses Verhalten verhindern, indem Sie die IsInputKey-Methode des Windows Forms-Steuerelements überschreiben oder das PreviewKeyDown-Ereignis behandeln. Geben Sie an, dass die IsInputKey-Methode true zurückgibt, oder legen Sie den Wert der PreviewKeyDownEventArgs.IsInputKey-Eigenschaft im PreviewKeyDown-Ereignishandler auf true fest.
AcceptsReturn, AcceptsTab und anderes steuerelementspezifisches Verhalten	Eigenschaften, die das standardmäßige Tastaturverhalten ändern, funktionieren wie üblich, wobei davon ausgegangen wird, dass das Windows Forms-Steuerelement die IsInputKey-Methode überschreibt, sodass true zurückgegeben wird.	Windows Forms-Steuerelemente, die das standardmäßige Tastaturverhalten durch Behandeln des KeyDown-Ereignisses ändern, werden im WPF-Hoststeuerelement zuletzt verarbeitet. Da diese Steuerelemente zuletzt verarbeitet werden, können sie zu unerwartetem Verhalten führen.
Enter-Ereignis und Leave-Ereignis	Wird der Fokus nicht auf das aufnehmende ElementHost-Steuerelement verschoben, werden das Enter-Ereignis und das Leave-Ereignis wie üblich ausgelöst, wenn sich der Fokus in einem einzelnen WindowsFormsHost-Steuerelement ändert.	Bei folgenden Fokusänderungen werden das Enter-Ereignis und das Leave-Ereignis nicht ausgelöst: Von innerhalb nach außerhalb eines WindowsFormsHost-Steuerelements. Von außerhalb nach innerhalb eines WindowsFormsHost-Steuerelements. Außerhalb eines WindowsFormsHost-Steuerelements. Von einem Windows Forms-Steuerelement, das in einem WindowsFormsHost-Steuerelement gehostet wird, zu einem ElementHost-Steuerelement, das innerhalb desselben WindowsFormsHost gehostet wird.
Multithreading	Alle Arten von Multithreading werden unterstützt.	Sowohl bei der Windows Forms-Technologie als auch bei der WPF-Technologie wird von einem Singlethread-Parallelitätsmodell ausgegangen. Während des Debuggens lösen von anderen Threads stammende Aufrufe von Frameworkobjekten zur Durchsetzung dieser Anforderung eine Ausnahme aus.
Sicherheit	Alle Interoperationsszenarien setzen volle Vertrauenswürdigkeit voraus.	Bei teilweiser Vertrauenswürdigkeit sind keine Interoperationsszenarien zulässig.
Eingabehilfen	Alle Eingabehilfenszenarien werden unterstützt. Hilfstechnologieprodukte funktionieren korrekt, wenn sie für Hybridanwendungen verwendet werden, die sowohl Windows Forms-Steuerelemente als auch WPF-Steuerelemente enthalten.	Nicht zutreffend.
Zwischenablage	Alle Zwischenablageoperationen funktionieren wie üblich. Hierzu zählen auch das Ausschneiden und Einfügen zwischen Windows Forms-Steuerelementen und WPF-Steuerelementen.	Nicht zutreffend.
Drag & Drop-Feature	Alle Drag & Drop-Operationen funktionieren wie üblich. Hierzu zählen auch Operationen zwischen Windows Forms-Steuerelementen und WPF-Steuerelementen.	Nicht zutreffend.

Windows Presentation Foundation-Steuerelemente für Windows Forms-basiertes Anwendungshosting

Die folgenden Interoperationsszenarien werden unterstützt, wenn ein Windows Forms-Steuerelement ein WPF-Steuerelement hostet:

Hosten eines oder mehrerer WPF-Steuerelemente mit Code.
Zuordnen eines Eigenschaftenblatts zu einem oder mehreren gehosteten WPF-Steuerelementen.
Hosten einer oder mehrerer WPF-Seiten in einem Formular.
Starten eines WPF-Fensters.
Hosten eines Master-/Detailformulars mit einem Windows Forms-Master und WPF-Details.
Hosten eines Master-/Detailformulars mit einem WPF-Master und Windows Forms-Details.
Hosten von benutzerdefinierten WPF-Steuerelementen.
Hosten von hybriden Steuerelementen.

Ambient-Eigenschaften

Einige der Ambient-Eigenschaften von Windows Forms-Steuerelementen verfügen über WPF-Entsprechungen. Diese Ambient-Eigenschaften werden an die gehosteten WPF-Steuerelemente weitergegeben und als öffentliche Eigenschaften für das ElementHost-Steuerelement verfügbar gemacht. Das ElementHost-Steuerelement übersetzt jede Ambient-Eigenschaft von Windows Forms in die zugehörige WPF-Entsprechung.

Weitere Informationen finden Sie unter Eigenschaftenzuordnung von Windows Forms und WPF.

Verhalten

In der folgenden Tabelle wird das Verhalten bei der Interoperation beschrieben.

Verhalten	Unterstützt	Nicht unterstützt
Transparenz	Bei der Wiedergabe von WPF-Steuerelementen wird Transparenz unterstützt. Der Hintergrund des übergeordneten Windows Forms-Steuerelements kann zum Hintergrund gehosteter WPF-Steuerelemente werden.	Nicht zutreffend.
Multithreading	Alle Arten von Multithreading werden unterstützt.	Sowohl bei der Windows Forms-Technologie als auch bei der WPF-Technologie wird von einem Singlethread-Parallelitätsmodell ausgegangen. Während des Debuggens lösen von anderen Threads stammende Aufrufe von Frameworkobjekten zur Durchsetzung dieser Anforderung eine Ausnahme aus.
Sicherheit	Alle Interoperationsszenarien setzen volle Vertrauenswürdigkeit voraus.	Bei teilweiser Vertrauenswürdigkeit sind keine Interoperationsszenarien zulässig.
Eingabehilfen	Alle Eingabehilfenszenarien werden unterstützt. Hilfstechnologieprodukte funktionieren korrekt, wenn sie für Hybridanwendungen verwendet werden, die sowohl Windows Forms-Steuerelemente als auch WPF-Steuerelemente enthalten.	Nicht zutreffend.
Zwischenablage	Alle Zwischenablageoperationen funktionieren wie üblich. Hierzu zählen auch das Ausschneiden und Einfügen zwischen Windows Forms-Steuerelementen und WPF-Steuerelementen.	Nicht zutreffend.
Drag & Drop-Feature	Alle Drag & Drop-Operationen funktionieren wie üblich. Hierzu zählen auch Vorgänge zwischen Windows Forms-Steuerelementen und WPF-Steuerelementen.	Nicht zutreffend.