Informazioni sui problemi di threading
In questo argomento vengono descritti gli scenari di threading comuni per le implementazioni client di Microsoft Automazione interfaccia utente e viene illustrato come evitare problemi che possono verificarsi se un client usa in modo non corretto il threading.
Questo argomento include le sezioni seguenti:
- Automazione interfaccia utente e il thread dell'interfaccia utente
- Modello di threading per gestori eventi
- Affinità apartment COM in Windows a 64 bit
- Argomenti correlati
Automazione interfaccia utente e il thread dell'interfaccia utente
A causa del modo in cui Automazione interfaccia utente usa i messaggi di Windows, i conflitti possono verificarsi quando un'applicazione client tenta di interagire con la propria interfaccia utente nel thread dell'interfaccia utente. Questi conflitti possono causare prestazioni molto lente o persino causare l'interruzione della risposta dell'applicazione.
Se l'applicazione client è progettata per interagire con tutti gli elementi sul desktop, inclusa la propria interfaccia utente, è necessario effettuare tutte le chiamate Automazione interfaccia utente da un thread separato. Sono inclusi l'individuazione di elementi, ad esempio, usando IUIAutomationTreeWalker o il metodo IUIAutomationElement::FindAll e usando i pattern di controllo. Questo thread non deve possedere finestre e deve essere un thread del modello Multithreaded Apartment (COM) Multithreaded Apartment (MTA) (un thread che inizializza COM chiamando CoInitializeEx con il flag COINIT_MULTITHREADED ).
È possibile effettuare Automazione interfaccia utente chiamate in un gestore eventi Automazione interfaccia utente, perché il gestore eventi viene sempre chiamato in un thread non dell'interfaccia utente. Tuttavia, quando si sottoscrive gli eventi che possono provenire dall'interfaccia utente dell'applicazione client, è necessario effettuare la chiamata a IUIAutomation::AddAutomationEventHandler, o un metodo correlato, in un thread non dell'interfaccia utente (che deve essere anche un thread MTA). Rimuovere i gestori eventi sullo stesso thread.
Un client Automazione interfaccia utente non deve usare più thread per aggiungere o rimuovere gestori eventi. Un comportamento imprevisto può determinare se un gestore eventi viene aggiunto o rimosso mentre un altro viene aggiunto o rimosso nello stesso processo client.
Modello di threading per gestori eventi
Un client Automazione interfaccia utente deve usare il modello di threading MTA COM per i thread che implementano gestori eventi. L'uso del modello Apartment a thread singolo (STA) può causare problemi, ad esempio impedire ai client di rimuovere gestori eventi dal thread.
Affinità apartment COM in Windows a 64 bit
In base alla specifica COM, la durata di un oggetto remoto è governata dalla durata dell'apartment in cui viene chiamata la funzione CoCreateInstance per creare l'oggetto. Quando l'appartamento originale viene chiuso, viene rilasciato anche l'oggetto remoto.
Per Automazione interfaccia utente client, questo comportamento COM può significare che la durata dell'helper remoto 32/64 (creata da UIAutomationCore.dll) usata da un elemento a 32 bit è governata dalla durata apartment del thread che ha creato l'elemento. Se il client Automazione interfaccia utente esegue il marshalling dell'elemento a un altro thread, l'elemento può diventare invalidato quando l'apartment di origine viene arrestato. Il client Automazione interfaccia utente deve gestire questi problemi in modo normale rilevando gli errori durante l'uso degli elementi di automazione con marshalling.
Lo stesso problema può verificarsi con un client Automazione interfaccia utente a 32 bit con elementi a 64 bit.
Argomenti correlati
Informazioni generali:
Ottenere elementi di automazione interfaccia utente
Sottoscrizione di eventi Automazione interfaccia utente
Panoramica degli eventi di automazione interfaccia utente
Altre risorse: