WPF UI Automation - AutomationElement.FindFirst échoue lorsqu'il y a beaucoup d'éléments

Question

Nous avons des tests d'interface utilisateur automatisés pour notre application WPF (.NET 4); ces tests utilisent les API UI Automation.

Nous appelons AutomationElement.FindFirst pour trouver un élément cible, puis interagir avec lui.

Exemple (pseudo-code):

var nameEquals = new PropertyCondition(AutomationElement.NameProperty, "OurAppWindow"); 
var appWindow = DesktopWindow.FindFirst(TreeScope.Children, nameEquals); 
// this succeeds 

var idEquals = new PropertyCondition(AutomationElement.AutomationIdProperty, "ControlId"); 
var someItem = appWindow.FindFirst(TreeScope.Descendants, idEquals); 
// this suceeds sometimes, and fails sometimes! 

Le problème est, le appWindow.FindFirst va parfois échouer et retourner nulle, même si l'élément est présent. J'ai écrit une fonction d'assistance qui parcourt manuellement l'arborescence de l'interface utilisateur et l'imprime, et l'élément avec l'ID correct est présent dans tous les cas.

Cela semble être lié au nombre d'autres éléments affichés dans la fenêtre. S'il n'y a pas d'autres éléments, cela réussit toujours, mais quand de nombreux autres éléments d'interface utilisateur complexes sont affichés à côté, la recherche échoue.

Il semble que nous atteignions une sorte de limite d'élément interne. Je ne trouve aucune limite d'élément documentée mentionnée pour les API d'automatisation - y a-t-il un moyen de contourner ce problème? Je pense que je devrais écrire ma propre implémentation de FindFirst qui fait marcher l'arbre lui-même manuellement ... Autant que je sache, cela devrait fonctionner, parce que ma fonction d'utilitaire arbre-arbre fait exactement cela, et ça va, mais il semble que ce serait :-(inutile et lent

Toute aide serait grandement appréciée

Answer 1

Faire l'arbre marche manuellement probablement la meilleure façon de contourner ce problème.

en fait, vous trouverez probablement qu'une implémentation de FindFirst en utilisant la marche en arbre sera plus rapide qu'en utilisant FindFirst sur un élément avec un grand engourdissement er d'enfants. Si vous regardez le code pour AutomationElement.FindFirst dans Reflector, vous verrez que cela fonctionne en tirant à travers la frontière d'automation tous les enfants correspondant à la condition, puis en retournant le premier d'entre eux. En revanche, l'approche TreeWalker tentera uniquement de tirer le premier enfant unique à travers la frontière.

Answer 2

J'ai eu le même problème dans une de mes applications que j'automatisais. J'avais un contrôle personnalisé qui était sur AdornerLayer et je modifiais l'arbre UI Automation afin que l'AutomationElement d'Adorner apparaisse comme un enfant Visual UI au contrôle qu'il décorait au lieu d'apparaître comme un enfant de la racine pour l'application. Lorsque j'utilisais UI Spy, j'obtenais un certain nombre d'erreurs dans la fenêtre de sortie en indiquant des choses à propos d'un parent invalide lorsque je naviguais dans son arborescence. J'ai résolu un bug dans mon code dans la façon dont j'étais parenting the AutomationElement pour AutomationElement de l'Adorner. Une fois que j'ai corrigé le bogue, UI Spy n'affiche plus les erreurs dans la fenêtre de sortie et je n'obtiens plus d'échec des appels de méthode FindFirst.

Si le poster d'origine continue de suivre cette question, est-ce que UI Spy a des problèmes pour naviguer dans votre application?

Answer 3

J'ai même bloqué avec ce problème mais je n'ai pas vu mon échec. Je crée une fenêtre à la volée et ajoute le contrôle en tant que contenu de la fenêtre. Mon échec ici était, que j'ai montré la fenêtre, puis assigné le contenu. Cela échoue même.Après des heures de recherche je l'ai changé mon code à ceci:

var window = new System.Windows.Window(); 
window.Content = addControl; 
window.Show(); 
GetWindow(window.Name); 

... et cela fonctionne.

Michael