daten in eine Jtable über ein JDialog anzeigen

javama

Erfahrenes Mitglied
Hallo,
ich habe vor kurzem eine Tabelle mit Swing erstellt , die Tabelle hat folgende spalten
(Name, Vorname, Wohnort, Alter , Verheiratet -Boolean-Checkbox), die daten sollen über ein JDialog eingegeben werden, das habe ich auch erstellt.
das problem jetzt wenn ich die daten eingebe und OK drücke werden diese nicht in die tabelle angezeigt (das ganze jetzt ohne persistence ) ich habe keine datenbank , will erst mal nur so probieren. also einfach die daten über JDialog eingeben und in der tabelle anzeigen

hat vielleicht jemand eine Idee, was mir noch fehlt?

ich danke euch im voraus
 
Moin,

hmm, habe jetzt mal auf die Schnelle da durchgescrollt, um den relevanten Code zu finden :rolleyes:

Ich sehe zwar im "actionPerformed" zum buttonOK, dass Du da Daten ermittelst, aber wo werden sie denn in Tabelle eingefügt? (TableModel ?)

Gruß
Klaus
 
... aber ich kann Dir sagen, was uns hier fehlt :

der relevante Code ! ! !

Gruß
Klaus

MADE MY DAY


@TO
Du hast aber schon mal was von Paket-Imports gehört oder ?
Bei der langen Liste an Imports baut der Compiler aus Performance-Gründen daraus eh folgendes :

Java:
import java.awt.*;
import java.awt.event.*;
import javax.swing.*;
import javax.swing.table.*;

Das kannst du gerne mit einem de-Compiler nachprüfen. Ab einer gewissen Menge an Imports aus dem selben Paket wird auf die Strategie "importiere das gesamte Paket* gewechselt. Nur wenn es sehr wenige Imports aus dem selben Paket sind ist eine explizite Klassenangabe sinnvoll.
Auch hat das ganze was mit Lesbarkeit und Übersicht des Codes zu tun.

Was mir dann noch weiter aufgefallen ist :
Java:
private static final long serialVersionUID=1L;
Du hast nicht ernsthaft vor ein JFrame zu serialisieren oder ? Davon abgesehen das diese Zeile ohne das Interface Serializable nutzlos ist und damit beim compilen eh rausfliegt *zumindest sollte sie das bei nem guten Compiler*.

Wobei alles weitere um diese Zeile genau so Käse ist : Objekt-Erzeugungen gehören in einen Konstruktor / eine Methode ! ... NICHT in den static-class-Kontext ! Auch hier greift wieder der Compiler und verschiebt solche Zeilen automatisch in den Konstruktor. Also davon abgesehen das sowas garnicht möglich ist sieht es auch nicht sehr schön aus. *Und zeigt eigentlich das du noch sehr wenig Erfahrung mit Java hast.*

Auch machen mich diese 4 Zeilen sehr stutzig :
Java:
hauptauswahlgui.button1.addActionListener(this);
//...
Davon abgesehen das es nur in sehr wenigen fällen Sinn hat den Inhalt des Konstruktors in eine eigene Methode auszulagern *nichts anderes machst du ... und der Compiler macht es wieder rückgängig da nacher ALLES im Konstruktor steht* gehören solche Dinge in den Konstruktor des jeweiligen Objektes.
Wenn du unbedingt Child-Objekten eines Objektes einen ActionListener der aktuellen Klasse übergeben willst ... dann übergib dem Konstruktor des Objektes eine Referenz auf die aktuelle Klasse *mit this*.
Optimiert würde das *! PSEUDO-CODE ! - compilebares Beispiel* so aussehen :
Java:
package pseudo;
import java.awt.*;
import java.awt.event.*;
import javax.swing.*;
public class MainClass implements ActionListener
{
	private ChildClass childObject=null;
	public MainClass()
	{
		childObject=new ChildClass(this);
	}
	public void actionPerformed(ActionEvent event)
	{
	}
}

class ChildClass
{
	private JButton button=null;
	private ChildClass() { }	// private NULL-Konstruktor
					// verhindert das ein Objekt ohne Übergabereferenz erzeugt werden kann
	protected ChildClass(ActionListener mainClass)
	{
		button=new JButton("BUTTON");
		button.addActionListener(mainClass);
	}
}

Dann fällt mir in der Klass DialogMitarbeiterEinfuegen noch dieser riesige GUI-Builder-Block auf ... da hast du dir ja einiges zusammen geklickt ... nicht gerade hilfreich für den Lerneffekt und -erfolg ... aber solange es funktioniert soll mich das nicht weiter stören ... auch wenn ich es deutlich optimierter schreiben kann.

Und zu guter Letzt fällt mir noch genau das auf was vfl schon sagte : du hast zwar soweit die GUI komplett ... aber von der Logik her fehlt noch das wichtigste : die Daten aus dem Input-Dialog in das TableModel zu übernehmen ...
 
Zuletzt bearbeitet von einem Moderator:
Ich habe auch keine Collection entdeckt, welche die Daten der Tabelle verwaltet. Wäre die vorhanden, könnten die Tabelle mit

JTable table = new JTable(data, columnNames);

angelegt werden. Fügst Du nämlich die Daten in die JTable ein und werden die Daten geändert dann wird das auch in der JTable angezeigt.
 
Zuletzt bearbeitet:
MADE MY DAY


@TO
Du hast aber schon mal was von Paket-Imports gehört oder ?
Bei der langen Liste an Imports baut der Compiler aus Performance-Gründen daraus eh folgendes :

Java:
import java.awt.*;
import java.awt.event.*;
import javax.swing.*;
import javax.swing.table.*;

Das kannst du gerne mit einem de-Compiler nachprüfen. Ab einer gewissen Menge an Imports aus dem selben Paket wird auf die Strategie "importiere das gesamte Paket* gewechselt. Nur wenn es sehr wenige Imports aus dem selben Paket sind ist eine explizite Klassenangabe sinnvoll.
Auch hat das ganze was mit Lesbarkeit und Übersicht des Codes zu tun.

Was mir dann noch weiter aufgefallen ist :
Java:
private static final long serialVersionUID=1L;
Du hast nicht ernsthaft vor ein JFrame zu serialisieren oder ? Davon abgesehen das diese Zeile ohne das Interface Serializable nutzlos ist und damit beim compilen eh rausfliegt *zumindest sollte sie das bei nem guten Compiler*.

Wobei alles weitere um diese Zeile genau so Käse ist : Objekt-Erzeugungen gehören in einen Konstruktor / eine Methode ! ... NICHT in den static-class-Kontext ! Auch hier greift wieder der Compiler und verschiebt solche Zeilen automatisch in den Konstruktor. Also davon abgesehen das sowas garnicht möglich ist sieht es auch nicht sehr schön aus. *Und zeigt eigentlich das du noch sehr wenig Erfahrung mit Java hast.*

Auch machen mich diese 4 Zeilen sehr stutzig :
Java:
hauptauswahlgui.button1.addActionListener(this);
//...
Davon abgesehen das es nur in sehr wenigen fällen Sinn hat den Inhalt des Konstruktors in eine eigene Methode auszulagern *nichts anderes machst du ... und der Compiler macht es wieder rückgängig da nacher ALLES im Konstruktor steht* gehören solche Dinge in den Konstruktor des jeweiligen Objektes.
Wenn du unbedingt Child-Objekten eines Objektes einen ActionListener der aktuellen Klasse übergeben willst ... dann übergib dem Konstruktor des Objektes eine Referenz auf die aktuelle Klasse *mit this*.
Optimiert würde das *! PSEUDO-CODE ! - compilebares Beispiel* so aussehen :
Java:
package pseudo;
import java.awt.*;
import java.awt.event.*;
import javax.swing.*;
public class MainClass implements ActionListener
{
	private ChildClass childObject=null;
	public MainClass()
	{
		childObject=new ChildClass(this);
	}
	public void actionPerformed(ActionEvent event)
	{
	}
}

class ChildClass
{
	private JButton button=null;
	private ChildClass() { }	// private NULL-Konstruktor
					// verhindert das ein Objekt ohne Übergabereferenz erzeugt werden kann
	protected ChildClass(ActionListener mainClass)
	{
		button=new JButton("BUTTON");
		button.addActionListener(mainClass);
	}
}

Dann fällt mir in der Klass DialogMitarbeiterEinfuegen noch dieser riesige GUI-Builder-Block auf ... da hast du dir ja einiges zusammen geklickt ... nicht gerade hilfreich für den Lerneffekt und -erfolg ... aber solange es funktioniert soll mich das nicht weiter stören ... auch wenn ich es deutlich optimierter schreiben kann.

Und zu guter Letzt fällt mir noch genau das auf was vfl schon sagte : du hast zwar soweit die GUI komplett ... aber von der Logik her fehlt noch das wichtigste : die Daten aus dem Input-Dialog in das TableModel zu übernehmen ...



Danke für die Hinweise, ich möchte nur drauf hinweisen , dass die klassen bei mir in unterschidlichen Files sind (also getrennt ), und hier habe ich versucht sie in einem File zusammen zu schreiben , damit das einfacher für die Forum-mitglieder ist.
 
Das ist irrelevant da beim Compilen daraus eh einzlene Class-Files generiert werden. Ob du den Source jetzt in EINER Datei hast oder alles in speraten ... das spielt für die compileten Class-Files keine Rolle ...

btw : es wäre aber übersichtlicher gewesen wenn du jeden Source in einien eigenen Code-Block gepackt hättest anstatt alles in einem ... -> Lesbarkeit.
 
@TO
Du hast aber schon mal was von Paket-Imports gehört oder ?
Bei der langen Liste an Imports baut der Compiler aus Performance-Gründen daraus eh folgendes :

Java:
import java.awt.*;
import java.awt.event.*;
import javax.swing.*;
import javax.swing.table.*;

Egal was der Compiler daraus macht, es gehört zum schlechten Programmierstil bei Imports mit Wildcards zu arbeiten. Eines der wichtigsten Gründe sind potentielle Namenskonflikte, die daraus entstehen können.
 

Neue Beiträge

Zurück