Partager via

Interopérabilité WPF et Windows Forms

  • Article

WPF et Windows Forms présentent deux architectures différentes pour la création d’interfaces d’application. L’espace de noms System.Windows.Forms.Integration fournit des classes qui activent des scénarios d’interopérabilité courants. Les deux classes clés qui implémentent des fonctionnalités d’interopérabilité sont WindowsFormsHost et ElementHost. Cette rubrique décrit les scénarios d’interopérabilité pris en charge et les scénarios qui ne sont pas pris en charge.

Note

Une considération particulière est apportée au scénario de contrôle hybride . Un contrôle hybride a un contrôle d’une technologie imbriquée dans un contrôle de l’autre technologie. On parle aussi d’interopérabilité imbriquée. Un contrôle hybride à plusieurs niveaux a plusieurs niveaux d’imbrication de contrôle hybride. Un exemple d’interopérabilité imbriquée à plusieurs niveaux est un contrôle Windows Forms qui contient un contrôle WPF, qui contient un autre contrôle Windows Forms. Les contrôles hybrides à plusieurs niveaux ne sont pas pris en charge.

Hébergement de contrôles Windows Forms dans WPF

Les scénarios d’interopérabilité suivants sont pris en charge lorsqu’un contrôle WPF héberge un contrôle Windows Forms :

  • Le contrôle WPF peut héberger un ou plusieurs contrôles Windows Forms à l’aide de XAML.

  • Il peut héberger un ou plusieurs contrôles Windows Forms à l’aide de code.

  • Il peut héberger des contrôles de conteneur Windows Forms qui contiennent d’autres contrôles Windows Forms.

  • Il peut héberger un formulaire maître/détail avec une partie maître WPF et une partie détail Windows Forms.

  • Il peut héberger un formulaire maître/détail avec une partie maître Windows Forms et une partie détail WPF.

  • Il peut héberger un ou plusieurs contrôles ActiveX.

  • Il peut héberger un ou plusieurs contrôles composites.

  • Il peut héberger des contrôles hybrides à l’aide du langage XAML (Extensible Application Markup Language).

  • Il peut héberger des contrôles hybrides à l’aide du code.

Prise en charge de la disposition

La liste suivante décrit les limitations connues lorsque l’élément WindowsFormsHost tente d’intégrer son contrôle Windows Forms hébergé dans le système de disposition WPF.

  • Dans certains cas, les contrôles Windows Forms ne peuvent pas être redimensionnés ou ne peuvent être dimensionnés qu’en dimensions spécifiques. Par exemple, un contrôle de ComboBox Windows Forms ne prend en charge qu’une seule hauteur, définie par la taille de police du contrôle. Dans une disposition dynamique WPF, qui suppose que les éléments peuvent s'étendre verticalement, un contrôle hébergé de type ComboBox ne s'étendra pas comme prévu.

  • Les contrôles Windows Forms ne peuvent pas être pivotés ou asymétriques. Par exemple, lorsque vous faites pivoter votre interface utilisateur de 90 degrés, les contrôles Windows Forms hébergés conservent leur position verticale.

  • Dans la plupart des cas, les contrôles Windows Forms ne prennent pas en charge la mise à l’échelle proportionnelle. Les dimensions globales du contrôle sont mises à l’échelle, mais les contrôles enfants et les composants du contrôle risquent de ne pas être redimensionnés comme prévu. Cette limitation dépend de la façon dont chaque contrôle Windows Forms prend en charge la mise à l’échelle.

  • Dans une interface utilisateur WPF, vous pouvez modifier l’ordre z des éléments pour contrôler le comportement qui se chevauche. Un contrôle Windows Forms hébergé est dessiné dans un HWND distinct, par conséquent, il est toujours affiché au-dessus des éléments WPF.

  • Les contrôles Windows Forms prennent en charge la mise à l’échelle automatique en fonction de la taille de police. Dans une interface utilisateur WPF, la modification de la taille de police ne redimensionne pas toute la disposition, même si des éléments individuels peuvent être redimensionnés dynamiquement.

Propriétés ambiantes

Certaines des propriétés ambiantes des contrôles WPF ont des équivalents Windows Forms. Ces propriétés ambiantes sont propagées aux contrôles Windows Forms hébergés et exposées en tant que propriétés publiques sur le contrôle WindowsFormsHost. Le contrôle WindowsFormsHost traduit chaque propriété ambiante WPF en son équivalent Windows Forms.

Pour plus d’informations, consultez Mappage de propriétés Windows Forms et WPF.

Comportement

Le tableau suivant décrit le comportement d’interopérabilité.

Comportement Prise en charge Non pris en charge
Transparence Le rendu du contrôle Windows Forms prend en charge la transparence. L’arrière-plan du contrôle WPF parent peut devenir l’arrière-plan des contrôles Windows Forms hébergés. Certains contrôles Windows Forms ne prennent pas en charge la transparence. Par exemple, les contrôles TextBox et ComboBox ne sont pas transparents lorsqu’ils sont hébergés par WPF.
Tabulation L’ordre de tabulation des contrôles Windows Forms hébergés est identique au moment où ces contrôles sont hébergés dans une application Windows Forms.

La tabulation entre un contrôle WPF et un contrôle Windows Forms à l’aide des touches TAB et MAJ+TAB fonctionne normalement.

Les contrôles Windows Forms dont la valeur de la propriété TabStop est false ne reçoivent pas le focus lorsque l'utilisateur passe d'un contrôle à l'autre par onglets.

- Chaque contrôle WindowsFormsHost a une valeur TabIndex, qui détermine quand ce contrôle WindowsFormsHost reçoit le focus.
- Les contrôles Windows Forms contenus dans un conteneur WindowsFormsHost suivent l’ordre spécifié par la propriété TabIndex. En conséquence, la tabulation à partir du dernier index de tabulation met le focus sur le contrôle WPF suivant, s’il existe. Si aucun autre contrôle WPF focusable n’existe, la tabulation retourne au premier contrôle Windows Forms dans l’ordre de tabulation.
Les valeurs de - etTabIndex pour les contrôles à l'intérieur de WindowsFormsHost sont relatives aux contrôles Windows Forms similaires contenus dans le contrôle WindowsFormsHost.
- La tabulation respecte le comportement spécifique de chaque contrôle. Par exemple, frapper la touche TAB dans un contrôle TextBox dont la valeur de la propriété AcceptsTab est true insère un onglet dans la zone de texte plutôt que de déplacer le focus.		 Sans objet.
Navigation avec des touches de direction - La navigation avec des touches de direction dans le contrôle WindowsFormsHost est la même que dans un contrôle conteneur Windows Forms ordinaire : les touches flèche haut et flèche gauche sélectionnent le contrôle précédent, et les touches flèche bas et flèche droite sélectionnent le contrôle suivant.
- Les touches FLÈCHE DU HAUT et FLÈCHE DE GAUCHE utilisées à partir du premier contrôle contenu dans le contrôle WindowsFormsHost effectuent la même action que le raccourci clavier Maj+Tab. S’il existe un contrôle WPF pouvant recevoir le focus, le focus se déplace en dehors du contrôle WindowsFormsHost. Ce comportement diffère du comportement standard ContainerControl en ce qu’il n’y a pas d’enveloppement vers le dernier contrôle. Si aucun autre contrôle WPF focusable n’existe, le focus revient au dernier contrôle Windows Forms dans l’ordre de tabulation.
- Les touches FLÈCHE DU BAS et FLÈCHE DE DROITE utilisées à partir du dernier contrôle contenu dans le contrôle WindowsFormsHost effectuent la même action que la touche TAB. S’il existe un contrôle WPF pouvant recevoir le focus, le focus se déplace en dehors du contrôle WindowsFormsHost. Ce comportement diffère du comportement standard ContainerControl en ce qu’il n’y a pas d’enveloppement vers le premier contrôle. Si aucun autre contrôle WPF focusable n’existe, le focus revient au premier contrôle Windows Forms dans l’ordre de tabulation.		 Sans objet.
Accélérateurs Les accélérateurs fonctionnent comme d’habitude, sauf lorsqu’ils sont notés dans la colonne « Non pris en charge ». Les accélérateurs dupliqués à travers les technologies ne fonctionnent pas comme les accélérateurs dupliqués ordinaires. Lorsqu'un accélérateur est dupliqué entre différentes technologies, avec au moins un sur un contrôle Windows Forms et l'autre sur un contrôle WPF, c'est toujours le contrôle Windows Forms qui reçoit l’accélérateur. Le focus ne bascule pas entre les contrôles lorsque l’accélérateur dupliqué est enfoncé.
Touches de raccourci Les touches de raccourci fonctionnent normalement, sauf indication contraire dans la colonne « Non pris en charge ». - Les touches de raccourci Windows Forms gérées à l’étape de prétraitement sont toujours prioritaires sur les touches de raccourci WPF. Par exemple, si vous avez un contrôle ToolStrip avec les touches de raccourci Ctrl+S définies et qu’il existe une commande WPF liée à Ctrl+S, le gestionnaire de contrôle ToolStrip est toujours appelé en premier, quel que soit le focus.
- Les touches de raccourci Windows Forms gérées par l’événement KeyDown sont traitées en dernier dans WPF. Vous pouvez empêcher ce comportement en substituant la méthode IsInputKey du contrôle Windows Forms ou en gérant l’événement PreviewKeyDown. Retournez true à partir de la méthode IsInputKey ou définissez la valeur de la propriété PreviewKeyDownEventArgs.IsInputKey sur true dans votre gestionnaire d’événements PreviewKeyDown.
AcceptsReturn, AcceptsTab et autre comportement spécifique d’un contrôle Les propriétés qui modifient le comportement du clavier par défaut fonctionnent normalement, en supposant que le contrôle Windows Forms remplace la méthode IsInputKey pour retourner true. Les contrôles Windows Forms qui modifient le comportement du clavier par défaut en gérant l’événement KeyDown sont traités en dernier dans le contrôle WPF hôte. Étant donné que ces contrôles sont traités en dernier, ils peuvent produire un comportement inattendu.
Événements Entrée et Sortie Lorsque le focus n’est pas dirigé vers le contrôle ElementHost, les événements Entrée et Sortie sont déclenchés normalement lorsque le focus change dans un seul contrôle WindowsFormsHost. Les événements Entrée et Sortie ne sont pas déclenchés quand les changements de focus suivants se produisent :

- De l’intérieur vers l’extérieur d’un contrôle WindowsFormsHost.
- De l’extérieur vers l’intérieur d’un contrôle WindowsFormsHost.
- En dehors d’un contrôle WindowsFormsHost.
- D’un contrôle Windows Forms hébergé dans un contrôle WindowsFormsHost vers un contrôle ElementHost hébergé dans le même WindowsFormsHost.
Multithreading Tous les types de multithreading sont pris en charge. Les technologies Windows Forms et WPF supposent l’utilisation d’un modèle de concurrence à thread unique. Pendant le débogage, les appels aux objets framework d’autres threads déclenchent une exception pour appliquer cette exigence.
Sécurité Tous les scénarios d’interopérabilité nécessitent une confiance totale. Aucun scénario d'interopération n’est autorisé en mode de confiance partielle.
Accessibilité Tous les scénarios d’accessibilité sont pris en charge. Les produits de technologie d’assistance fonctionnent correctement lorsqu’ils sont utilisés pour les applications hybrides qui contiennent à la fois des contrôles Windows Forms et WPF. Sans objet.
Presse-papiers Toutes les opérations de Presse-papiers fonctionnent normalement. Cela inclut la coupe et le collage entre les contrôles Windows Forms et WPF. Sans objet.
Fonctionnalité glisser-déplacer Toutes les opérations de glisser-déplacer fonctionnent normalement. Cela inclut les opérations entre les contrôles Windows Forms et WPF. Sans objet.

Hébergement de contrôles WPF dans Windows Forms

Les scénarios d’interopérabilité suivants sont pris en charge lorsqu’un contrôle Windows Forms héberge un contrôle WPF :

  • Hébergement d’un ou de plusieurs contrôles WPF à l’aide de code.

  • Association d’une feuille de propriétés à un ou plusieurs contrôles WPF hébergés.

  • Hébergement d’une ou de plusieurs pages WPF dans un formulaire.

  • Démarrage d’une fenêtre WPF.

  • Hébergement d’un formulaire maître/détail avec une partie maître Windows Forms et une partie détail WPF.

  • Hébergement d’un formulaire maître/détail avec une partie maître WPF et une partie détail Windows Forms.

  • Hébergement de contrôles WPF personnalisés.

  • Hébergement de contrôles hybrides.

Propriétés ambiantes

Certaines des propriétés ambiantes des contrôles Windows Forms ont des équivalents WPF. Ces propriétés ambiantes sont propagées vers les contrôles WPF hébergés et exposées comme propriétés publiques sur le contrôle ElementHost. Le contrôle ElementHost traduit chaque propriété ambiante Windows Forms en son équivalent WPF.

Pour plus d’informations, consultez Mappage de propriétés Windows Forms et WPF.

Comportement

Le tableau suivant décrit le comportement d’interopérabilité.

Comportement Prise en charge Non pris en charge
Transparence Le rendu d’un contrôle WPF prend en charge la transparence. L’arrière-plan du contrôle Windows Forms parent peut devenir l’arrière-plan des contrôles WPF hébergés. Sans objet.
Multithreading Tous les types de multithreading sont pris en charge. Les technologies Windows Forms et WPF supposent l’utilisation d’un modèle de concurrence à thread unique. Pendant le débogage, les appels aux objets framework d’autres threads déclenchent une exception pour appliquer cette exigence.
Sécurité Tous les scénarios d’interopérabilité nécessitent une confiance totale. Aucun scénario d’interopérabilité n’est autorisé dans une confiance partielle.
Accessibilité Tous les scénarios d’accessibilité sont pris en charge. Les produits de technologie d’assistance fonctionnent correctement lorsqu’ils sont utilisés pour les applications hybrides qui contiennent à la fois des contrôles Windows Forms et WPF. Sans objet.
Presse-papiers Toutes les opérations de Presse-papiers fonctionnent normalement. Cela inclut la coupe et le collage entre les contrôles Windows Forms et WPF. Sans objet.
Fonctionnalité glisser-déplacer Toutes les opérations de glisser-déplacer fonctionnent normalement. Cela inclut les opérations entre les contrôles Windows Forms et WPF. Sans objet.

Voir aussi