Seite 1 von 1
Fehler in Programmtabelle
Verfasst: 29 Okt 2004, 16:41
von platin(x)
Mit der aktuellen CVS-Version, nachdem ich ein anderen Filter gewählt hatte.
Ein nicht behandelter Fehler ist aufgetreten
----- Start of stacktrace -----
java.lang.ArrayIndexOutOfBoundsException: 3
at tvbrowser.ui.programtable.DefaultProgramTableModel.getRowCount(DefaultProgramTableModel.java:289)
at tvbrowser.ui.programtable.ProgramTable.paintComponent(ProgramTable.java:215)
at javax.swing.JComponent.paint(Unknown Source)
at javax.swing.JComponent.paintWithOffscreenBuffer(Unknown Source)
at javax.swing.JComponent.paintDoubleBuffered(Unknown Source)
at javax.swing.JComponent._paintImmediately(Unknown Source)
at javax.swing.JComponent.paintImmediately(Unknown Source)
at javax.swing.RepaintManager.paintDirtyRegions(Unknown Source)
at javax.swing.SystemEventQueueUtilities$ComponentWorkRequest.run(Unknown Source)
at java.awt.event.InvocationEvent.dispatch(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)
----- End of stacktrace -----
Verfasst: 29 Okt 2004, 16:51
von bodo
Wie hast du den Filter gewechselt? So wie's aussieht hat der beim Neuzeichnen den Filter reingehauen, so das der nich mehr die richtige Anzahl von Spalten hatte ?!
Verfasst: 29 Okt 2004, 18:23
von platin(x)
Menübar, Ansicht => Filter
Verfasst: 29 Okt 2004, 18:39
von bodo
Til, da muss das Model noch Synchronisiert werden, oder?
Verfasst: 30 Okt 2004, 09:16
von Til
Das bringt nicht viel. Es ist blöd, wenn man sich nicht darauf verlassen kann, dass getRowCount() in der nächsten Sekunde sich geändert hat, wenn man es aufruft.
Ich fände besser, wenn alles, was im TableModel gemacht wird, im Swing-Thread zu passieren hat. Dann können wir uns den synchronized-Kram sparen, der ja auch nur bedingt weiterhilft. Es hilft ja niemand was, wenn die Methoden des TableModel selbst synchronisiert sind, aber der aufrufende Kontext nicht.
Ich schlage deshalb vor, dass wir die synchronized-Sachen wieder rauskicken und durch Prüfungen ersetzten, die schauen, dass auch ja der richtige Thread genutzt wird. In der Entwicklerversion können wir bei einer Verletzung eine Exception schmeissen, so finden wir wohl recht schnell alle Stellen, die am Model herumpfuschen und können sie in ein SwingUtilities.invokeLater() verpacken. Danach können wir eine einfache Warnung ausgeben.
Verfasst: 30 Okt 2004, 09:24
von bodo
OK. Klingt gut!
Verfasst: 30 Okt 2004, 14:42
von Til
Alla gud, dann mach ich das mal...
Verfasst: 31 Okt 2004, 19:42
von bodo
Du hast bei den setProgramFilter keine Thread-Überprüfung eingebaut. War das absicht
?
Verfasst: 31 Okt 2004, 20:01
von Til
setProgramFilter macht selbst nichts dramatisches. Es ruft jedoch updateTableContent auf und das hat eine Prüfung. Ich hab nur da Prüfungen reingebaut, wo auf die Variablen mChannelArr, mShownChannelArr, mProgramColumn oder mShownProgramColumn zugegriffen wird. Die enthalten die eigentliche Model-Information.
Verfasst: 31 Okt 2004, 20:26
von bodo
Muß jetzt noch in den MainFrame ins setProgramFilter noch ein invokeLater rein?
Verfasst: 31 Okt 2004, 20:47
von Til
Momentan wird eine Exception geworfen, wenn das Model außerhalb vom Swing event thread verwendet wird. Filter wechseln habe ich probiert. Das schein schon im richtigen Thread gemacht zu werden. Du kannst da gerne ein invokeLater reinpacken, schaden kann es nicht, aber nötig ist es momentan auch nicht...