Re: How to add elements to a JList without preventing refresh

Anonymous user wrote: 

i have a simple problem. Let's say that in some app, i have a loop wich
add a lot of elements to a JList. I CANNOT change the loop, but i can
change how each element is added.


Are you not going to tell us why?

What i would like is that i can scroll the JList with the mouse,
select/unselect, etc... WHILE the elements are added:

public class Refresh extends JFrame { 

There is no need to extend JFrame.

	private JPanel jContentPane = null;
[...]
		this.setContentPane(getJContentPane());


What's with the J's? They just make it more difficult to read.

	}

	private JPanel getJContentPane() {
		if (jContentPane == null) {


And what's with this lazy initialisation that is always done?

Perhaps if these methods were called by a base class constructor it would matter, but then you've just clobbered them with the initialisation assignments.

jContentPane = new JPanel();

If you are going to set a JPanel as the content pane, you should setOpaque(true) on it. It doesn't make any difference on most platforms, but on some it does. "Works for me" doesn't work.

			jButton = new JButton();
			jButton.setText("Add");
			jButton.addActionListener(new java.awt.event.ActionListener() {
				public void actionPerformed(java.awt.event.ActionEvent e) {

					// this CANNOT be changed
					for (int i = 0; i < 1000000; i++)
						add2(i);
				}
			});

Okay, so you are are creating and adding 1,000,000 entries to the list in one go from within the Event Dispatch Thread.

If these entries have a high creation cost then the obvious thing to do is either do it in batches, or create in another thread and transfer across. Better still create the entries lazily, which you seem quite keen on (IIRC, you need set a fixed with and height on the JList, or they will all be created to determine individual heights). But if you can't do that for some reason, I guess you can't. On a 1 GHz processor we have around 100 cycles per entry. That should be just about doable for a trivial object.

	private void add1(int i) {
		((DefaultListModel)getJList().getModel()).addElement(new Integer(i));
	}

Each time you add an entry, the model fires an event. That isn't going to be efficient. So perhaps create an entirely new model with a bulk add. That or remove the listeners for the duration.

Note, a very long list, without fixed cell width and height, validating layout will be extremely slow.

	 * The JList freezes too, and a java.lang.OutOfMemoryError is throwed;
	 */
	private void add2(int i) {
		SwingUtilities.invokeLater(new RunAdd(i));
	}


An anonymous inner class would have worked better here.

What you are doing here is queueing up a million events. That isn't going to be nice.

You could add the entries to a plain List. invokeLater on a task that adds a traunch of the outstanding entries. If not all entries are added in one go, then the task should invokeLater itself again. This is similar to the way SwingWorker operates.


There is a way to clear the event queue without returning from an event. The ActionListener above should invokeLater, because the event hasn't finished firing and there may be other listeners yet execute (for instance from the PL&F). The technique is a complete hack and I don't recommend it, but anyway:

Modal dialog boxes run a nested copy of the event loop without returning from the event that caused the dialog box to be shown. This can be hacked for our purposes. The Foxtrot library should help, if you must do this.

public static void main(String[] args) { 

You need the standard boilerplate here:

EventQueue.invokeLater(new Runnable() { public void run() {
new Refresh().setVisible(true);
}}); 
	}
}


Tom Hawtin
--
Unemployed English Java programmer
http://jroller.com/page/tackline/
.

Quantcast