Cenni preliminari sui provider di automazione interfaccia utente

Nota
La presente documentazione è destinata agli sviluppatori di .NET Framework che desiderano utilizzare le classi UI Automation gestite definite nello spazio dei nomi System.Windows.Automation.Per informazioni aggiornate sull'UI Automation, vedere Windows Automation API: Automazione interfaccia utente (la pagina potrebbe essere in inglese).

I provider di automazione interfaccia utente consentono la comunicazione tra i controlli e le applicazioni client di automazione interfaccia utente. In generale, ogni controllo o un altro elemento distinto di un'user interface (UI) è rappresentato da un provider. Il provider espone informazioni sull'elemento e facoltativamente implementa i pattern di controllo che consentono l'interazione tra l'applicazione client e il controllo.

In genere, non è necessario che esista un rapporto diretto tra applicazioni e provider. La maggior parte dei controlli standard nelle applicazioni che utilizzano i framework Win32, Windows Forms o Windows Presentation Foundation (WPF) viene esposta automaticamente al sistema di UI Automation. Le applicazioni che implementano controlli personalizzati possono implementare anche i provider di UI Automation per tali controlli e le applicazioni client possono accedervi senza la necessità di passaggi speciali.

In questo argomento vengono forniti cenni preliminari sulle modalità con cui gli sviluppatori di controlli implementano i provider di UI Automation, in particolare per i controlli delle finestre Windows Forms e Win32.

Nel presente argomento sono contenute le seguenti sezioni.

• Tipi di provider
• Concetti relativi ai provider di automazione interfaccia utente
• Argomenti correlati

Tipi di provider

I provider di automazione interfaccia utente rientrano in due categorie: lato client e lato server.

Provider lato client

I provider sul lato client sono implementati dai client di automazione interfaccia utente per comunicare con un'applicazione che non supporta, o almeno non completamente, l'UI Automation. I provider sul lato client di solito comunicano con il server attraverso il limite dei processi inviando e ricevendo i messaggi di Windows.

Poiché i provider di automazione interfaccia utente per i controlli delle applicazioni Win32, Windows Forms o WPF vengono forniti come parte del sistema operativo, per le applicazioni client non è in genere necessario implementare provider personalizzati, che non verranno pertanto trattati in questo documento.

Provider lato server

I provider sul lato server vengono implementati da controlli personalizzati o da applicazioni basati su un framework di interfaccia utente diverso da Win32, Windows Forms o WPF.

I provider sul lato server comunicano con le applicazioni client attraverso il limite dei processi esponendo le interfacce al sistema principale di UI Automation, che a sua volta gestisce le richieste dei client.

Concetti relativi ai provider di automazione interfaccia utente

In questa sezione viene fornita una breve spiegazione di alcuni dei principali concetti che sono alla base dell'implementazione di provider di automazione interfaccia utente.

Elementi

Gli elementi di UI Automation sono parti dell'user interface (UI) visibili ai client di automazione interfaccia utente, ad esempio finestre, riquadri, pulsanti, descrizioni comandi e elementi di elenco delle applicazioni.

Spostamento

Gli elementi di UI Automation vengono esposti ai client sotto forma di struttura ad albero di UI Automation. La struttura ad albero viene costruita dall'UI Automation con lo spostamento da un elemento all'altro. Lo spostamento è abilitato dai provider per ogni elemento, ciascuno dei quali può puntare a un elemento padre, a elementi di pari livello e a elementi figlio.

Per ulteriori informazioni sulla visualizzazione client della struttura ad albero di UI Automation, vedere Cenni preliminari sulla struttura ad albero di automazione dell'interfaccia utente.

Visualizzazioni

Un client può vedere la struttura ad albero di UI Automation in tre visualizzazioni principali, come illustrato nella tabella seguente.

Visualizzazione non elaborata	Contiene tutti gli elementi.
Visualizzazione controlli	Contiene elementi che corrispondono a controlli.
Visualizzazione contenuto	Contiene elementi che includono contenuto.

Per ulteriori informazioni sulle visualizzazioni client della struttura ad albero di UI Automation, vedere Cenni preliminari sulla struttura ad albero di automazione dell'interfaccia utente.

È responsabilità dell'implementazione del provider definire un elemento come elemento contenuto o elemento controllo. Gli elementi controllo possono essere o meno anche elementi contenuto, mentre tutti gli elementi contenuto sono elementi controllo.

Framework

Un framework è un componente che gestisce controlli figlio, hit test e rendering in un'area dello schermo. Ad esempio, una finestra Win32, solitamente definita HWND, può fungere da framework contenente più elementi di UI Automation, quali barra di menu, barra di stato e pulsanti.

I controlli contenitore di Win32, ad esempio caselle di riepilogo e visualizzazioni albero, sono considerati framework perché contengono codice per il rendering e l'esecuzione di hit test degli elementi figlio. Viceversa, una casella di riepilogo di WPF non è un framework, perché il rendering e gli hit test vengono gestiti dalla finestra WPF che la contiene.

L'UI di un'applicazione può essere costituita da framework diversi. Ad esempio, una finestra di applicazione HWND potrebbe contenere codice Dynamic HTML (DHTML), che a sua volta contiene un componente quale una casella combinata in un HWND.

Frammenti

Un frammento è un sottoalbero completo di elementi di un determinato framework. L'elemento in corrispondenza del nodo radice del sottoalbero è denominato radice del frammento. Una radice di frammento non include un elemento padre, ma è contenuta in un altro framework, solitamente una finestra Win32 (HWND).

Host

Il nodo radice di ogni frammento deve essere contenuto in un elemento, solitamente una finestra Win32 (HWND). L'eccezione è il desktop, che non è contenuto in nessun altro elemento. L'host di un controllo personalizzato è l'HWND del controllo stesso, non la finestra dell'applicazione o qualsiasi altra finestra che potrebbe contenere gruppi di controlli di primo livello.

L'host di un frammento ricopre un ruolo importante nella fornitura di servizi di UI Automation. Consente lo spostamento fino alla radice del frammento e rende disponibili alcune proprietà predefinite che non devono quindi essere implementate dal provider.

Vedere anche

Concetti

Implementazione del provider di automazione interfaccia utente lato server