En travaillant sur un outil d'automatisation général, en envisageant de passer des hooks de messages Win32 à .net UI Automation, l'ensemble des fonctionnalités d'UI Automation ne couvre pas tout ce que nous avons dans Win32 et ne le fait pas encore. ne semble pas supporter toute l'interface graphique sur Windows.Comment écrivez-vous une UI Automation for MS cohérente? MSAA et UI Automation ne semblent pas se chevaucher
Un exemple est Windows Live Messenger.
Windows Live Messenger 2009 utilise toujours l'ancien DirectUIHwnd pour dessiner le GUI. Cela signifie que vous ne pouvez pas utiliser les messages Windows à envoyer aux contrôles, car les contrôles n'ont pas leur propre HWND. Il semble également vaincre le nouveau framework .net UI Automation bien que la documentation semble faire comme si elle pouvait être jointe dans le document UI Automation and Microsoft Active Accessibility. En regardant MS Accessibility souligné Active Accessibility 2.0 SDK Tools qui a montré que MSAA peut interagir avec le contenu.
Y a-t-il un truc pour obtenir l'ancienne technologie MSAA que UI Automation semble essayer de remplacer pour fonctionner avec UI Automation? Je préfère ne pas avoir plusieurs solutions essayant d'automatiser les mêmes fenêtres pour Windows contrairement à Windows Live Messenger où chacune de ces techniques est valide et fonctionnera.