Eingabearchitektur für die Interoperabilität zwischen Windows Forms und WPF

Aktualisiert: November 2007

Die Interoperation zwischen WPF und Windows Forms erfordert, dass beide Technologien über die entsprechende Verarbeitung von Tastatureingaben verfügen. In diesem Thema wird beschrieben, wie diese Technologien die Tastatur- und Meldungsverarbeitung implementieren, um eine reibungslose Interoperation in hybriden Anwendungen zu ermöglichen.

Dieses Thema enthält folgende Unterabschnitte:

  • Nicht modale Formulare und Dialogfelder

  • Tastatur- und Meldungsverarbeitung von WindowsFormsHost

  • Tastatur- und Meldungsverarbeitung von ElementHost

Nicht modale Formulare und Dialogfelder

Rufen Sie die EnableWindowsFormsInterop-Methode für das WindowsFormsHost-Element auf, um ein nicht modales Formular oder Dialogfeld aus einer WPF-basierten Anwendung zu öffnen.

Rufen Sie die EnableModelessKeyboardInterop-Methode für das ElementHost-Steuerelement auf, um eine nicht modale WPF-Seite in einer Windows Forms-basierten Anwendung zu öffnen.

Tastatur- und Meldungsverarbeitung von WindowsFormsHost

Wenn die Tastatur- und Meldungsverarbeitung von Windows Forms von einer WPF-basierten Anwendung gehostet wird, umfasst sie Folgendes:

In den folgenden Abschnitten werden diese Teile des Vorgangs ausführlicher beschrieben.

Abrufen von Meldungen aus der Windows Presentation Foundation-Meldungsschleife

Die ComponentDispatcher-Klasse implementiert den Meldungsschleifen-Manager für WPF. Die ComponentDispatcher-Klasse stellt Hooks bereit, damit externe Clients Meldungen filtern können, bevor sie von WPF verarbeitet werden.

Die Implementierung der Interoperation behandelt das ComponentDispatcher.ThreadFilterMessage-Ereignis, mit dem Windows Forms-Steuerelemente Meldungen vor WPF-Steuerelementen verarbeiten können.

Windows Forms-Ersatzmeldungsschleife

Standardmäßig enthält die System.Windows.Forms.Application-Klasse die primäre Meldungsschleife für Windows Forms-Anwendungen. Während der Interoperation verarbeitet die Windows Forms-Meldungsschleife keine Meldungen. Deshalb muss diese Logik reproduziert werden. Der Handler für das ComponentDispatcher.ThreadFilterMessage-Ereignis führt die folgenden Schritte aus:

  1. Filtern der Meldung mithilfe der IMessageFilter-Schnittstelle.

  2. Aufruf der Control.PreProcessMessage-Methode.

  3. Übersetzen und Weiterleiten der Meldung, wenn erforderlich.

  4. Übergeben der Meldung ans Hostingsteuerelement, wenn keine anderen Steuerelemente die Meldung verarbeiten.

IKeyboardInputSink-Implementierung

Die Ersatzmeldungsschleife behandelt die Tastaturverwaltung. Deshalb ist die IKeyboardInputSink.TabInto-Methode der einzige IKeyboardInputSink-Member, der eine Implementierung in der WindowsFormsHost-Klasse erfordert.

Standardmäßig gibt die HwndHost-Klasse false für ihre IKeyboardInputSink.TabInto-Implementierung zurück. Dadurch wird das Wechseln mit der TAB-TASTE von einem Windows Forms-Steuerelement zu einem WPF-Steuerelement verhindert.

Die WindowsFormsHost-Implementierung der IKeyboardInputSink.TabInto-Methode führt die folgenden Schritte aus:

  1. Suchen des ersten oder letzten Windows Forms-Steuerelements, das im WindowsFormsHost-Steuerelement enthalten ist und den Fokus erhalten kann. Die Auswahl des Steuerelements hängt von Informationen zum Traversieren ab.

  2. Festlegen des Fokus auf das Steuerelement und Rückgabe von true.

  3. Rückgabe von false, wenn kein Steuerelement den Fokus erhalten kann.

WindowsFormsHost-Registrierung

Wenn das Fensterhandle für ein WindowsFormsHost-Steuerelement erstellt wird, ruft das WindowsFormsHost-Steuerelement eine interne statische Methode auf, die ihr Vorhandensein für die Meldungsschleife registriert.

Während der Registrierung untersucht das WindowsFormsHost-Steuerelement die Meldungsschleife. Wenn die Meldungsschleife nicht gestartet wurde, wird der ComponentDispatcher.ThreadFilterMessage-Ereignishandler erstellt. Es wird angenommen, dass die Meldungsschleife ausgeführt wird, wenn der ComponentDispatcher.ThreadFilterMessage-Ereignishandler angefügt wird.

Wenn das Fensterhandle zerstört wird, entfernt das WindowsFormsHost-Steuerelement sich aus der Registrierung.

Tastatur- und Meldungsverarbeitung von ElementHost

Wenn die Tastatur- und Meldungsverarbeitung von WPF von einer Windows Forms-Anwendung gehostet wird, besteht sie aus Folgendem:

In den folgenden Abschnitten werden diese Teile ausführlicher beschrieben.

Schnittstellenimplementierungen

In Windows Forms werden Tastaturmeldungen zum Fensterhandle des Steuerelements weitergeleitet, das den Fokus besitzt. Im ElementHost-Steuerelement werden diese Meldungen zum gehosteten Element weitergeleitet. Um dies zu erreichen, stellt das ElementHost-Steuerelement eine HwndSource-Instanz bereit. Wenn das ElementHost-Steuerelement den Fokus besitzt, leitet die HwndSource-Instanz die meisten Tastatureingaben weiter, sodass sie von der WPFInputManager-Klasse verarbeitet werden können.

Die HwndSource-Klasse implementiert die IKeyboardInputSink-Schnittstelle und die IKeyboardInputSite-Schnittstelle.

Die Tastaturinteroperation hängt von der Implementierung der OnNoMoreTabStops-Methode ab, um die mittels TAB-TASTE und Pfeiltasten vorgenommene Eingabe, die bewirkt, dass gehostete Elemente den Fokus verlieren, zu behandeln.

TAB-TASTE und Pfeiltasten

Die Windows Forms-Auswahllogik wird der IKeyboardInputSink.TabInto-Methode und der OnNoMoreTabStops-Methode zugeordnet, um die Navigation mit der TAB-TASTE und den Pfeiltasten zu implementieren. Durch das Überschreiben der Select-Methode wird diese Zuordnung erreicht.

Befehlstasten und Tastatureingaben im Dialogfeld.

Damit WPF die erste Möglichkeit erhält, Befehlstasten und Tastatureingaben im Dialogfeld zu verarbeiten, wird die Windows Forms-Befehlsvorverarbeitung mit der TranslateAccelerator-Methode verbunden. Durch das Überschreiben der Control.ProcessCmdKey-Methode werden die zwei Technologien verbunden.

Mit der TranslateAccelerator-Methode können die gehosteten Elemente jede Tastenmeldung behandeln, z. B. WM_KEYDOWN, WM_KEYUP, WM_SYSKEYDOWN oder WM_SYSKEYUP, einschließlich Befehlstasten, z. B. TAB-TASTE, EINGABETASTE, ESC-TASTE und Pfeiltasten. Wenn eine Tastenmeldung nicht behandelt wird, wird sie in der Windows Forms-Vorgängerhierarchie nach oben zur Behandlung gesendet.

Zugriffstastenverarbeitung

Um Zugriffstasten ordnungsgemäß zu verarbeiten, muss die Windows Forms-Zugriffstastenverarbeitung mit der WPFAccessKeyManager-Klasse verbunden werden. Außerdem müssen alle WM_CHAR-Meldungen ordnungsgemäß zu gehosteten Elementen weitergeleitet werden.

Da die HwndSource-Standardimplementierung der TranslateChar-Methode false zurückgibt, werden WM_CHAR-Meldungen unter Verwendung der folgenden Logik verarbeitet:

  • Die Control.IsInputChar-Methode wird überschrieben, um sicherzustellen, dass alle WM_CHAR-Meldungen zu gehosteten Elementen weitergeleitet werden.

  • Wenn die ALT-TASTE gedrückt wird, lautet die Meldung WM_SYSCHAR. Windows Forms führt keine Vorverarbeitung dieser Meldung durch die IsInputChar-Methode aus. Deshalb wird die ProcessMnemonic-Methode überschrieben, um eine registrierte Zugriffstaste von WPFAccessKeyManager abzufragen. Wenn eine registrierte Zugriffstaste gefunden wird, wird sie von AccessKeyManager verarbeitet.

  • Wenn die ALT-TASTE nicht gedrückt wird, wird die unbehandelte Eingabe von der WPF, InputManager-Klasse verarbeitet. Wenn die Eingabe eine Zugriffstaste ist, wird sie von AccessKeyManager verarbeitet. Das PostProcessInput-Ereignis wird für WM_CHAR-Meldungen behandelt, die nicht verarbeitet wurden.

Wenn der Benutzer die ALT-TASTE drückt, werden im ganzen Formular visuelle Hinweise für Zugriffstasten angezeigt. Um dieses Verhalten zu unterstützen, erhalten alle ElementHost-Steuerelemente im aktiven Formular WM_SYSKEYDOWN-Meldungen, unabhängig davon, welches Steuerelement den Fokus besitzt.

Meldungen werden nur an ElementHost-Steuerelemente im aktiven Formular gesendet.

Siehe auch

Konzepte

Exemplarische Vorgehensweise: Hosten eines zusammengesetzten Windows Forms-Steuerelements in Windows Presentation Foundation

Exemplarische Vorgehensweise: Hosten eines Windows Presentation Foundation-Steuerelements in Windows Forms

Übersicht über die Interaktion zwischen WPF und Win32

Referenz

EnableWindowsFormsInterop

EnableModelessKeyboardInterop

ElementHost

WindowsFormsHost