✔ daten in eine Jtable über ein JDialog anzeigen

[SE]

NEIN ! Eben nicht ... wo bitte in deiner überschriebenen setValueAt() Methode wird das veränderte Mitarbeiter-Objekt denn wieder in das TableModel geschrieben ? Nur weil du eine Methode so überschreibst heißt es nicht das sie automatisch das tut was sie tun soll. Deine überschriebene Methode führt etwas aus ... ja .. aber NICHT das was sie soll.

Hier mal der original Code *Java7*

public void setValueAt(Object aValue, int row, int column)
{
	Vector rowVector=(Vector)dataVector.elementAt(row);
	rowVector.setElementAt(aValue, column);
	fireTableCellUpdated(row, column);
}

Was passiert hier ?
1) Der RowVector der die Daten für die aktuelle Zeile enthält wird aus dem DataVector extrahiert
2) innerhalb das RowVectors wird das gewünschte elemt dierekt verändert
3) Die Zelle wird neu gerendert

Und in deinem Code fehlen einfach mal die Punkte 1 und 2 ... wesshalb sich im TableModel NICHTS ändert weil du nirgends auf den DataVector zugreifst und diesen manipulierst ... und DESSHALB ändert sich beim re-rendern auch nicht an der Anzeige.

Das ist ganz simples OOP ... von dem du scheinbar keine Ahnung hast.

 

[javama]

Danke es hat jetzt funktioniert

@Override
	public void setValueAt(Object wert, int zeile, int spalte) {
		
     Vector mitVector = (Vector)dataVector.elementAt(zeile);
		mitVector.setElementAt(wert, spalte);
			fireTableCellUpdated(zeile, spalte);
		
	}

soll man den Vector Typesieren, oder kann man die Methode optimieren sodass man keine Warning mehr hat

 

[vfl_freak]

Moin,

was genau meinst Du mit "typisieren" ?
Welche Warning ?

Gruß
Klaus

 

[javama]

Moin,

was genau meinst Du mit "typisieren" ?
Welche Warning ?

Gruß
Klaus

z.B. Vector<...>

warning: Vector is a raw type. References to generic type Vector<E> should be parameterized

 

[vfl_freak]

ach so, generics ....

Ja, die sind schon seit Java5 Pflicht und sollte man auch konsequent einsetzen!

Gruß
Klaus

 

[j2se]

soll man den Vector Typesieren, oder kann man die Methode optimieren sodass man keine Warning mehr hat

Zur Typsicherheit ist es natürlich besser den Vector zu typisieren. Man erspart sich auch ein cast beim Lesen.

Mit der Annotation @SuppressWarnings("unchecked") kriegst Du das Warning weg.

 

[vfl_freak]

Moin,

Mit der Annotation @SuppressWarnings("unchecked") kriegst Du das Warning weg

also ich habe mir angewöhnt, Warnings nie zu ignorieren (ob mit SuppressWarnings, zu seicht eingestelltem Compiler oder wie auch immer).
Die Argumente von einigen Kollegen von mir ("ist ja NUR 'ne Warning") finde ich persönlich sehr ignorant!
Es gibt immer einen guten Grund für eine Warning; sie zu prüfen und dann zu beseitigen dauert doch meist nur ein paar Sekunden !

Als ich hier meine 6 Projekte übernommen habe, durfte ich jeweils so zwischen 3.000 und 5.000 Warnings entfernen (!!) - in durchschnittlich gut 50.000 Programmzeilen !

Gruß
Klaus

 

[SE]

@TO
Natürlich bekommst du eine Warning weil ich den Code auch nur so aus dem Source-File kopiert habe ...
Nach dem compilen hast du sowieso nur noch den RAW-Type *Type-Ereasure* ... in diesem Fall kannst du die Warning wirklich vernachlässigen da es nach dem Compilen genau so in der Class steht wie jetzt im Source

*Wer kam eigentlich auf diese Idee Generics durch Type-Ereasure abwärtskompatibel zu machen ? Der gehört echt an die Wand.*

 

[javama]

kann mir jemand erklären was ist der Unterschied zw.

@Override
	public Class<?> getColumnClass(int columnIndex) {
		if(columnIndex == 4) { return Boolean.class; }

		return super.getColumnClass(columnIndex);
	}

und

/*
	 * JTable uses this method to determine the default renderer/ editor for
	 * each cell. Hierdurch wird ("true"/"false")als checkBox dargestellt.
	 */
	@SuppressWarnings("unchecked")
	public Class getColumnClass(int c) {
		try {
			return getValueAt(0, c).getClass();
		}
		// Für den Fall, dass die Tabelle leer ist
		catch (ArrayIndexOutOfBoundsException e) {
			return Object.class;
		}
	}

Also die erste Methode kann ich nachvollziehen aber die zweite habe ich nicht verstanden besonders die 0 bei getValueAt(0, c) , warum eigentlich 0?

 

[SE]

Was die Methodensignatur an sich angeht unterscheiden sich beide Methoden NACH dem Compilen nicht mehr ... beide haben dann folgende Signatur

public Class getColumnClass(int)

Das passiert durch sog. Type-Ereasure um Generics-Klassen abwärtskompatibel zu halten *was eigentlich so nicht funktioniert da es Generics erst seit Java5.0 gibt ... und mit Java5.0 compilte Klassen eh nur mit mindestens Java5.0 ausgeführt werden ... von daher -> Schwachsinn*.

Ansonsten returnen die beiden Methoden Objekte vom Typ Class ... welche genau und warum ist eigentlich eher unwichtig.