There's a list of which classes are part of the Collections framework and why a programmer might choose each one here and clicking on the Overview link. That's a child page under the top-level Java 6 page.jfrazierjr wrote:Well, it looks like ObservableList is backed by an ArrayList, which maintains order. ZoneRenderer.getSelectedTokensList() appears to be the place where the sorting is performed from a quick glance. The questions remaining are a) is this the only place(probably) and b) why was the returned token list sorted in the first place??
Probably not. There are concurrency issues with updating the GUI on anything except the event handling thread. Because the Swing component library does not know about any of the application programmer's code it can't have concurrency checking built into it (no mutex locks, for example).I am by no means a java expert, but I believe a new macro function that creates a new thread will halt macro execution and allow for interaction with the UI, so I am playing around with that(using the toolbar button approach so you can "finish" that macro call and continue with the rest of the original macro. I hope to get that tested in the next few hours for a proof of concept.
That means that the only safe place to put GUI code is on the event thread.
When the user clicks a macro button, it's the Swing JButton that responds to the click and fires off the AP's code (AP = application programmer). So for most GUI-related things, the code the AP writes is already on the event thread. But say that you start another thread. What happens when it tries to access some Swing component via that other thread -- while the event thread is already executing the same code!? Without concurrency controls (i.e. locking of data structures) it's possible (likely?) that the internal data will get corrupted or out of sync resulting in failure of the GUI components.
There are two ways around this. The first is SwingUtilities.invokeLater() which queues up a Runnable object at the end of the event handling queue so that when the current AP code is done and it returns to the Swing JButton component (for example), that code will returns to its parent, and so on. When the code gets all the way to the top of the stack, it'll check the event queue before returning to the OS and see that there's another event. In which case that code will be executed.
This allows a Runnable to be executed in a deferred manner on the Swing thread and this approach should always be followed for running AP code in the simple case. A more sophisticated approach is possible but it's not for the beginner.
The other technique is SwingUtilities.invokeWait() which takes a Runnable and invokes it immediately, waiting for that code to finish before the calling routine completes. It is essentially the same as just calling a method directly -- except that it works properly even if the calling thread is not the event thread!
I typed in the above from memory and I may have missed some details, so don't take the above as gospel.
There are other ramifications of writing a multi-threaded Swing application and I would strongly suggest reading through the Swing Tutorials on Sun's web site, in particular the tutorial dealing with multi-threaded apps. Of course.