jComboBox chiarimenti

[Jason Bourne]

Allora vi spiego il mio problema ho una j combo box :

((EOpzioneInterface)jComboBox.getSelectedItem()).seleziona();

da qui mi uscirebbe un oggetto di tipo opzione

((EOpzioneInterface)jComboBox.getSelectedItem())

e quindi recuperato l'oggetto ci applica il metodo seleziona() che è implementato in opzione che praticamente porterebbe a true un attributo di opzione che inizialmente è a false, il problema è che nella jComboBox ci sono più ozioni e se un utente visualizzando l'interfaccia prima selezziona nella jCombo l'opzione 1 e farebbe questo

((EOpzioneInterface)jComboBox.getSelectedItem()).seleziona();

poi però cambia e seleziona l'opzione 2 cosi poi avremo opzione1 e opzione 2 a true e io devo far si che ne possa selezionare solo una, come si potrebbe fare??

[desa]

Ti tieni memorizzato da qualche parte l'oggetto opzione attualmente selezionato.
Quando un utente cambia la selezione fai:

opzione_selezionata.deseleziona();
opzione_selezionata = (EOpzioneInterface)jComboBox.getSelectedItem();
opzione_selezionata.seleziona();

Dipende da come è strutturata la tua applicazione, ma potrebbe non essere una cattiva idea mettere questo codice a synchronized.

[Jason Bourne]

"Dipende da come è strutturata la tua applicazione, ma potrebbe non essere una cattiva idea mettere questo codice a synchronized."



cosa significa mettere questo codice a synchronized??


e poi si ci ho pensato anche io a questa cosa, ma come faccio a sapere quante volte l'utente possa cambiare idea la tua soluzione va bene nel caso in cui voglia cambiare una sola volta, e come mai non mi si visualizza niente nelle jcombo e nelle jtext quando faccio girare l'applicazione???

[valia]

io associarei alla combo un evento (actionListener per la precisione) in modo da fare
a. aggiorna una variabile di classe che mantiene l'ultimo stato selezionato
b. invoca altra roba che cambiano il valore.

Eviterei la sincronizzazione (non realmente necessaria secondo me).

Ovviamente evita di fare una marea di robe dentro il punto b (eventualmente ricontrolla se è possibile cambiare architettura in modo da non sovraccaricare la jvm con continue chiamate all'action listener)

[desa]

La sincronizzazione ha a che fare con i Thread. Per dirla in parole semplici, se ci fossero almeno due sottoprogrammi (chiamati thread) contemporaneamente in esecuzione che, magari per caso, contemporaneamente cercano di eseguire il tuo metodo, c'è la possibilità che finiscano con il pestarsi i piedi: ovverosia, se il primo thread non ha ancora completato l'esecuzione e il secondo gli va a modificare delle variabili che deve ancora usare, molto probabilmente finiranno entrambi con l'incasinarsi. Tramite l'utilizzo (opportuno) della parola chiave "synchronized" eviti questo problema: finchè il primo sottoprogramma non ha finito, il secondo deve aspettare.

Ad ogni modo, anche io sono convinto che prevedere questo meccanismo nel tuo caso è superfluo, dato che sicuramente avrai in esecuzione solamente un sottoprogramma (quello avviato dal clic sulle combobox)... ma ci tenevo a sollevare il problema

La risposta di valia è in realtà molto simile alla mia: la variabile di classe di cui parla altro non è che quella che avevo chiamato "opzione_selezionata".
La questione è che, prima di sostituirla con quella appena scelta dall'utente, è necessario richiamare un metodo deseleziona() appositamente definito. In questo modo non succede ciò che avevi ipotizzato nel tuo primo post, e cioè che più opzioni possano avere il loro attributo a "true".
Prova a pensarci un attimo, e vedrai che la tecnica funziona indipendentemente dal numero di scelte che farà l'utente.