Come fa Java a capire quando è stato premuto un bottone?
Pippolippo
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.
Fabry
gestione degli eventi:
http://download.oracle.com/javase/tutorial/uiswing/events/intro.html
Bye bye
On 22 Feb, 00:10, "Pippolippo" <key...@live.it> wrote:
> 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
Snow Bros
Marco
>> 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
> Basta leggere e cercare su internet ... tutto ruota intorno alla
> gestione degli eventi:
> 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).
OcchioDiDrago
> 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
>
> Non ditemi di chiederlo agli ingegneri della sun/oracle (loro lo sanno
> sicuro) :-D
>
> 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)
Pippolippo
A quanto mi ￜ parso di capire quindi c'ￜ una stretta collaborazione tra la
JVM e il S.O. ?
Saluti.
"OcchioDiDrago" ha scritto nel messaggio
news:mn.b4c27db28...@email.it...
> Auff... quando mi prende la mano divento veramente logorroico...
> Spero di non averti annoiato :)
No no tutt'altro :-D
Dr.Ugo Gagliardelli
> Perfetto grazie, era proprio quello che cercavo.
>
> la JVM e il S.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
Pippolippo
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:
OcchioDiDrago
>
> "Dr.Ugo Gagliardelli" ha scritto nel messaggio
> news:ik87ej$8t9$1...@speranza.aioe.org...
>
>>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.
>
> 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.
>
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...