Dove si trova l'interfaccia tra il clic del pulsante e l'innalzamento degli eventi definito

1. L'hardware del mouse invia messaggi molto semplici sul bus USB quando appropriato, in sostanza "il pulsante x è stato premuto / rilasciato" e "spostato molto nelle direzioni x e y dall'ultimo messaggio inviato".
2. Il driver USB del computer sta eseguendo il polling di questi messaggi (controllando periodicamente) o riceve un interrupt , che è un meccanismo incorporato nell'hardware che dice "Ho un nuovo USB messaggio in modo che sto eseguendo il codice in una posizione particolare. "
3. Il driver USB passa il messaggio al driver del mouse nel kernel.
4. Il driver del mouse passa il messaggio al sottosistema grafico (come xorg su Linux).
5. Il sottosistema grafico tiene traccia della posizione assoluta del mouse, aggiornandolo dai relativi messaggi di posizione inviati dal driver del mouse.
6. Il sottosistema grafico passa gli eventi al gestore di finestre (come mutter ).
7. Il gestore di finestre tiene traccia di quale finestra è sotto il mouse e passa gli eventi di clic al toolkit di windowing (come Qt ) associato a quella finestra.
8. Il windowing toolkit tiene traccia di quale pulsante è sotto il mouse, esegue l'animazione dei clic utilizzando le primitive grafiche e passa gli eventi ai listener iscritti.

Ovviamente l'implementazione è diversa per i diversi sistemi operativi. In particolare, Windows raggruppa molti strati per il programmatore e il punto di vista dell'utente, ma questa è la disposizione base del terreno. Ti ho dato alcuni nomi per Linux perché quelli sono open source e se fossi così inclinato da poter rintracciare tutto dal silicio in su. Qt e altri toolkit widget, che sembra essere la parte che ti interessa di più, sono disponibili anche per Windows.

È piuttosto sorprendente contemplare il flusso preciso di elettroni necessari iniziando dallo switch del pulsante del mouse, attraverso la CPU, verso Internet e viceversa attraverso innumerevoli router e server, tornando indietro attraverso la CPU, fino a ottenere ogni singolo pixel sul tuo display che viene comandato al suo colore specifico. Riassumiamo il risultato di milioni di ore di sforzi collaborativi semplicemente come "fare clic su un collegamento".

Non c'è davvero un'interfaccia. C'è l'oggetto che solleva l'evento e poi un delegato (s) che gestisce l'evento. L'oggetto che solleva l'evento non ha idea di chi / cosa / come verrà gestito l'evento. Solleva semplicemente l'evento con qualsiasi dato rilevante sul messaggio in modo che i delegati possano gestirlo correttamente.

Il delegato deve registrarsi come gestore per quell'evento.

Qualcosa del genere:

button1.Click += new EventHandler(button1Click);

Quindi ci sarà il metodo che gestirà l'evento:

void button1Click(object obj, EventArgs e)
{
    //Do Something with the click
}

Non è garantito che " Event Driven Programming Model " esisterà sulla tua piattaforma o ambiente. Succede su Windows che questo sia supportato.

Con .Net, il supporto viene fornito con la possibilità di generare eventi e utilizzare i delegati per gestirli. C'è anche costruito nel supporto asincrono pure.

Sotto, il sistema operativo (Windows) ha un messaggio pompa o ciclo che è costantemente in bicicletta e gestisce i messaggi che vengono pubblicati. In genere, nei linguaggi di livello superiore non è necessario interagire con gli interni poiché questi sono protetti dal framework con spazi dei nomi come System.Windows.Forms . Ma puoi avvicinarti al pump dei messaggi lavorando direttamente con l'API di Windows (se lo desideri).

Puoi saperne di più sul messaggio pompa qui:

link