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?
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?
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.
Although what you say makes sense, I wonder if it's my problem because
I'm modifying the model outside of the EDT (whatever that situation is
properly termed) and after a few other method calls is when the model is
updated with new nodes. I don't know when the exception actually occurs
(painting when the item is deleted or painting when i refresh the list
to get the current contents from the server) so maybe your theory is
still accurate.
private void list_deleteObj() {
int idx = dirList.getSelectedIndex();
String dn = LDAPMgr.ldapUtility.getDN(
model.getListModel().getElementAt(idx) );
int ans = JOptionPane.showConfirmDialog(this,
"Confirm delete for:\n" + dn + "\n",
"Delete Object",
JOptionPane.YES_NO_OPTION,
JOptionPane.PLAIN_MESSAGE);
if (ans == 1)
return;
String msg = null;
msg = LDAPMgr.ldapUtility.deleteEntry(
model.getListModel().getElementAt(idx));
/* if successful */
if (msg == null) {
model.getListModel().remove(idx);
/* reload the subtree and list to show deletion */
refresh();
}
}
As you can see the removal from the list occurs before refresh(). In
refresh() I call expand(). In expand() I spawn the thread to refresh the
list model. If the repaint from the model.getListModel().remove(idx);
doesn't occur until my thread is spawned then maybe that creates the
exception. In another posting a few minutes before this one I tell
Nigel that I put the call to the method above on the EDT and it didn't
help; after enough deletions the exception crops up again.