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 -----
Fehler in Programmtabelle
Fehler in Programmtabelle
Mit der aktuellen CVS-Version, nachdem ich ein anderen Filter gewählt hatte.
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.
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.
?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.
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...