Exception verweist nicht auf mein Programm

Status
Nicht offen für weitere Antworten.

Felix

Bekanntes Mitglied
Hallo zusammen,

ich hab ein komisches Problem: Ich habe eine JTable und möchte die selektierte Zeile beim Drücken der Entfernentaste löschen. Dazu hab ich den folgenden KeyListener geschrieben:

Code:
	public void keyReleased(KeyEvent ke) {
		if (ke.getKeyCode() == KeyEvent.VK_DELETE) { // Key festlegen
			if (ke.getSource() == table) { // Source festlegen
				int row;
				if ((row = table.getSelectedRow()) != -1) {
					if (JOptionPane.showConfirmDialog(this,
							"Wollen Sie die Vokabel wirklich löschen?",
							"löschen?", JOptionPane.YES_NO_OPTION,
							JOptionPane.QUESTION_MESSAGE) == JOptionPane.YES_OPTION) {

						box.getAndRemoveVocable(row);

						this.avoidstuckoverflow = true;
						
						model.removeRow(row);
					}
				}
			}
		}
	}

Wenn ich jetzt aber die letzte (das passiert nur bei der letzten) Zeile versuche so zu löschen, kommt eine Fehlermeldung, die zwar lang ist, aber nicht auf mein Programm verweist. (In dem Fall hatte die Tabelle 4 Zeilen)

Exception in thread "AWT-EventQueue-0" java.lang.ArrayIndexOutOfBoundsException: 3 >= 3
at java.util.Vector.elementAt(Vector.java:447)
at javax.swing.table.DefaultTableModel.setValueAt(DefaultTableModel.java:665)
at javax.swing.JTable.setValueAt(JTable.java:2686)
at javax.swing.JTable.editingStopped(JTable.java:4668)
at javax.swing.AbstractCellEditor.fireEditingStopped(AbstractCellEditor.java:142)
at javax.swing.DefaultCellEditor$EditorDelegate.stopCellEditing(DefaultCellEditor.java:346)
at javax.swing.DefaultCellEditor.stopCellEditing(DefaultCellEditor.java:231)
at javax.swing.JTable$GenericEditor.stopCellEditing(JTable.java:5422)
at javax.swing.plaf.basic.BasicTableUI$Handler.mousePressed(BasicTableUI.java:1013)
at java.awt.AWTEventMulticaster.mousePressed(AWTEventMulticaster.java:280)
at java.awt.Component.processMouseEvent(Component.java:6098)
at javax.swing.JComponent.processMouseEvent(JComponent.java:3276)
at java.awt.Component.processEvent(Component.java:5866)
at java.awt.Container.processEvent(Container.java:2105)
at java.awt.Component.dispatchEventImpl(Component.java:4462)
at java.awt.Container.dispatchEventImpl(Container.java:2163)
at java.awt.Component.dispatchEvent(Component.java:4288)
at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4461)
at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4122)
at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4055)
at java.awt.Container.dispatchEventImpl(Container.java:2149)
at java.awt.Window.dispatchEventImpl(Window.java:2478)
at java.awt.Component.dispatchEvent(Component.java:4288)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:604)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:275)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:200)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:190)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:185)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:177)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:138)

Ich bin jetzt ein bisschen hilflos, weil ich nicht weiß, wo in meinem Programm der Fehler liegt. Könnt ihr mir helfen?

Gruß
der Felix
 
Ich würde sagen, du kommst dir mit dem CellEditor in die Quere. Mach (zum Testen) mal ein SwingUtillties.invokeLater um den Code.
Aus Interesse: this.avoidstuckoverflow = true;
WTF is that?
 
Das Problem ist, dass ich das DefaultTableModel auch zu einem TableModelListener hinzugefügt habe. Da habe ich jetzt schon das Problem, dass ich, wenn ich in diesem TableModelListener etwas in die Tabelle geschrieben habe, einen StuckOverflow ausgelöst habe. Wenn ich avoidstuckoverflow = true setzte, verarbeitet der TableModelListener das nächste Ereignis nicht und damit gibt es keinen StuckOverflow.
Scheint aber, das jetzt mit dem KeyListener öfter als einmal der TableModelListener aufgerufen wird. Kann das Problem hierher kommen?
 
Hab jetzt den konkreten Codeschnipsel nicht nachvollzogen, aber sooo abenteuerlich ist sowas garnicht: Wenn man im klassischen Model-View-Controller-Pattern sowas hat wie
Code:
model.wasChangedAntThrowsEventToUpdateTheView();
und
Code:
class View
{
    void catchEventFromModel() 
    { 
        slider.setValue(model.getValue());  // slider.setValue bewirkt aber wieder ein update des Modells!
    } 
}

hat man schnell einen StackOverflow, den man umgeht, indem man sowas macht wie
Code:
class View
{
    private boolean updating = false;

    void catchEventFromModel() 
    { 
        if (!updating)
        {
            updating = true;
            slider.setValue(model.getValue());  // slider.setValue bewirkt aber wieder ein update des Modells!
            updating = false;
        }
    }
}

(Bei Swing-Component wird das i.a. verhindert, indem NUR dann ein Event geworfen wird, wenn sich wirlich was geändert hat). Allerdings weiß ich nicht, ob das hier auch vorliegt, oder das hier nur ein Hack ist :wink:
 
Marco13, dein Beispiel verstehe ich nicht.
'View' ist eigentlich ein Controller, oder?
Und slider ist eine View?
Aber warum triggert der slider dann ein Event auf dem Modell?
Und wenn slider selbst wieder mit dem Modell verbunden ist, warum muss er dann benachrichtigt werden?
 
Vielleicht hätte ich mehr Zeit für dieses Beispiel aufwenden sollen. Der Controller kann dabei (analog zu den ganze Swing-Klassen) unter den Tisch fallen.

Nochmal abstrakter:

Wenn das Modell geändert wird, dann soll dieser neue Zustand in der View angezeigt werden
(Dazu hängt ein Listener am Modell, der dafür sorgt, dass die GUI sich den neuen Wert holt - dieser Listener kann direkt die GUI sein, oder ein Controller. In diesem Beispiel würde das z.B. bedeuten, dass der Wert eines Sliders verändert wird, so das er den Wert im Modell widerspiegelt)

Wenn in der View etwas geändert wird, wird diese Änderung ins Modell übertragen.
(Dazu hängt ein Listener z.B. an einem Slider, der bei jeder Änderung des Slider-Wertes den neuen Wert ins Modell überträgt)

Wenn man nicht sicherstellt, dass
1. Das Modell nur dann Events feuert, wenn der Wert wirklich geändert (und nicht etwa nur "neu gesetzt") wurde, ODER
2. Die View den Wert des Sliders nur dann setzt, wenn der Event, den sie vom Modell bekommt, NICHT dadurch ausgelöst wurde, dass sie SELBST diesen Wert ans Modell übetragen hat
hat man unendliche gegenseitige Aufrufe.
 
Nach meinem Verständnis sieht MVC in etwa so aus:
1.Fall
Model ändert sich -> View wird informiert -> View holt die neuen Daten ab und passt die Darstellung an

2.Fall
Benutzer interagiert mit View -> View benachrichtigt Controller -> Controller verändert Model -> Model ändert sich -> zurück zu Fall 1
 
Ja, aber die View kann ja nicht unterscheiden, ob z.B. das Verändern des Wertes eines Sliders eine "Anpassung der Darstellung ans Modell" war, oder ob das vom Benutzer gemacht wurde (und das Modell demnach "an die Darstellung angepasst werden muss"). Vom Slider kommt nur ein Event. Man sieht daran nicht, ob der neue Sliderwert ins Modell übertragen werden muss, oder ob er (über welchen Weg auch immer) gerade erst aus dem Modell kommt....

An deinem Beispiel:

1.Fall
Model ändert sich -> View wird informiert -> View holt die neuen Daten ab und passt die Darstellung an

2.Fall
Benutzer interagiert mit View -> View benachrichtigt Controller -> Controller verändert Model -> Model ändert sich -> zurück zu Fall 1

Die beiden fettgedruckten Dinge bewirken, dass (zum Beispiel) der Slider einen Event wirft, d.h. dort wird "View benachrichtigt Controller" ausgeführt.

Wenn das irgendwo vom Controller verhindert werden soll, muss DER sich merken, was er gerade macht ... und dann braucht eben der Controller so ein Flag....
 
Ok, ich glaube ich verstehe dein Beispiel jetzt.
Für mich ist hier die View Komponente ein reiner Renderer, der nur Daten nimmt und visualisiert, also nicht direkt an zB slider.setValue(newValue) gekoppelt ist.
Ich bin wohl schon zu lange in der Welt von SWT/JFace/Draw2D/GEF um bei euch Swingern noch mitreden zu können. :wink:
 
Status
Nicht offen für weitere Antworten.

Neue Themen


Zurück
Oben