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 System.Windows.Forms.Integration de noms 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é qui sont pris en charge et ceux qui ne le sont pas.

Remarque

Le scénario de contrôle hybride est examiné plus en détail. Un contrôle hybride contient un contrôle d’une technologie qui est lui-même imbriqué dans un contrôle d’une 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 des 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 des détails wpF master et Windows Forms.

  • Il peut héberger un formulaire maître/détail avec des détails windows Forms et 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 de 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 Windows Forms ComboBox 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’étirer verticalement, un contrôle hébergé ComboBox ne s’étend 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. Il est donc toujours dessiné sur les é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 WindowsFormsHost contrôle. Le WindowsFormsHost contrôle 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 Pris en charge Non prise 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 et ComboBox les TextBox contrôles 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 d’un contrôle WPF vers un contrôle Windows Forms avec la touche TAB et les touches Maj+Tab fonctionnent comme d’habitude.

Les contrôles Windows Forms qui ont une TabStop valeur de propriété ne false reçoivent pas le focus lorsque l’utilisateur clique sur des onglets via des contrôles.

- Chaque WindowsFormsHost contrôle a une TabIndex valeur, qui détermine quand ce WindowsFormsHost contrôle reçoit le focus.
- Les contrôles Windows Forms contenus dans un WindowsFormsHost conteneur suivent l’ordre spécifié par la TabIndex propriété. Le tabulation à partir du dernier index de tabulation met le focus sur le contrôle WPF suivant, s’il en existe un. Si aucun autre contrôle WPF focusable n’existe, la tabulation retourne au premier contrôle Windows Forms dans l’ordre de tabulation.
- TabIndex les valeurs des contrôles à l’intérieur du WindowsFormsHost contrôle sont relatives aux contrôles Windows Forms frères contenus dans le WindowsFormsHost contrôle.
- La tabulation respecte le comportement spécifique de chaque contrôle. Par exemple, appuyez sur la touche TAB dans un TextBox contrôle qui a une AcceptsTab valeur de propriété d’entrée true dans une tabulation dans la zone de texte au lieu de déplacer le focus.		 Non applicable.
Navigation à l’aide des touches de direction - La navigation avec des touches de direction dans le WindowsFormsHost contrôle est identique à celle d’un contrôle conteneur Windows Forms ordinaire : la flèche haut et les touches 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 haut et gauche du premier contrôle contenu dans le WindowsFormsHost contrôle effectuent la même action que le raccourci clavier Maj+Tab. S’il existe un contrôle WPF focusable, le focus se déplace en dehors du WindowsFormsHost contrôle. Ce comportement diffère du comportement standard ContainerControl dans lequel aucun encapsulage au dernier contrôle ne se produit. Si aucun autre contrôle WPF focusable n’existe, le focus revient au dernier contrôle Windows Forms dans l’ordre de tabulation.
- La flèche bas et les touches de direction droite du dernier contrôle contenu dans le WindowsFormsHost contrôle effectuent la même action que la touche TAB. S’il existe un contrôle WPF focusable, le focus se déplace en dehors du WindowsFormsHost contrôle. Ce comportement diffère du comportement standard ContainerControl dans lequel aucune habillage n’est effectué sur 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.		 Non applicable.
Accélérateurs Les accélérateurs fonctionnent normalement, sauf indication contraire dans la colonne « Non pris en charge ». Les accélérateurs en double entre les technologies ne fonctionnent pas comme des accélérateurs en double standard. Lorsqu’un accélérateur est dupliqué entre les technologies, avec au moins un contrôle Windows Forms et l’autre sur un contrôle WPF, le contrôle Windows Forms reçoit toujours l’accélérateur. Le focus ne bascule pas entre les contrôles quand l’accélérateur en double est utilisé.
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 ToolStrip contrôle avec les touches de raccourci Ctrl+S définies et qu’il existe une commande WPF liée à Ctrl+S, le gestionnaire de contrôles est toujours appelé en premier, quel que soit le ToolStrip 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 du IsInputKey contrôle Windows Forms ou en gérant l’événement PreviewKeyDown . Retournez true de la IsInputKey méthode ou définissez la valeur de la PreviewKeyDownEventArgs.IsInputKey propriété true dans votre PreviewKeyDown gestionnaire d’événements.
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 comme d’habitude, en supposant que le contrôle Windows Forms remplace la IsInputKey méthode 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 entraîner un comportement inattendu.
Événements Enter et Leave Lorsque le focus ne va pas au contrôle conteneur ElementHost , les événements Entrée et Leave sont déclenchés comme d’habitude lorsque le focus change dans un seul WindowsFormsHost contrôle. Les événements Enter et Leave ne sont pas déclenchés quand les changements de focus suivants se produisent :

- De l’intérieur à l’extérieur d’un WindowsFormsHost contrôle.
- De l’extérieur à l’intérieur d’un WindowsFormsHost contrôle.
- En dehors d’un WindowsFormsHost contrôle.
- D’un contrôle Windows Forms hébergé dans un WindowsFormsHost contrôle à un ElementHost contrôle hébergé à l’intérieur du même WindowsFormsHost.
Multithreading Tous les types de multithreading sont pris en charge. Les technologies Windows Forms et WPF supposent tous deux un modèle d’accès concurrentiel à thread unique. Pendant le débogage, les appels aux objets de framework d’autres threads lèvent 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é avec 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. Non applicable.
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. Non applicable.
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. Non applicable.

Hébergement des 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 des détails windows Forms et WPF.

  • Hébergement d’un formulaire maître/détail avec des détails wpF et 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 aux contrôles WPF hébergés et exposées en tant que propriétés publiques sur le ElementHost contrôle. Le ElementHost contrôle 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 Pris en charge Non prise en charge
Transparence Le rendu du 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. Non applicable.
Multithreading Tous les types de multithreading sont pris en charge. Les technologies Windows Forms et WPF supposent tous deux un modèle d’accès concurrentiel à thread unique. Pendant le débogage, les appels aux objets de framework d’autres threads lèvent 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é avec 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. Non applicable.
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. Non applicable.
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. Non applicable.

Voir aussi