Utilisez l'automatisation de l'interface utilisateur pour les anciens commandes tierces

Question

Existe-t-il un moyen prêt à l'emploi de créer un fournisseur d'automatisation d'interface utilisateur pour les contrôles tiers qui ne prennent pas en charge l'automatisation de l'interface utilisateur?

Mon problème: j'essaie d'automatiser l'application VB6 avec VSFlexGrid Activex Control et ne parvient pas à accéder à ses propriétés et méthodes.

Merci

Answer 1

C'est possible, mais c'est beaucoup de travail, et pas approprié en toutes circonstances.

Les exigences clés sont que le contrôle cible:

• a un hwnd à lui, de préférence avec un nom de classe bien connu et stable

• A une manière bien définie de communiquer avec ce contrôle à partir d'un autre processus. Les commandes qui utilisent un ensemble de messages Windows (comme les contrôles communs Win32) entrent dans cette catégorie, tout comme les contrôles comme le contrôle MS Internet Explorer, qui expose une interface approfondie (IHTMLDocument).

Mais si le contrôle n'a pas un moyen d'accéder à ses informations en externe, alors l'automatisation de l'interface utilisateur n'aidera pas beaucoup: tout ce que l'UIA fait ici vous permet de placer une classe d'adaptateur dans son cadre existant; Mais cela ne vous donne pas d'outils nouveaux ou supplémentaires pour gérer les informations sous-jacentes en premier lieu.

Les anciens contrôles ActiveX de l'ère VB sont quelque chose d'un défi: si vous pouvez obtenir un contrôle sur le formulaire, vous pouvez utiliser les différentes interfaces COM pour naviguer vers les autres contrôles sur ce formulaire et accéder à leurs propriétés. Mais la capture est que vous ne pouvez pas facilement le faire à partir d'un autre processus. Et peu, le cas échéant, de ces contrôles ActiveX prennent en charge tout type de messages Windows, car ils supposent que le code client utilisera les interfaces COM à la place.