Handling selection and deselection of objects in a user interface

Question

I'm writing a small audio application (in Silverlight, but that's not really relevant I suppose), and I'm a struggling with a problem I've faced before and never solved properly. This time I want to get it right.

In the application there is one Arrangement control, which contains several Track controls, and every Track can contain AudioObject controls (these are all custom user controls). The user needs to be able to select audio objects, and when these objects are selected they are rendered differently. I can make this happen by hooking into the MouseDown event of the AudioObject control and setting state accordingly. So far so good, but when an audio object is selected, all other audio objects need to be deselected (well, unless the user holds the shift key). Audio objects don't know about other audio objects though, so they have no way to tell the rest to deselect themselves.

Now if I would approach this problem like I did the last time I would pass a reference to the Arrangement control in the constructor of the AudioObject control and give the Arrangement control a DeselectAll() method or something like that, which would tell all Track controls to deselect all their AudioObject controls. This feels wrong, and if I apply this strategy to similar issues I'm afraid I will soon end up with every object having a reference to every other object, creating one big tightly coupled mess. It feels like opening the floodgates for poorly designed code.

Is there a better way to handle this?

Answer 1

One way to maintain some degree of loose coupling would be to implement the selection notification through an event. As you say, the AudioObject controls could accept an Arrangement control in their constructors (or better yet, an IArrangement interface, so you could have multiple implementations for slightly better decoupling), and the IArrangement interface could have a RaiseItemSelected() method, which in turn raised the ItemSelected event. All AudioObject controls would know to listen to that event, and would deselect themselves if they're not the object being selected.

Answer 2

Why not handle selection through the arrangement control? Hook up the mousedown event on each AudioObject (or just handle it entirely at the arrangement level by hittesting the click location) to the same handler in the arrangement. Then you can just set the selection visuals off for every AudioObject and then turn it on for the one sent into the handler. Doing it like this also makes it easier for you to maintain stuff like SelectedAudio property or a SelectionChanged event off of the arrangement control for use up the tree.

EDIT: I reread the question more closely to pick out what is going on with the arrangement vs track vs audioobject controls a little better. Seeing the 3 layers, I would definitely handle all selection from the arrangement (unless the track control must also perform selection related activities). I would handle the click event for the arrangement control, and when it comes in I would do a hit test on the click location and check to see if an AudioObject is in the stack. If one is, I would just manipulate a selection collection kept at the arrangement level to have the correct data (based on key modifier or whatever). I would have also set up an event handler on collectionchanged for that selection collection that loops through the AudioObjects in each track control, and sets their visuals depending on whether or not they are contained in the selection collection. Set up like this, I could then also just manually manipulate the selection in code (for whatever reasons I may need) by adding/removing from the selection collection.