Re: any recommendations?
Michael Rauscher wrote:
Brandon McCombs wrote:
Exception in thread "AWT-EventQueue-0"
java.lang.ArrayIndexOutOfBoundsException: 1 >= 0
at java.util.Vector.elementAt(Unknown Source)
at javax.swing.DefaultListModel.getElementAt(Unknown Source)
at javax.swing.plaf.basic.BasicListUI.paintCell(Unknown Source)
at javax.swing.plaf.basic.BasicListUI.paint(Unknown Source)
[snip]
Well the deletion still works when I get the exception. I am doing the
deletion by going through the ListModel for the JList which I thought
was correct. I never knew you could create a read-only ListModel.
NB: a ListModel *is* read-only by default.
The method I call for deleting a selected item from the JList is the
following (model is the instance of BrowserModel):
private void list_deleteObj() {
Is this method called from the EDT?
currently it is not.
The idx in the code above rarely matches (if ever) the index value
listed in the generated exception and again, the deletion above still
works when the exception is generated. Refresh() essentially determines
Sure, the exception originates from the UI-Delegate's paint method. Why
would you expect the deletion not to work?
I never said I didn't expect it to work. I was notifying you guys that
it still was in case you didn't know and needed to know.
The reason for the exception is usually a simple one: you're modifying
the underlying ListModel in one thread while the EDT repaints the list.
Imagine the following pseudo code as part of the painting procedure:
int n = model.getSize();
for ( int i = 0; i < n; i++ ) {
// ...
Object value = model.getElementAt(i);
// ...
}
Let's consider a ListModel that contains 5 elements. The code above runs
on the EDT, so it starts with n = 5 and enters the loop. Now, in another
thread you delete one element from the ListModel so that
model.getSize()==4. The loop continues until i=4, then an
ArrayIndexOutOfBoundsException will be thrown, e.g.: 4 >= 4. If the
second thread would have removed all elements from the ListModel, the
exception is thrown immediately at the next model.getElementAt method
call, e. g. 2 >= 0.
ok that makes sense.
The thread is spawned with this:
...
asyncSearch = new AsyncSearch(this);
...
asyncSearch.start();
Does AsynchSearch modify the ListModel? And if, how?
no. It calls updateGUI() from the component that spawned the thread.
Component is a constructor to that thread class and updateGUI() is an
interface method of an interface I created for that purpose of letting
the components (I got 3 of them) update themselves in their own ways.
Only one of them is involved with this problem though. I'll work on
making the delete method spawn from the EDT.
I don't suppose you guys know of a way I can test this to know for sure
it works?
Bye
Michael