views:

75

answers:

2

I have a JFace editor that is mostly made up of a TreeViewer. This is hooked up to a ContentOutlinePage to bring the Outline view to life.

When either one receives a SelectionChangedEvent event they call the others setSelection() method ... and therein lies the problem. setSelection() generates another SelectionChangedEvent ... and thus the infinite loop is joined.

Is there a means of telling if the SelectionChangedEvent was created by actual user interaction rather than by another object calling setSelection()?

Is there a better means still of stopping this sort of deadly-embrace?

Clues welcomed.

+2  A: 

Generally, you would check a flag in the beginning of the routine to check to see if you are in the middle of the event handler. If the flag is set, then you exit without processing.

If the flag is not set, you set the flag, process, then set the flag back.

casperOne
A: 

Another pattern that works is to remove the event listener, make the selection, add the eventlistener back again. This ensures that there is a single place in the code where you have to worry about this - with a flag you would have to simultaneously maintain two places.

Also, the SelectionChangedChanged is possibly (not sure though) put on top of the event stack (ie executed asynchronously). In which case, you also minimise the period during which the viewer does not propagate notification.

Overall, I find it disappointing that the SelectionChangedEvent generated is the same, regardless of whether a mouse was clicked. I suppose it's not as easy to do that as one would hope. I once had to modify a text editor class behaviour so that it new about two kinds of insert events (user generated and network generated) in order to make that text editor class shared. I'd love to see more discussion of this.

Tirno