KuroKami69 ha scritto:
Sul addVeicoli te gli passi una list altri veicoli, ma quella come avevi pensato di crearla?
In qualsiasi modo, era solo per dare la possibilità a chi usa il modello di aggiungere elementi da un'altra lista invece che essere costretto ad aggiungerne uno alla volta. Ad esempio se hai già creato la tabella e vuoi aggiungere tutti i veicoli che leggi da un altro file.
Ma più semplicemente: quando hai 10 righe nella tabella e sullo spinner inserisci 20, al momento tu vuoi aggiungere 10 veicoli, quindi ne crei uno alla volta e lo passi al modello, che dice alla tabella di ridisegnarsi. Ma se sai già di crearne altri dieci, puoi crearti una lista temporanea nel tuo metodo, aggiungerci tutti i dieci veicoli, e poi passare la lista al modello, che così deve aggiornarsi una volta sola.
E' solo una possibilità, non è fondamentale.
KuroKami69 ha scritto:
Usare un unica lista è MOLTO più semplice da gestire, ma chiaramente comporta dei limiti, ossia che avrò sempre veicoli nuovi, usare 2 liste invece mi permette, come da voi suggerito, di salvare tutti i veicoli che creo in una lista e di averne una usa e getta che uso per visualizzare o auto o moto, e che caricherà i veicoli dalla seconda. è questo che prevedeva il tuo esempio?
Questo era il vecchio consiglio che ti avevo dato per filtrare le righe senza sbatterti con un RowFilter. Ma quel metodo addVeicoli () non ha niente a che fare con questo, ho messo un metodo che accetta una lista di veicoli da aggiungere solo per fare la cosa più velocemente e dare una possibilità in più.
KuroKami69 ha scritto:
(A questo punto mi piacerebbe implementare un checkbox che dice, sostanzialmente, se lavora con una sola lista o se lavora con 2, però ho paura che dopo diventerebbe difficile da gestire, perché se passo dal lavorare con una lista a lavorare con 2, perderò tutti i veicoli del primo metodo, mentre quelli del secondo, credo, continueranno ad accumularsi a ogni switch di modalità quindi mi sembra improponibile come cosa)
Mmh quello che dici qua, soprattutto nella seconda parte, sinceramente non l'ho capito. E non c'è alcun motivo per cui tu debba perdere o aggiungere veicoli in più, mi sa che hai frainteso lo scopo di quella lista come argomento (puoi anche toglierlo quel metodo come dicevo).
Ma, in quanto al checkbox, mi pare una brutta idea, è il modello che "sa" come i dati sono memorizzati all'interno, quello sì che è compito suo, la classe con i componenti non sa niente di questo, e francamente come opzione non mi pare sia utile, non aggiunge alcuna funzionalità, e non è nemmeno facile da capire per un utente.
KuroKami69 ha scritto:
P.S. i metodi add e remove son giusti?
public void addVeicoli(Veicolo veicolo)
{
veicoli.add(veicolo);
fireTableRowsInserted(veicolo.size()-1, veicoli.size());
}
public void removeVeicoli(int rowIndex)
{
if (rowIndex < 0 || rowIndex >= veicoli.size ()) return;
veicoli.remove(rowIndex);
fireTableRowsDeleted(veicoli.size()-1, veicoli.size());
}
il firetablepiù che altro, ci ho pensato e mi sembra corretto, visto che questi metodi prevedono l'add e il remove di un veicolo per volta, e che poi vengono loopati nella tabella
No, il fire non è corretto. Nel primo metodo devi passare gli indici delle nuove righe inserite, inclusi, e visto che aggiungi una sola riga il primo indice deve coincidere con il secondo. Se hai 3 righe ad esempio, e ne aggiungi una quarta, la nuova riga inserita è la quarta, con indice 3. Quindi il fireTableRowsInserted va chiamato con il range [3, 3], perché è la sola riga inserita.
Per la rimozione vale un discorso simile (se la soluzione non ti viene al volo ti basta prendere carta e penna e farti un esempio con indici di prova per vedere la regola).
KuroKami69 ha scritto:
public void changeRowNumber(int newRowCount)
{
int oldRowCount = atb.getRowCount();
if (newRowCount != oldRowCount)
{
if (oldRowCount > newRowCount)
{
while(atb.getRowCount() > newRowCount)
atb.removeVeicolo(newRowCount);
}
else
{
while(veicoli.size() < rowIndex)
{
if(DisplayMode.AUTO_ONLY)
{
//rifare il costruttore di veicolo e automobile
//veicoli.add(new Automobile(d.setMarcaAuto(a), d.setModelloAuto(a), d.setTipoAuto(n), d.setPrezzoAuto(n), d.setCavalliAuto(n), d.setMassaAuto(n), d.setCilindrataAuto(n), d.setConsumoAuto(n)));
}
else if(DisplayMode.MOTO_ONLY)
{
//rifare il costruttore di veicolo e automobile
//veicoli.add(new Moto(d.setMarcaAuto(a), d.setModelloAuto(a), d.setTipoAuto(n), d.setPrezzoAuto(n), d.setCavalliAuto(n), d.setMassaAuto(n), d.setCilindrataAuto(n), d.setConsumoAuto(n)));
}
else
{
}
}
}
}
}
Beh non è che sia un granché sistemato il codice no? Hai commentato le vecchie parti dove crei i veicoli, che come detto vanno totalmente cambiate.
Inoltre non sei più dentro il TableModel (per fortuna), quindi non hai più accesso a veicoli, non lo devi proprio usare.
La parte dove rimuovi i veicoli va bene. Poi al posto di veicoli.size () devi chiedere come sopra al modello il numero di righe. E anche l'if con le modalità non è corretto. Non è un boolean, non puoi fare
if (valore), sarebbe come scrivere
if (3).
Devi fare un confronto: prendi la modalità di visualizzazione "corrente" della tabella, e la confronti con == con i vari elementi della enum.
O usi il metodo che ti ho scritto io, quel checkDisplayMode (che ritorna la modalità impostata in base a quale radiobutton è selezionato), ed assegni il risultato del metodo a una variabile per poi fare il confronto, o chiedi la modalità direttamente al modello, a patto che tu la aggiorni all'interno del modello ad ogni modifica (ti avevo suggerito di usare un setDisplayMode nel modello a riguardo).
KuroKami69 ha scritto:
I radio, però qua ho la vaga idea che in quel checkdisplaymode gli devo passare il e.getsource, altrimenti non fa nulla ahahahaha
JRadioButton auto = new JRadioButton("Auto", true);
JRadioButton moto = new JRadioButton("Moto");
JRadioButton both = new JRadioButton("Entrambi");
auto.setSelected(true);
class RadioButtonActionListener implements ActionListener
{
@Override
public void actionPerformed(ActionEvent e)
{
JRadioButton button = (JRadioButton)e.getSource();
checkDisplayMode();
}
}
No, non è questo il modo in cui va usato quel metodo. Se vuoi implementare un listener sui radiobutton, quando ricevi un evento devi controllare quale radio button è selezionato, e in base a quello setti al modello la modalità di visualizzazione corretta. Usare così il checkDisplayMode () non serve a nulla, non viene assegnato a niente il risultato.
E il getSource () non ti risolve nulla, lascia stare, usa sempre isSelected () per controllare quale dei radiobutton è selezionato.
KuroKami69 ha scritto:
[...]
Io allora avrò il metodo che popola l'array di marche e modelli, poi avrò un metodo che genererà un random e mi ritornerà il valore dell'array corrispondente, e quindi avrò una cosa tipo
new Automobile(selezionaMarca(), SelezionaModello(), ecc ecc)
giusto?
oppure sto ancora fraintendendo qualcosa?
Meglio la lista rispetto all'array, lo abbiamo già detto, con la lista sai sempre quanti elementi hai all'interno, ed è anche più comoda da gestire per l'inserimento quando non sai a priori quanti oggetti dovrà contentere.
Il resto tecnicamente è corretto, ma non so se hai capito dove vanno inseriti quei metodi selezionaMarca () etc. Quei metodi devono essere nella classe CostruttoreVeicoli (o come vuoi chiamarla) che è l'unica ad avere le liste e che può quindi prenderne un elemento (anche a caso) all'interno.
Ma avere un metodo per ogni selezione mi pare eccessivo, ti basta una riga di codice. Se hai la lista di modelli definita come
List <String> modelliAuto, per prenderne un elemento casuale ti basta scrivere:
String modello = modelliAuto.get (random.nextInt (modelliAuto.size ()));
// qui puoi passare modello e tutte le altre variabili al costruttore di Automobile
Come vedi è molto più semplice rispetto a scrivere un metodo per ogni attributo, avresti un codice infinito (non che sia poco per ora, ma è inevitabile se vuoi avere tutti quei dati).
L'importante è che modelliAuto sia riempita nel costruttore (leggendo da file, ad esempio) e che random sia un oggetto Random anch'esso costruito solo alla creazione della tua istanza (non ha senso averne più di uno).