That sounds to me like you want to use events -- the items which light up should listen to the items that trigger them. When the triggering item gets moused over, the listening item(s) can decide whether to react. This might just take your redundancy and put it somewhere else, but it keeps you from writing and checking a ton of different lists.


Yeah, that sounds good. I haven't used events and listeners much, so upfront it might take me longer than my first approach. But let me see if I have the theory right.

Each item in the lists is assigned a listener object as it is created, which would be a list of the possible events that will trigger it. Each item also has an event object that fires when rolled over.

Rolling over item A fires an event that all the other items hear, each other item checks its list of events that will trigger it, and if it finds the event that was fired, it does its thing.

Does that sound about right?

Close. Let's assume you're using mx.events.EventDispatcher. Your event broadcaster class starts like this:

import mx.events.EventDispatcher;

class myClass
{
   // function declarations to be mixed in by EventDispatcher
   public var addEventListener:Function;
   public var removeEventListener:Function;
   public var dispatchEvent:Function;
/* constructor */
   public function MyClass()
   {
      EventDispatcher.initialize(this);
   }
}

The EventDispatcher.initialize() call simply "fills in" the blank function declarations, and your object -- no matter what its type was before -- now acts as an EventDispatcher.

Now let's say you have greenSwitch and purpleSwitch, which are event dispatchers; and redLight, blueLight, and yellowLight, which don't need to be. Given basic color theory, you want red and blue to light up if you click the purple switch.

class Switch
{
   ...

   public function toggle():Void
   {
       var eventObject:Object = new Object;
       eventObject.type = "onSwitchChange";
       eventObject.target = this;   // sends a reference to itself!
       dispatchEvent(eventObject);
   }
}

class Light
{
   ...

   // note that this function has the same name as the event
   public function onSwitchChange(eventObject:Object):Void
   {
      // animate something, probably by altering a movieclip
   }
}

And finally, the code that makes use of these objects:

var purpleSwitch:Switch = new Switch();

var redLight:Light = new Light();
var blueLight:Light = new Light();

purpleSwitch.addEventListener(redLight);
purpleSwitch.addEventListener(blueLight);

purpleSwitch.toggle();

As you see here, purpleSwitch contains an array of all objects listening to it; then when you create and dispatch an event object, it simply calls the identically-named method on each listener object. It's nothing mystical -- just convenient.

And the nice thing about it, for your purposes, is that none of the switches or lights really even needs to know what color they are... the logic is contained in their sender/listener relationship.

If you need something more complex, just add properties to the eventObject, and have the listener object deal with that. Or just read from eventObject.target, which should be a reference to the broadcasting object. The classic example is to have a textField or something, which sends events when it's updated; a listener could get to the text with eventObject.target.text.

_______________________________________________
Flashcoders mailing list
[email protected]
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Reply via email to