Nei precedenti articoli sulla programmazione labview, abbiamo utilizzato la struttura ad eventi, utilizzata negli stati Event/Idle per attendere un input da Interfaccia Grafica (UI).
In questo articolo parliamo di programmazione Event Driven.
La caratteristica dell’ Event Driven è dato dall’ordine di esecuzione del codice, guidato dagli eventi.
La differenza rispetto al polling, che si basa sul monitorare continuamente il valore di un input per l’esecuzione del codice, nella programmazione Event Driven, guidano gli eventi ovvero le azioni, i cambiamenti di valore, le azioni eseguite dall’utente, come il click del mouse. Si ottiene quindi un maggior numero di possibilità di controllo. Gli eventi possono essere scatenati dall’ultente
Static Event
Eventi che a loro volta possono essere di tipo Notifier e o Filter (Prima di eseguire l’evento chiedo, es. PanelClose? permettono di annullare l’evento (Discard?=T).
Eventi Dinamici
Gli eventi dinamici, sono definiti da utente (User Event) mediante registrazione alla event structure.
Nell’articolo Queues Vs Notifier, abbiamo visto i Notifier (singolo elemento, no memoria, MultiWriter,MultiReader) e le Queues (Buffer, No perdita dati, MultiWriter SingleReader).
Il meccanismo degli user event è un mix tra i due, infatti può avere relazioni modificabili (Multi-Writer,Single-Reader e Multi-Writer,Multi-Reader) e funziona generando dati su un buffer FIFO, anche qui ogni buffer deve essere registrato quindi chi vuole ricevere i dati deve registrarsi all’evento.
Abbiamo quindi già un primo vantaggio rispetto alle code, inoltre l’evento lavora sul dato, per cui chi lo riceve riceve anche il dato.
Per spiegare meglio, facciamo riferimento alla QSM invio una stringa per decidere il case e un variant per passare il dato.
In questo caso invece l’evento è messaggio e porta con se il dato.
In questo caso è il parametro stesso a generare uno stato/evento, senza dover ricorrere al variant.
Vantaggi principali dell’event driven.
- Mantengono memoria come per le code.
- MultiWriter e MultiReader.
- il messaggio incapsula il dato.
- Possono essere utilizzate in combinazione con eventi statici per le interfacce.
Use case Event Producer/Consumer
In questo esempio, abbiamo creato un evento (Create User Event), facendo attenzione di dare una label alla costante boolean (questo sarà il nome dell’evento nella struttura Event).
Ci sono tre processi con strutture ad eventi, nella prima che rappresenta il producer, non registriamo l’evento perchè sarà il generatore di eventi, ovvero lui non deve rispondere al <GlobalStop>:User Event, ma lo genera.
Gli altri due processi invece registrano lo User Event attraverso il metodo Register Event.
Infatti i due processi che saranno i consumer, aspettano l’evento e lo eseguono quando viene generato dal primo processo (UI-Handle).
Registrando questi eventi possiamo comunicare tra strutture ad eventi in cui quel particolare evento è stato registrato.
Conclusione
La programmazione Event Driven permette un utilizzo delle risorse più efficiente, semplifica il codice e permette il controllo di eventi dell’ interfaccia come eventi del mouse, finestre.
