Condividi tramite

Architettura di input per l'interoperabilità tra Windows Form e WPF

  • Articolo

L'interoperabilità tra WPF e Windows Form richiede che entrambe le tecnologie dispongano dell'elaborazione dell'input da tastiera appropriata. Questo argomento descrive in che modo queste tecnologie implementano l'elaborazione di tastiera e messaggi per consentire l'interoperabilità uniforme nelle applicazioni ibride.

In questo argomento sono contenute le seguenti sottosezioni:

  • Moduli e finestre di dialogo non modali

  • Elaborazione di tastiera e messaggi WindowsFormsHost

  • Elaborazione di tastiera e messaggi ElementHost

Moduli e finestre di dialogo non modali

Chiamare il EnableWindowsFormsInterop metodo sull'elemento WindowsFormsHost per aprire una maschera o una finestra di dialogo senza modalità da un'applicazione basata su WPF.

Chiamare il EnableModelessKeyboardInterop metodo nel ElementHost controllo per aprire una pagina WPF senza modalità in un'applicazione basata su Windows Form.

Elaborazione di tastiera e messaggi WindowsFormsHost

Se ospitato da un'applicazione basata su WPF, Windows Form l'elaborazione di tastiera e messaggi è costituita dai seguenti elementi:

Le sezioni seguenti descrivono queste parti del processo in modo più dettagliato.

Acquisizione di messaggi dal ciclo di messaggi WPF

La ComponentDispatcher classe implementa la gestione cicli di messaggi per WPF. La ComponentDispatcher classe fornisce hook per consentire ai client esterni di filtrare i messaggi prima che WPF li elabora.

L'implementazione dell'interoperabilità gestisce l'eventoComponentDispatcher.ThreadFilterMessage, che consente ai controlli Windows Form di elaborare i messaggi prima dei controlli WPF.

Ciclo di messaggi surrogati Windows Form

Per impostazione predefinita, la System.Windows.Forms.Application classe contiene il ciclo di messaggi primario per le applicazioni Windows Form. Durante l'interoperabilità, il ciclo di messaggi Windows Form non elabora i messaggi. Pertanto, questa logica deve essere riprodotta. Il gestore per l'evento ComponentDispatcher.ThreadFilterMessage esegue i passaggi seguenti:

  1. Filtra il messaggio usando l'interfaccia IMessageFilter .

  2. Chiama il Control.PreProcessMessage metodo .

  3. Converte e invia il messaggio, se necessario.

  4. Passa il messaggio al controllo host, se nessun altro controllo elabora il messaggio.

Implementazione di IKeyboardInputSink

Il ciclo di messaggi surrogati gestisce la gestione della tastiera. Pertanto, il IKeyboardInputSink.TabInto metodo è l'unico IKeyboardInputSink membro che richiede un'implementazione nella WindowsFormsHost classe .

Per impostazione predefinita, la HwndHost classe restituisce false per l'implementazione IKeyboardInputSink.TabInto . Ciò impedisce la tabulazione da un controllo WPF a un controllo Windows Form.

L'implementazione WindowsFormsHost del IKeyboardInputSink.TabInto metodo esegue i passaggi seguenti:

  1. Trova il primo o l'ultimo WindowsFormsHost controllo Windows Form contenuto dal controllo e che può ricevere lo stato attivo. La scelta del controllo dipende dalle informazioni di attraversamento.

  2. Imposta lo stato attivo sul controllo e restituisce true.

  3. Se nessun controllo può ricevere lo stato attivo, restituisce false.

Registrazione di WindowsFormsHost

Quando viene creato l'handle di finestra di un WindowsFormsHost controllo, il WindowsFormsHost controllo chiama un metodo statico interno che registra la sua presenza per il ciclo di messaggi.

Durante la registrazione, il WindowsFormsHost controllo esamina il ciclo di messaggi. Se il ciclo di messaggi non è stato avviato, viene creato il ComponentDispatcher.ThreadFilterMessage gestore eventi. Il ciclo di messaggi viene considerato in esecuzione quando il ComponentDispatcher.ThreadFilterMessage gestore eventi è associato.

Quando l'handle della finestra viene eliminato definitivamente, il WindowsFormsHost controllo rimuove se stesso dalla registrazione.

Elaborazione di tastiera e messaggi ElementHost

Se ospitato da un'applicazione Windows Form, l'elaborazione di tastiera e messaggi WPF è costituita dai seguenti elementi:

Le sezioni seguenti descrivono queste parti in modo più dettagliato.

Implementazioni dell'interfaccia

In Windows Form, i messaggi della tastiera vengono indirizzati all'handle della finestra del controllo con stato attivo. ElementHost Nel controllo questi messaggi vengono indirizzati all'elemento ospitato. A tale scopo, il controllo fornisce un'istanza ElementHostHwndSource di . Se il ElementHost controllo ha lo stato attivo, l'istanza instrada la HwndSource maggior parte dell'input da tastiera in modo che possa essere elaborata dalla classe WPF InputManager .

La HwndSource classe implementa le IKeyboardInputSink interfacce e IKeyboardInputSite .

L'interoperabilità della tastiera si basa sull'implementazione del OnNoMoreTabStops metodo per gestire l'input del tasto TAB e del tasto freccia che sposta lo stato attivo fuori dagli elementi ospitati.

Tabulazione e tasti di direzione

La logica di selezione Windows Form viene mappata ai IKeyboardInputSink.TabInto metodi e OnNoMoreTabStops per implementare lo spostamento tramite TAB e tasti di direzione. L'override del metodo esegue questo Select mapping.

Chiavi di comando e chiavi della finestra di dialogo

Per offrire a WPF la prima opportunità di elaborare i tasti di comando e i tasti di dialogo, Windows Form pre-elaborazione dei comandi è connesso al TranslateAccelerator metodo . L'override del Control.ProcessCmdKey metodo connette le due tecnologie.

Con il TranslateAccelerator metodo , gli elementi ospitati possono gestire qualsiasi messaggio di chiave, ad esempio WM_KEYDOWN, WM_KEYUP, WM_SYSKEYDOWN o WM_SYSKEYUP, inclusi i tasti di comando, ad esempio TAB, INVIO, ESC e tasti di direzione. Se un messaggio chiave non viene gestito, viene inviato il Windows Form gerarchia predecessore per la gestione.

Elaborazione acceleratore

Per elaborare correttamente gli acceleratori, Windows Form l'elaborazione dell'acceleratore deve essere connessa alla classe WPFAccessKeyManager. Inoltre, tutti i messaggi WM_CHAR devono essere indirizzati correttamente agli elementi ospitati.

Poiché l'implementazione predefinita HwndSource del TranslateChar metodo restituisce false, i messaggi WM_CHAR vengono elaborati usando la logica seguente:

  • Viene eseguito l'override del Control.IsInputChar metodo per assicurarsi che tutti i messaggi WM_CHAR vengano inoltrati agli elementi ospitati.

  • Se viene premuto IL tasto ALT, il messaggio viene WM_SYSCHAR. Windows Form non pre-elabora questo messaggio tramite il IsInputChar metodo . Di conseguenza, il ProcessMnemonic metodo viene sottoposto a override per eseguire una query in WPF AccessKeyManager per un acceleratore registrato. Se viene trovato un acceleratore registrato, AccessKeyManager lo elabora.

  • Se il tasto ALT non viene premuto, la classe WPF InputManager elabora l'input non gestito. Se l'input è un acceleratore, AccessKeyManager lo elabora. L'evento PostProcessInput viene gestito per i messaggi WM_CHAR non elaborati.

Quando l'utente preme il tasto ALT, i segnali visivi dell'acceleratore vengono visualizzati nell'intero form. Per supportare questo comportamento, tutti i ElementHost controlli del modulo attivo ricevono WM_SYSKEYDOWN messaggi, indipendentemente dal controllo con stato attivo.

I messaggi vengono inviati solo ai ElementHost controlli nel modulo attivo.

Vedi anche