Could be I twisted my english too far and it broke. ;-)
Larry
On 1/18/07, Stefan Steiniger <[EMAIL PROTECTED]> wrote:
> This is one of those pieces of code that the more I look at it, the more
> I see I don't see. Know what I mean?
i dont understand that really
but i know that i do not unde
> This is one of those pieces of code that the more I look at it, the more
> I see I don't see. Know what I mean?
i dont understand that really
but i know that i do not understand.. thats why i am a GIS guy and not a
programmer :o)
good night, stefan
-
I know exactly what you mean! I'm sorry I ever selected this bug out of the
tracker. :]
I should have followed the method calls that result from the call to
LayerManager.fireCategoryChanged() farther down the chain than I did.
I would still like to understand how things are working. I will print
Sunburned,
Well, it calls fireLayerEvent with a new inline Runnable class method run
defined to do layerListener.categoryChanged. Then fireLayerEvent invokes
GUIUtil.invokeOnEventThread which does:
if (SwingUtilities.isEventDispatchThread()) {
r.run();
} else {
Larry,
You could be right. I didn't even think about the iteration occuring in the
GUI Thread. Does this mean that the Runnable argument passed to the
LayerManager.fireCategoryChanged() method is in fact the GUI Thread? It
looked like OpenJUMP/JUMP was creating a brand new thread using an inner
c
Sunburned,
I respectfully disagree with your analysis. I believe all of the
iteration over LayerListeners occurs within the GUI Thread. My guess is that
although addCategory took the bullet, it didn't fire the gun. Having said
that, and looking at the trace, and your fix, I don't see any harm
I have attached the Java file for the modified LayerManager class that fixes
Pedro's bug with the ConcurrentModificationException. All of the changes
were made to the LayerManager.fireCategoryChanged() method. I implemented
the solution recommended by David, which is to clone the layerListener
col
