2011-08-30 10 views
5

Ho un controllo TreeView sul mio modulo e sto ricorsivamente passando attraverso gli elementi di un'altra finestra che inizia con la finestra stessa. Sto usando questo per trovare gli elementi:Automazione dell'interfaccia utente di Windows che non mostra tutti gli elementi figlio?

getRecursiveElements(AutomationElement parent) 
{ 
    children = parent.FindAll(TreeScope.Children, Condition.TrueCondition); 

    foreach (AutomationElement child in children) 
    { 
    addToTreeView(child); 
    getRecursiveElements(child); 
    } 
} 

In generale, il codice funziona abbastanza bene nella maggior parte dei casi. L'albero è popolato e ho un po 'di altro codice di supporto che mi permette di fare doppio clic, ad esempio, un elemento nella vista ad albero e evidenzierà quell'elemento nel modulo di destinazione.

Il problema che sto avendo è che, mentre si genera un albero impressionante, ci sono ancora alcuni elementi mancanti per alcuni programmi di destinazione.

Che motivo poteva esserci per questo, e c'è un modo per aggirare l'ostacolo? Se chiamo EnumChildWindows() da user32.dll avremo lo stesso problema?

+2

Puoi dare alcuni esempi dei tipi di elementi che sta saltando? E hai paragonato il tuo albero a quello prodotto dagli strumenti UISpy o Inspect dell'SDK? UIA ha un concetto di 'viste', che è un filtro che viene applicato in aggiunta alla condizione che si fornisce a Trova. Per impostazione predefinita, l'UIA filtra le cose che non sono elementi di contenuto, quindi se si enumera una listbox o listview, si otterrà solo la listbox, ma non le barre di scorrimento o l'intestazione. È questo il genere di cosa che ti manca o qualcos'altro? – BrendanMcK

risposta

3

Non tutti i programmi utilizzano controlli separati da finestra per tutti i relativi figli logici. Principalmente ciò dipende dalla struttura della GUI utilizzata.

Come esempio estremo, Qt utilizza una singola finestra per ogni finestra di primo livello. Dipinge quindi tutti i widget sul modulo dal gestore di messaggi WM_PAINT del modulo.

I programmi che adottano questo approccio sono in genere impossibili da automatizzare con metodi generici.

Sembra che tu hai incontrato un'applicazione che utilizza alcuni controlli con la finestra ma utilizza anche controlli personalizzati con una sola finestra per quello che sembra essere più widget. Ancora una volta questo è abbastanza comune.

+1

Per l'OP: mi piacerebbe comunque un esempio di ciò che non funziona: le app che non usano HWND dovrebbero implementare MSAA o UIAutomation in modo che siano accessibili agli utenti con disabilità - e finiscono per essere testabili/automatizzabile. Ad esempio, WPF, Silverlight e Flash e le aree del documento di IE e Firefox non usano HWND per i loro elementi figli, ma poiché implementano queste interfacce, è ancora possibile enumerarli con UIA. Mi chiedo quali sono i "determinati programmi target", poiché probabilmente hanno anche problemi di accessibilità; Sono curioso di sapere se queste sono app conosciute. – BrendanMcK

+2

(FWIW, QT sembra implementare MSAA - quindi, anche se utilizza solo un singolo HWND, dovrebbe comunque essere enumerabile usando UIA - dal momento che UIA usa MSAA come fonte di informazioni internamente.Se l'UI è enumerabile con UIA è più complesso che semplicemente se utilizza HWND per elementi figlio, può anche dipendere dal fatto che il framework abbia il supporto per l'accessibilità e, in caso affermativo, se lo sviluppatore dell'app lo abbia usato correttamente.) – BrendanMcK

0

Puoi dare un esempio migliore di ciò che fallisce? Pensando al problema, è possibile che l''elemento' nell'altro modulo sia disegnato manualmente, e quindi non ha maniglie registrate distinte per tutto.

Problemi correlati