Broadcast global component change

Wow, it's been a long time ...

I'm creating a bunch of components that extend a base component.

I'd like for that base component to be able to tell all instances of the sub-classed components when a global change is coming. For instance, I want the user to be able to increase the type size used in all buttons, lists and text fields, just like a browser has a text increase/decrease command.

I have accomplished this, but I'd like to know if I've taken the best approach.

What I've done is set the base class to dispatch an event targeted to the stage, and my sub-classes components have a stage level addEventListener.

Code:

---

stage.dispatchEvent(new LCARSEvents(LCARSEvents.GLOBAL_CHANGE, false, false));

---

and

Code:

---

stage.addEventListener(LCARSEvents.GLOBAL_CHANGE,globalChange);

---

Of course, to make this work, I had to instantiate my base class and add it to the display list -- addChild(baseClassInstance) -- or else the base class has no idea what a stage is.

In the past, what I've done is keep an array of each object as it gets instantiated and whenever a global update is needed, I just for ... each through the array, calling the update function for each instance.

I'd appreciate any thoughts as to which is the more efficient path.

Thanks,

Jennifer

PS Although I claim to have accomplished this, there have been a few snags, mainly that I've been trying to update a static variable with the values contained in one of three static constants. But if I call the instance of the base class that I mentioned above, the instance knows not of the static variables/constants. If I call the base class itself, it's unaware of the existence of the stage.

I think I could get around this if I declared my constants and variables in the document class. Any ideas?

I don't think there's any way to dispatch an event without the dispatcher being in the display chain. So whether the class itself dispatches the event and had it bubble, or had the stage dispatches it, you're in the same boat of needing a reference to the stage.
What would happen if your component instances had an added to stage listener that set the stage reference as a static var, and then your dispatching class used that reference? Then at least you wouldn't have to add it in the document class. Hard to know w/o looking at the code, and I'm not really an expert on components.
Josh

Quote:

---

Originally Posted by joshstrike

I don't think there's any way to dispatch an event without the dispatcher being in the display chain. So whether the class itself dispatches the event and had it bubble, or had the stage dispatches it, you're in the same boat of needing a reference to the stage.
What would happen if your component instances had an added to stage listener that set the stage reference as a static var, and then your dispatching class used that reference? Then at least you wouldn't have to add it in the document class. Hard to know w/o looking at the code, and I'm not really an expert on components.
Josh

---

Thanks for the suggestion, Josh. I really appreciate the suggestion, but I went with the document class because I realized that other things besides the components would benefit from knowing whether the user requested a text size increase.

I was also reluctant to use the document class because I was worried about it getting too busy, but then I realized that I could create a base document class and just extend it for each fla (this is a multi-fla project).

I probably will also add the function that sends out the text increase/decrease event to the document class. The document class understands the existence of the stage without having to instantiate it.

Jennifer

Actually, I used Josh's advice and also went with a document class. I created a static method in the document class that broadcasts the text increase/decrease event but the static method is unaware of the stage. So in the document class' constructor, I set a private static var equal to stage, which I can then use as the target for the event.

So, thanks again, Josh.

Jennifer

I'm pretty sure that an object does not in fact have to be in the displaychain in order to dispatch events. The livedocs for EventDispatcher shows that it extends Object, not DisplayObject.

In fact, I have created various EventManager classes just for the purpose of registering 'global' events for various types of listeners. These were singletons, and didn't do much except handle event logic.

You could try using a shared object.

Quote:

---

Originally Posted by 5TonsOfFlax

I'm pretty sure that an object does not in fact have to be in the displaychain in order to dispatch events. The livedocs for EventDispatcher shows that it extends Object, not DisplayObject.

In fact, I have created various EventManager classes just for the purpose of registering 'global' events for various types of listeners. These were singletons, and didn't do much except handle event logic.

---

Thanks for the reply, Mr. Flax.

I just dispatched the event to the stage and had my instances watch the stage. This may be really sloppy and goes back to my original question of whether my method of updating the instances is the best way to go. I should really do a test of whether iterating an array or sending out an event is faster or has less overhead.

Jennifer

Quote:

---

Originally Posted by cancerinform

You could try using a shared object.

---

That's an excellent suggestion. I'm actually redoing a website that's at http://www.personal-log.com/ and most of my prefs were stored in SharedObjects. I will definitely be storing my user's prefs there again, but I will still probably use the document class to parse the SOs anyway.

Jennifer

Manually managed arrays may be faster (maybe not), but for me the event model makes more intuitive sense. Sequentially executing a method on each element of an array would be single-threaded, whereas event-driven code could take advantage of idle time via parallel threads. Of course, there's probably not much idle time anyway since loaders are inherently multi-threaded.

Incidentally, I notice the "LCARS" in your class names. Are you implementing a Star Trek UI?

Quote:

---

Originally Posted by 5TonsOfFlax

Manually managed arrays may be faster (maybe not), but for me the event model makes more intuitive sense. Sequentially executing a method on each element of an array would be single-threaded, whereas event-driven code could take advantage of idle time via parallel threads. Of course, there's probably not much idle time anyway since loaders are inherently multi-threaded.

Incidentally, I notice the "LCARS" in your class names. Are you implementing a Star Trek UI?

---

I agree, an event based notification just seems more elegant and like you say, it lets each instance get around to noticing there's an update on their own good time.

And yes, I'm reworking my site, http://www.personal-log.com/ to be AS 3.0 based. I only recently could rub together the shekels to afford CS3. The site was done in Flash 6 and there are times when I really needed both bitmap caching and most especially embedded images in html text.

I'm also trying to create a real LCARS interface for phpBB.

Jennifer, geek