Newsgroup: it.comp.java
Titolo: Come fa Java a capire quando è stato premuto un bottone?

Salve a tutti, siccome sto studiando la gestione degli eventi in Java e 
siccome sono sempre stato un tipo molto curioso, volevo sapere se esiste 
qualche documento in rete che mi spiegasse come fa tutto l'ecosistema O.S. + 
Java a capire quando un utente clicca con il mouse su un bottone (o preme 
invio quando questo ha il focus) e come fa a capire che č stato premuto 
proprio quel bottone.
Non ditemi di chiederlo agli ingegneri della sun/oracle (loro lo sanno 
sicuro) :-D
Grazie.

 invio quando questo ha il focus) e come fa a capire che stato premuto



http://www.netmeister.org/news/learn2quote2.html#ss2.3

 
http://download.oracle.com/javase/tutorial/uiswing/events/intro.html
Forse ho capito male, ma Pippolippo non chiedeva tanto come si fa a 
programmare la gestione degli eventi in Java (mi sembra questo 
l'argomento del link), ma come fa la jvm a capire che deve gestire un 
evento.
Per esempio, se guardiamo il sorgente della classe 
java.awt.event.ActionListener troviamo:
package java.awt.event;
import java.util.EventListener;
public interface ActionListener extends EventListener
  {public void actionPerformed(ActionEvent e);}
Visto che ActionListener estende java.util.EventListener, vediamo il 
codice di quest'ultima:
package java.util;
public interface EventListener {}
...assolutamente vuoto! E qui ci fermiamo. E' chiaro che, quindi, il 
problema diventa capire quale classe invoca il metodo actionPerformed di 
ActionListener, e dove si trova il codice relativo. Ci si potrebbe 
aspettare (ma sto solo inventando!) qualcosa tipo:
ActionEvent e=fattoClickSuButton(Button b);
if (e!=null)
  {
   ActionListener[]a=b.getActionListeners();
   for (int i=0;i<a.length;i++)
    {a[i].actionPerformed(e);}
  }
Ma qui non so dire altro (è anche possibile che, da qualche parte, si 
vada ad eseguire in codice nativo).

 Grazie.
Ciao!
Ottima domanda, tempo fa mi prese la stessa curiosità e ho perso
un'intera nottata a capire da dove arrivassero le chiamate ai listener
dei vari componenti.
Documentazione specifica non ne ho trovata, però grazie ad
un'infarinatura di programmazione API Win32, ti posso dire quello che
succede "dietro le quinte".
La programmazione GUI in Windows (e immagino in tutti gli ambienti
grafici) ruota tutta attorno all'elaborazione di messaggi che il
sistema operativo invia alle finestre appartenenti all'applicazione in
esecuzione. Ridotta all'osso, e togliendo di mezzo tutte le librerie
"comode" nate nel tempo, un'applicazione Windows consiste
esclusivamente in questi passi:
1) creare la finestra principale, più o meno complessa a seconda dei
casi (il sistema operativo provvede a creare anche una coda di
messaggi)
2) visualizzarla a video
3) eseguire il loop:
3a)  pesca il prossimo messaggio
3b)  è una richiesta di fine applicazione?
       SI: esci dal loop / NO: prosegui
3c)  è un messaggio che interessa questa applicazione?
       SI: elabora il messaggio / NO: rimanda il messaggio al S.O.
3d)  prossimo giro nel loop
4) disalloca la finestra, fine applicazione
A finestra visualizzata, il sistema operativo invia tutti i messaggi
che possono interessare l'applicazione, e quando dico "tutti" intendo
proprio *TUTTI* : dal semplice movimento del mouse sulla finestra ad un
messaggio proveniente da un'altra applicazione. Il "trucco", se
possiamo chiamarlo così, sta nel punto 3c, quando vi sono messaggi "non
interessanti" che vengono rimandati al sistema operativo. A questo
punto il S.O. può eventualmente "rimasticare" il messaggio e reinviarlo
all'applicazione in un'altra forma.
Per maggiore chiarezza, ecco quello che succede quando l'utente clicca
su un Button (S.O. rappresenta un messaggio in arrivo):
S.O.: click sulla finesta 0013DA alle coordinate (120, 80)
appl: non mi interessa, te lo rimando
  S.O.: (lì c'è un Button, disegnamolo premuto e intanto informiamo...)
        click sul Button 02AF della finestra 0013DA
  appl: non mi intersssa, te lo rimando
    S.O.: (uhm, l'applicazione ha una tabella di traduzione...)
          Al Button 02AF della finesta 0013DA è associato il comando
          "Invia mail" della tua tabella delle risorse
    appl: allora mi interessa! (mando la mail)
Nel caso di Java, la finestra creata dal codice nativo di Swing
aggancia tutti i messaggi più elementari inviati da Windows, e li
re-inoltra al thread di elaborazione eventi di Swing sotto forma di
oggetti java.awt.AWTEvent .
Il thread degli eventi di Swing a sua volta effettua un loop molto
simile a quello di Win32, però lo fa dentro la Java Virtual Machine. La
coda dei messaggi è raggiungibile tramite:
java.awt.Toolkit.getSystemEventQueue()
...e su questa coda, il thread degli eventi di Swing pesca i messaggi
tramite:
java.awt.Toolkit.getSystemEventQueue().getNextEvent()
Questa chiamata è bloccante, un po' come InputStream.read(). Come per
Windows, l'evento (AWTEvent) pescato può essere rielaborato e può
generare diversi tipi di eventi in cascata. Ma a differenza di Windows,
il listener che riceve l'evento non deve preoccuparsi di rimandarlo al
sistema operativo, dato che l'intera gestione è a carico di Swing. Se
ti interessa un evento più "grezzo" infatti, non devi fare altro che
aggiungere il listener giusto nel punto più opportuno.
Auff... quando mi prende la mano divento veramente logorroico...
Spero di non averti annoiato :)
-- 
erk: C0 CE FE 84 C2 27 F7 5B D0 7A 7E B8 46 50 9F 93 B2 38 E7 70 DA CB
9F F4 A3 88 F8 12 48 2B E2 1B riv: 47 EE 74 54 E4 77 4C C9 B8 96 0C 7B
59 F4 C1 4D - further info: Google it!
(per rispondere personalmente leva IlDitoDalCulo)

 Spero di non averti annoiato :)
No no tutt'altro :-D 

 la JVM e il S.O. ?
E' inevitabile. Ogni classe che interagisca con funzioni del SO prima o 
poi invoca una funzione di libreria (quelle caricate con il metodo 
statico System.loadLibrary(), per intenderci). E la JVM interagisce 
obbligatoriamente con il SO quando deve utilizzare un device (una porta 
com/lpt o la console ad esempio) un'interfaccia di rete, il file-system, 
il sottosistema grafico, etc.etc.
-- 
Dr. Ugo Gagliardelli, Modena, Italy
Spaccamaroni andate a cagare/Spammers not welcome

Be grazie mille, finalmente ho capito a grandi linee il funzionamento di
questo meccanismo "misterioso."
@OcchioDiDrago: Effettivamente una volta mi sono imbattuto in un programmino
scritto con le API Win32 native, il solito "Hello World!", anche se non ci
ho capito molto mi ricordo di uno strato loop che doveva essere eseguite 
incessantemente , credo fosse un ciclo while.
--------------------------------------
"Dr.Ugo Gagliardelli"  ha scritto nel messaggio 
news:ik87ej$8t9$1...@speranza.aioe.org...
il 25.02.2011 12.48, Scrive Pippolippo 65172256:



Prima di tutto, occhio al quoting: su usenet le risposte vanno inserite
sempre dopo gli altri messaggi, in fondo.
Il ciclo while di cui parli è la "message pump", un concetto "antico"
presente sin dalle primissime versioni di Windows (quando ancora girava
in 640Kbyte di RAM). Ormai, con tutti i framework prodotti dal 1985 ad
oggi, non c'è più bisogno di pensare esplicitamente al dispatch dei
messaggi, ma puoi ancora scrivere programmi del genere:
http://msdn.microsoft.com/en-us/library/ff381409(v=VS.85).aspx
Quanti ricordi...
