Vue d'ensemble des applications Windows Forms et non managées
Les applications et les contrôles Windows Forms peuvent interagir avec des applications non managées, en tenant compte de certaines mises en garde. Les sections suivantes décrivent les scénarios et configurations pris en charge, ou non, par les applications et les contrôles Windows Forms.
Contrôles Windows Forms et applications ActiveX
À l'exception de Microsoft Internet Explorer et de Microsoft Foundation Classes (MFC), les contrôles Windows Forms ne sont pas pris en charge dans les applications conçues pour héberger des contrôles ActiveX. D'autres applications et outils de développement sont capables d'héberger des contrôles ActiveX, y compris des conteneurs de test ActiveX de versions de Visual Studio antérieures à Visual Studio .NET 2003, ne sont pas des hôtes pris en charge pour les contrôles Windows Forms.
Ces contraintes s'appliquent également à l'utilisation de contrôles Windows Forms à travers COM Interop. L'utilisation d'un contrôle Windows Forms à travers un wrapper CCW (COM Callable Wrapper) est prise en charge uniquement dans Internet Explorer. Pour plus d'informations sur COM interop, consultez
COM Interop (Visual Basic) et Interopérabilité COM avancée.
Le tableau suivant affiche la prise en charge d'hébergement ActiveX disponible pour les contrôles Windows Forms.
Version de Windows Forms |
Prise en charge |
|---|---|
.NET Framework version 1.0 |
Internet Explorer 5.01 et versions ultérieures |
.NET Framework 1.1 et versions ultérieures |
Internet Explorer 5.01 et versions ultérieures Microsoft Foundation Classes (MFC) 7.0 et versions ultérieures |
Hébergement de composants Windows Forms en tant que contrôles ActiveX
Dans le .NET Framework 1.1, la prise en charge a été étendue de manière à inclure MFC 7.0 et les versions ultérieures. Cette prise en charge inclut tout conteneur pleinement compatible avec le MFC 7.0 et le conteneur de contrôles ActiveX ultérieur.
Toutefois, l'inscription de contrôles Windows Forms en tant que contrôles ActiveX n'est pas prise en charge. Par ailleurs, l'appel de la méthode com.ms.win32.Ole32.CoCreateInstance pour les contrôles Windows Forms n'est pas non plus pris en charge. Seule l'activation managée des contrôles Windows Forms est prise en charge. Une fois que vous créez un contrôle Windows Forms, vous pouvez l'héberger dans une application MFC comme avec un contrôle ActiveX.
Pour utiliser des contrôles Windows Forms dans votre application non managée, vous devez soit héberger le CLR à l'aide des API d'hébergement du CLR non managées soit utiliser les fonctionnalités d'interopérabilité C++. L'utilisation des fonctionnalités d'interopérabilité C++ est la solution recommandée.
Windows Forms dans les applications clientes COM
Lorsque vous ouvrez un Windows Form à partir d'une application cliente COM, telle qu'une application Visual Basic 6.0 ou une application MFC, le formulaire peut se comporter de façon inattendue. Par exemple, lorsque vous appuyez sur la touche TAB, le focus ne passe pas d'un contrôle à un autre. Lorsque vous appuyez sur la touche ENTRÉE pendant qu'un bouton de commande a le focus, l'événement Click du bouton n'est pas déclenché. Vous pouvez également constater un comportement inattendu des frappes de touche ou de l'activité de la souris.
Ce problème se produit parce que l'application non managée n'implémente pas la prise en charge de boucle de message requise par Windows Forms pour fonctionner correctement. La boucle de message fournie par l'application cliente COM est fondamentalement différente de la boucle de message Windows Forms.
La boucle de message d'une application est une boucle de programme interne qui récupère les messages dans la file d'attente de messages d'un thread, les traduit, puis les envoie à l'application pour qu'ils soient traités. La boucle de message d'un Windows Form n'a pas la même architecture que les boucles de message des applications antérieures, telles que les applications Visual Basic 6.0 et les applications MFC. Les messages de fenêtre qui sont publiés dans la boucle de message peuvent être traités différemment de ce qu'attend le Windows Form. Dans ces circonstances, un comportement inattendu peut se produire. Certaines combinaisons de touches, certains mouvements de souris peuvent ne pas fonctionner, et certains événements peuvent ne pas se déclencher comme prévu.
Résolution des problèmes d'interopérabilité
Vous pouvez résoudre ces problèmes en affichant le formulaire dans une boucle de message .NET Framework, qui est créée à l'aide de la méthode Application.Run.
Pour qu'un Windows Form fonctionne correctement à partir d'une application cliente COM, vous devez l'exécuter sur une boucle de message Windows Forms. Pour cela, utilisez l'une des approches suivantes :
Utilisez la méthode Form.ShowDialog pour afficher le Windows Form. Pour plus d'informations, consultez Comment : prendre en charge COM Interop en affichant un Windows Form avec la méthode ShowDialog.
Affichez chaque Windows Form sur un nouveau thread. Pour plus d'informations, consultez Comment : prendre en charge l'interopérabilité COM en affichant chaque Windows Form sur son propre thread.
Voir aussi
Tâches
Comment : prendre en charge COM Interop en affichant un Windows Form avec la méthode ShowDialog
Référence
Aximp.exe (Windows Forms ActiveX Control Importer)
Concepts
Exposition de composants .NET Framework à COM
Empaquetage d'un assembly pour COM
Inscription d'assemblys dans COM
Autres ressources
Applications Windows Forms et non managées
Interopérabilité COM dans les applications .NET Framework (Visual Basic)