misonsan ha scritto:
Allora vorrei capire il meccanismo di gestione Eventi.
Ma il concetto non è così difficile. In AWT/Swing esistono svariati "listener", ciascuno per un compito ben preciso e specifico. Ci sono listener di "basso" livello (es. MouseListener) e listener a più alto livello (es. ActionListener).
Un listener è una
INTERFACE Java. Le interfacce si usano sovente/solitamente per definire un "contratto" tra due/più parti. Chi emette gli eventi (un componente GUI o altra entità) si aspetta di ricevere la registrazione di un oggetto che implementa una certa interfaccia con quei metodi ben precisi. E chi vuole ricevere la notifica, implementando quella interfaccia dichiara di rispettare esattamente quel contratto mettendo nella implementazione del listener esattamente quei metodi che sono richiesti dalla interfaccia.
Ciascun componente AWT o Swing può gestire SVARIATI tipi di listener.
JTextField ad esempio possiede:
- addActionListener
- addCaretListener — ereditato da JTextComponent
- addInputMethodListener — ereditato da JTextComponent
- addAncestorListener — ereditato da JComponent
- addVetoableChangeListener — ereditato da JComponent
- addContainerListener — ereditato da Container
- addPropertyChangeListener — ereditato da Container
- addComponentListener — ereditato da Component
- addFocusListener — ereditato da Component
- addHierarchyBoundsListener — ereditato da Component
- addHierarchyListener — ereditato da Component
- addKeyListener — ereditato da Component
- addMouseListener — ereditato da Component
- addMouseMotionListener — ereditato da Component
- addMouseWheelListener — ereditato da Component
Quindi JTextField gestisce (se non ne ho dimenticato qualcuno) 15 listener differenti. Di cui la maggior parte sono "ereditati" dalle super-classi.
addFocusListener ad esempio è in java.awt.Component che è la classe BASE di TUTTI i componenti AWT e Swing. Ma è logico: le notifiche riguardanti il focus c'entrano con tutti i componenti, quindi è ovvio che è stato messo nella classe base.
Idem es. addKeyListener e addMouseListener. Sono generali, validi per TUTTI i componenti. Quindi sono lì nella classe "base".
addCaretListener (il "caret" è quella barrettina lampeggiante che indica il punto dove si inserisce il testo) riguarda solo i componenti "di testo". E quindi è stato messo in J
TextComponent che è la classe base dei componenti appunto di testo.
Il DocumentListener che dicevo prima NON è di un componente GUI ma di un "modello", il Document che è il
model interno ai componenti di testo.
Sulla mia macchina che uso ora avevo messo il Eclipse Photon con il WindowBuilder. NON lo uso normalmente il WindowBuilder ma ho fatto una verifica veloce. Se nella vista "Design" fai tasto destro mouse su un JTextField ti compare un menù di popup con diverse voci tra cui:
Add event handler >
e "sotto" quel menù ci sono voci
action >
ancestor >
.....
propertyChange >
vetoableChange >
Che corrispondono appunto ai 15 addXXXListener che ho detto prima.
Se tu continui a cliccare su propertyChange (che NON ti serve), non si può dare la colpa al IDE o al WindowBuilder. Non è quello che devi scegliere!
Il punto però l'ho detto prima: DocumentListener NON è di JTextField ma del Document interno. E NON compare in quella lista.
E nella vista Properties NON vedo una proprietà "document".
Quindi, pur non conoscendo bene il WindowBuilder ho una mia impressione/sensazione: che il DocumentListener NON lo si possa registrare "graficamente" con il WindowBuilder. E quindi vada registrato e implementato A MANO scrivendo del codice.
Tutto qui. E se così fosse, allora sì, sarebbe un LIMITE del WindowBuilder.