La gestione degli eventi Antonio Cisternino Programmazione ad

La gestione degli eventi Antonio Cisternino

Programmazione ad Eventi þCome abbiamo visto dagli esempi esiste un pattern comune ai vari sistemi per la gestione degli eventi þLa gestione degli eventi nelle interfacce si articola in: üGestione degli eventi all’interno dell’applicazione üGestione degli eventi del gestore dell’interfaccia grafica

Delegate Event Model þQuesto modello, inizialmente introdotto da Java 1. 1, è ormai quello più diffuso nei framework di programmazione di GUI þIl modello prevede: üUna sorgente degli eventi (es. il bottone) üI consumatori degli eventi üDelle interfacce (un modo di comunicazione concordato tra il produttore e il consumatore)

Schema di funzionamento Consumatori registrati Sorgente Eventi (es. Button) Listeners (interfaccia richiesta dalla sorgente)

Il pattern in Java þIl delegate event model può essere implementato in vari linguaggi þIn Java è realizzato utilizzando: üConvenzione sui nomi dei metodi per registrare consumatori presso la sorgente (add. XXXListener(XXXListener l)) üInterfaccia che la sorgente usa per comunicare l’evento (XXXListener) üInvocazione dell’evento: la sorgente invoca uno dei metodi dell’interfaccia XXXListener

Chi fa cosa þProduttore di eventi: üadd. XXXListener üremove. XXXListener üDefinisce una classe XXXEvent üDefinisce l’interfaccia XXXListener þConsumatore di eventi üImplementa l’interfaccia XXXListener üSi registra presso il produttore

Il punto di vista dei controlli þIl delegate event model, ideale per chi usa controlli, presenta problemi nella gestione degli eventi dei controlli þCome si fa a rendere “trasparente”un controllo ad un evento? þAd esempio: il click su una label potrebbe convenire che sia notificato alla finestra che lo contiene

Propagazione degli eventi þ Il bubbling di un evento si ha quando viene passato al contenitore di chi lo ha ricevuto þ In questo modo si possono implementare i comportamenti di default þ Si possono anche gestire in modo centralizzato eventi di un controllo composto da finestre

Tunneling þ Framework come WPF (aka Avalon) supportano anche il flusso in direzione inversa al bubbling degli eventi: il tunneling þ Questo flusso (solitamente seguito dal bubbling) offre la possibilità al contenitore di un controllo di gestire un evento prima che arrivi al figlio þ Il gestore dell’interfaccia decide, per ogni tipo evento, se è diretto, se fa uso di bubbling, o tunneling e bubbling

Implementiamo il bubbling þ Nei linguaggi orientati ad oggetti il bubbling viene facilmente scaricato sulla gerarchia dell’ereditarietà þ Nei framework OO normalmente tutti I componenti grafici ereditano da una classe base, ad esempio Component þ Dalla classe base tutti i componenti ereditano (direttamente o meno) un metodo deputato alla gestione degli eventi þ Il componente vede passare tutti gli eventi a lui diretti, e può gestirli localmente o delegare

Un esempio þ Java, nella sua prima versione (fino alla versione 1. 0. 2) aveva un modello di gestione degli eventi come OWL (Borland) e MFC (Microsoft) basato su bubbling þ La possibilità di invocare il metodo della superclasse consente di delegare la gestione di un evento non gestito (o solo parzialmente gestito) þ Il dispatch e la classificazione degli eventi viene tipicamente incapsulato da metodi invocati dal metodo che gestisce gli eventi, inclusa la delega

Java AWT Event Model class Component { int x, y; bool handle. Event(Event e); } class Button extends Component { String text; bool handle. Event() { } … } class Window extends Component Frame extends Window

Event handling class My. Button extends Button { boolean handle. Event(Event e) { switch (e. type) { case Event. MOUSE_UP: … return true; // Event handled! } default: return super. handle. Event(e); }}

Dal bubbling alla delegation þI controlli, nella gestione degli eventi, possono implementare l’interfaccia necessaria per essere una sorgente di eventi þPer fare questo si possono intercettare gli eventi, ed invocare il metodo dei consumatori registrati þLa delegation migliora le performance: la gestione degli eventi non necessita l’introduzione di nuove classi

L’event loop þChi invoca gli event handler? þUn thread dell’applicazione spende una porzione significativa del suo tempo nell’event loop þL’event loop ha la seguente struttura: while (m=Pick. Message()) Dispatch. Message(m) þUn qualche metodo (più o meno nascosto) esegue questo ciclo

L’event loop þ Normalmente l’event-loop viene incapsulato in qualche classe (Application. Run per. NET, Swing. Utilities. invoke. Later in Java) þ La funzione di dispatch del messaggio si occupa di inoltrare il messaggio al componente dell’applicazione interessato þ Questo innesca il meccanismo di chiamate che poi va a chiamare gli event handler definiti dall’applicazione

Thread or threads? þ Quanti thread gestiscono l’event loop? þ A dispetto dell’apparente concorrenza degli eventi il thread della UI è uno þ Se un event handler lo blocca l’intera interfaccia dell’applicazione smette di funzionare þ Se quindi è necessario intraprendere un qualche lavoro significativo è bene avviare un thread nell’event handler a cui delegare il compito

Troviamo il colpevole þ Come fa il gestore dell’interfaccia a individuare il destinatario di un evento? þ Input da tastiera: il controllo che ha il focus riceve il messaggio ü Spesso il focus si ottiene evidenziando il controllo ü Usando il tab è possibile spostare il focus su altri controlli þ La pick correlation consiste nell’associare un evento del puntatore con il controllo a cui è diretto

Pick Correlation þ Come facciamo a sapere quale controllo deve ricevere gli eventi del puntatore? þ Abbiamo a disposizione le coordinate del punto (x, y), ma non sono sufficienti! þ Siamo tutti abituati a sovrapporre finestre: qual’è quella visibile? þ Il gestore dell’interfaccia organizza in modo appropriato le finestre e per ciascuna ricorda lo z -index ovvero un indice che indica l’ordinamento lungo l’asse Z

Finestre e Z-Ordering þ La struttura dati primitiva delle interfacce grafiche (fino ad oggi…) è la finestra: un’area rettangolare dello schermo þ Tutti i controlli non sono altro che finestre specializzate þ Per trovare a quale finestra corrisponde un punto (x, y) sullo schermo è necessario ü trovare tutte le finestre che lo contengono ü tra queste prendere quella con z-index più alto þ Le finestre sono organizzate in un albero che consenta l’implementazione della ricerca in modo più efficiente (sfruttando il contenimento)

Usare Spy++ þ Spy++ è un tool Microsoft (ne esistono analoghi per XWindows) che consente di monitorare gli eventi diretti a finestre þ È anche possibile analizzare la struttura di un’applicazione in termini di finestre

Osserviamo gli eventi þSe abilitiamo il log degli eventi su un bottone della calcolatrice notiamo che: üGli eventi di paint arrivano in momenti inattesi üCi sono molti tipi di eventi þSe invece facciamo il log della finestra vediamo in azione il bubbling: alcuni eventi sui figli sono inviati anche al padre