flash actionscript: TruLine,

[quoted text, click to view]

ActionScript is based on the ECMA standard. This is really no different
from JavaScript. Wherever you scope your variables, there they are. If you
don't like to specify long paths, you could create a variable to act as a
kind of shortcut, or write a function that routes your traffic for you.

[quoted text, click to view]

This is how classes work in every language I can think of that uses
classes. If you make your class static (the native Math class is static,
for example), you don't have to (can't) make instances of it.

[quoted text, click to view]

Honestly, bro, that's just not object oriented thinking. To each his
own, of course, but I think you're coming at this the wrong way. If you
really want to lay down a variable that is global to everything and affects
all your movie clips, then use the _global object.

_global.myVariable = "myValue";

.... and have your movie clips reference _global.myVariable;


David
stiller (at) quip (dot) net
"Luck is the residue of good design."

TruLine,

[quoted text, click to view]

It really does take a bit of zen to "get" object oriented concepts, but,
speaking for myself, OOP is my favorite way to go. Just like a really good
movie, you'll continue to spot things in OOP that you didn't see before. In
order to alert a dozen movie clips that a certain thing has occurred, you
might, for example, use the EventDispatcher class. Essentially, you create
a flass of your own, say Enemy, that can be instantiated into dozens of
little enemy dudes. The Enemy class responds to certain events -- just like
movie clips do: they respond to onRollOver, onEnterFrame, etc., etc. -- and
since you're writing the class, you can determine what these events are. If
you want, you can write an onKicked event that represents the "event" of an
Enemy instanced being kicked. Or, say, an onBombed event, in which case all
your enemies fall down dead, because the bomb is powerful enough to hit them
all. Rather than have a _global.bomb = true; variable (just, for example),
you might have some movie clip that represents a bomb, and when it hits the
floor, it raises an onBombed event (or onExplode, or whatever you call it).
Your Enemy instances are all subscribed to this event, so when the event
happens, it happens! And they all fall over.

It sounds like magic, probably, to hear me describe it that way, but
you'll get it if you dig through the EventDispatcher class and study up on
OOP. Don't be afraid to write your own classes. But if your game is truly
that far along, you'll probably have to re-write it completely or just plug
again and consider an OOP approach next time.

[quoted text, click to view]

All a static class is is a class that cannot be instantiated. I'll use
Math class again, to explain. If you wanted to know the value of pi, you
could store an arbitrarily long constant in a global variable ...

_global.pi = 3.14159;

.... and of course, it would always be available via _global.pi from that
point forward. OR, you can just summon up Math.PI, which more or less
amounts to the same thing. It's just as easy to use one or the other.

With the Math class, though, this datum is at least organized. (Pi is a
math term and belongs to the Math class.) Math can perform all sorts of
functions, too, such as rounding, multiplying by powers, sine and cosine,
etc. You could store all those functions in the _global class, too, but
they're available simply via Math.round(4.5).

You can't create an instance of the Math class. You can't do var m =
new Math(). It would make no sense to do so. But if Math had properties
there were publicly accessible (and writable), you could certainly change
them. You could change them as easily as you could a publicly accessible
(and writable) property of a MovieClip instance, such as myClip._x = 5.

Static classes are valuable for "global" data and functionality that is
organized into a meaninful package. In your game, you might have a static
Score class that keeps track of a score dependant on any number of factors.
Maybe a number of Enemy instances subtract points from Score.count over
time, say. You could keep that count variable, or something called score,
in the _global object -- it really makes no difference -- but I think it's
good to get into the *habit* of organization, at least, until it truly hits
you how you can make use of these various kinds of classes.

Much more important (and more powerful) in your case at the moment,
though, will be the EventDispatcher class.

[quoted text, click to view]

Yes, it is the same. The only thing is, you can't use instances of a
static class.


David
stiller (at) quip (dot) net
"Luck is the residue of good design."

TruLine,

[quoted text, click to view]

Bring it on. This is what the forums are for.

[quoted text, click to view]

What's stopping you? :) Built in, schmilt in. If you write a static
class, it will be just as useful, powerful, and available as any built-in
classes. A class is just code. Class defines a datatype. If you want a
string, you'll need to instantiate the String class. You want a movie clip?
Instantiate the MovieClip class. The class is what defines each of those
those as what they are. Static classes are the same, except they don't
instantiate (or you might have a class that has both static members and
not). Do what you want!

[quoted text, click to view]

I guess you do, if the class is not static.

[quoted text, click to view]

That fact that you have instantiated your class ...

var clTest:AO = new AO();

.... tells me this isn't a static class. Static classes are *not*
instantiated. They cannot have instances made of them (see how "instance"
and "instantiate" come from the same root word?). You cannot make an object
clTest from the AO class if you want AO to be static. When it is static,
you can access it from anywhere, just like _global.


David
stiller (at) quip (dot) net

Is there any way in 8 to declare a variable on the main time line, and
manipulate them in nested MCs without haveing to put the entire path on them?
I tried many ways, and the only way so far, is like so...

_level0.variable = newValue.

I tried making custom classes and you still have to declare an object of said
class before you can manipulate the class variable...

How are some of you guys doing this? Is there any way for one to say...

var widget = someValue ...and then change this value anywhere in your
application with a simple...

widget = newValue?

This minor dilema is keeping me from launching, and I would like to get this
down so I can fly!!

Tim

TruLine,

[quoted text, click to view]

That's a perfectly logical thought. Let me back up a bit, to make sure
I'm not misleading you. I've been speaking of "static classes" versus
"non-static classes." Actually, it's not a *class* that is or isn't static,
but its members (its properties and/or methods). It was speaking less
clearly than I should have.

So ... just create your class as you already have, but for whatever
properties you want to be static, use the static statement; for whatever
methods you want to be static, use the static statement. (If all properties
and all methods are static, I suppose it makes sense to call the class
itself static, which is what I meant earlier.)

class AO {
// Properties
private static var _something:String;
public static var somethingElse:Number;
private var _foo:Boolean;
public var bar:Array;
// Constructor
function AO() {
}
// Methods
private static function doThis() {}
private function doThat() {}
public static function doTheOther() {}
public function doTheOtherOther() {}
}

[quoted text, click to view]

That's how you access static members of the Math class, right? That's
how it's done. It is that easy. But ... BUT! ... don't get too wrapped
around static class members and the _global object. Remember, the solution
you *should* be after is the EventDispatcher class.


David
stiller (at) quip (dot) net
"Luck is the residue of good design."

I appreciate your response.

I am guilty of wanting the easy way I admit, I am also guilty of wanting to do
a marathon before I give up smoking and practice running down the block without
haveing to stop and catch my breath!! But that's the best way I learn.

I am making a pretty heavy gaming program, and I need to change the direction
of things in the game at many turns and on many movieclip instances.

Please, elaborate a bit on static classes... I am reading a book and it said
it'self instead of using global variables, use static classes. but the book did
not go into it very far, and I thought I seen that static classes cannot be
manipulated or did I read it wrong?

I created my first class last night and worked it a bit in my application.
Can I use a user defined static class and manipulate it with the getter and
setter methods as I do with a normal class?

If you can spoon feed me on this on area, I would be grateful...

Tim

One more and I'll leave you alone...

... and of course, it would always be available via _global.pi from that
point forward. OR, you can just summon up Math.PI, which more or less
amounts to the same thing. It's just as easy to use one or the other.


This is a built in class. I want to do the same thng with my classes...as in
"class Tim", changing the background of the movie which is a movieclip...once I
know this, the fog will dicipate.

Tim.view(newview_mc)

You can use the Math class like this anywhere in the application. Thus far, I
have had to create an object for the class in every movieclip instance... AO is
my first attempt at creating classes in action script. "AO" would be short for
"Area of Operations". Theater is a variable that hold a movieclip. "canvas_mc"
is a back ground.

var clTest:AO = new AO();
trace(clTest.theater);
clTest.theater = canvas_mc;
trace(clTest)
trace(clTest.theater);

I have found, that I need to declare an instance of the class like above,
everytime I go to use it other movieclips... Why can't I just say
"clTest.theater = canvas_mc;" anywhere in my ap like you can with Math()?

Okay!! so how do I make my existing AO a static class??

Simply by this?...

Static class AO {
//code
}

And now I can invoke methods allover by AO.whatever()??

It can't be that cut-n-dry....

did an F1 in flash 8 and came up with nuthin on EventDispatcher..?????

Just to learn it any way, explain this one if you can...

Here is F1 help in flash 8...

class Users {
private static var numInstances:Number = 0;
function Users() {
numInstances++;
}
static function get instances():Number {
return numInstances;
}
}


Create a FLA or AS document in the same directory, and enter the following
ActionScript in Frame 1 of the Timeline:

trace(Users.instances);



Here is mine...

class AO {

private static var theater:MovieClip = null;
//private static var _weapon:MovieClip = null;
//private var _fire:Sound = null;
//private var _action:Boolean = false;

function AO() {
theater = canvas_mc;
}

static function get area():MovieClip {
return theater;
}

On my frame 1...

trace(AO.area);

And here is my error message...

**Error** Scene=Scene 1, layer=actions, frame=1:Line 11: There is no property
with the name 'area'.
trace(AO.area)

drivin me crazy!!

I want to learn this. My abilites thus far over all tell me to conquer this
area of Action Script and my limits are endless...

delay my last...was working on the class, and did not hit save...It was
accessing a previous version of my .as file. I took for granted that the
editing window in flash 8 for class files were live when test movie is hit...I
learned something else!!

If I die of stress, you guys at Macromedia are to blame!!!

Sorry, this has nothing to do with the original topic, but I was reading your
discussion and I can't help but notice this code:

class AO {
// Properties
private static var _something:String;
public static var somethingElse:Number;
private var _foo:Boolean;
public var bar:Array;
// Constructor
function AO() {
}
// Methods
private static function doThis() {}
private function doThat() {}
public static function doTheOther() {}
public function doTheOtherOther() {}
}

Here's the question. Can a static member be declared private or public? It
doesn't make sense to me. It seems that they all have to be public or else you
wouldn't be able to use them in your script, unless it's because you don't have
to instantiate them.

Yes, a static member can declared private or public.

A public example:
class Circle {

public function Circle(){
}

public static function testCircle():Void{
trace("called");
}
}

Access:
Circle.testCircle();
You have access because of the public attribute

A private example:
class Circle {

public function Circle(){
}

private static function testCircle():String{
var test:String="called";
return test;
}

public static function traceCircle():Void{
trace(testCircle());
}
}

Access:
Circle.traceCircle();

Whether it makes sense? Well, maybe David has a practical example. I can't
think of one right away. In general, you might want to use (some of) your class
methods only internally. Depends on architecture I guess.

codescodescodes,

[quoted text, click to view]

You would make a static member private or public for the same reasons
you normally would. Example: if I'm developing a game, I might write a
class called Enemy. This class is entirely non-static: I would, of course,
be using the class to generate a new enemy any time I needed one. There
might be a dozen enemies in the game at any given time. Any given enemy
would feature public members, such as x,y (location), health ... anything
that would have to be accessible to other classes. For example, if the hero
strikes an enemy, it may make sense to have Enemy.health be public, so that
the hero's object can affect this given enemy's object directly (by
decreasing the enemy's health). But an enemy's health might be more
complicated than that: there may very well be methods of the Enemy class
that calculate environment properties (how hot is it, is the terrain
especially rocky?) which might also affect its health. Any properties used
to calculate averages and make other statistical analyses that affect health
are, quite frankly, not the business of any class except Enemy. It makes no
sense to make those public, so those would be private. (Good object
oriented design tends toward revealing as little as possible to the outside
world, since robust classes should be able to handle themselves.) The above
mentioned public or private members would be non-static, because we want
dozens of Enemy instances running around, maintaining their own statistics.

Now, to keep track of higher level business, such as *how many* enemies
there are at any time, I might also have an EnemyManager class. This class
would likely be static -- that is, most or all of its members would be
static -- because I would only need one EnemyManager: only one entity that
creates enemies, keeps track of how many there are, destroys them (to free
up memory), etc.

It might be useful, for example, to know at any given time how many
enemies there are on the field. That's a perfect candidate for a public
static property. Makes sense, right? There can't be more than one number
that represents the number of enemies, and this number should be available
to a class like Hero. But maybe there's an element of illness in the game,
or something like morale. If enough of the enemies die, their overall
morale may decline. The value of enemy morale could probably be a public
static property, but any properties (and methods) used to calculate this
value are no one's business but EnemyManager's, and might end up being
private static members.


David
stiller (at) quip (dot) net
"Luck is the residue of good design."

I get what you are saying, but that arises another question. Why even use
static members at all in those situations since you won't need to even
reference the class name if you're using them in the class itself.
OOOOOOHHHHHH! Unless if you extend the class, then maybe you might want to do
that. I guess. What's your take. When would be a good situation to have to
declare a static member as private?

It's under the Components "book," in the Help docs (but don't let that
confuse you: you don't need to use Components to use the EventDispatcher
class).

If you just Google "EventDispatcher class," you'll find a tutorial at
Macromedia.com.


David
stiller (at) quip (dot) net
"Luck is the residue of good design."



[quoted text, click to view]

Wow....

It will take me some time to go over the event handlers, but I imagine it will
be time well spent. You're right on the money...if I am able to get
comfortable with what i see so far of this handler, life will be good. I need
to learn how to work with it.

Let me aks... could you give me another freebie??...

If I had a movieclip as a back ground picture, and I wanted to dock my aiming
device when I moved off of the said movieclip(I have a tool bar per se to
change optics, change battle zones, change trigger options(single shot, three
shot burst, or full auto) ) , could you give me a thumbnail sketch on how to
create an event object that listens to the movement on the background MC and
when it moves off, the event is triggered and my mouse is normal to pick side
line options...

I know mouse proceedure(mouse.show) etc, I just need to now how to start the
communiction with this handler...the examples givin are for buttons. Which, is
just like any other programming book I ever picked up.
They give examples using foo and bar(no offense!) as connection and function
methods/eventhandlers. They rarely give real world examples which would change
the learning rate for me anyway, if they did.

Tim

Let's use a class to load the background and implement a method to move the
background:

import mx.transitions.*
import mx.events.EventDispatcher

class Background{

var container_mc:MovieClip;

private function dispatchEvent(){};
public function addEventListener(){};
public function removeEventListener(){};

public function Background(){
mx.events.EventDispatcher.initialize(this);
}

public function loadBackground(target_mc:MovieClip,url:String){
container_mc=target_mc.createEmptyMovieClip("background_mc",
target_mc.getNextHighestDepth());
container_mc.loadMovie(url);
}

function moveLeft(amount:Number,delay:Number):Void{
var thisObj:Background=this;
var eventObject:Object = {target:this,type:'exit'};
var xTween:Object=new Tween(container_mc, "_x",
mx.transitions.easing.Regular.easeOut,container_mc._x,amount,delay,true);
xTween.onMotionFinished=function():Void{
thisObj.dispatchEvent(eventObject);
}
}
}

Usage in the fla:

// initialize our Background object
var myBackground:Background = new Background();

// set up a listener
var myListnerObj:Object = new Object;

// function to handle the exit event
myListnerObj.exit = function(evtObj) {
trace("Background shifted");
}

// subscribe myListnerObj to myBackground
myBackground.addEventListener("exit",myListnerObj);
// load the background
myBackground.loadBackground(this,"http://www.yoursite.com/images/01.jpg");
// move the background and trigger the event:
myBackground.moveLeft(-100,1.5);

Now, this doesn't account for the time it takes to load the background but you
can add that. I'm only moving the background by 100 pixels but you can also let
the event be triggered when the background goes off the stage by adjusting the
amount to move in the call to myBackground.moveLeft

Hope this helps.

class file:

import mx.transitions.*
import mx.events.EventDispatcher

class Background{

var container_mc:MovieClip;

private function dispatchEvent(){};
public function addEventListener(){};
public function removeEventListener(){};

public function Background(){
mx.events.EventDispatcher.initialize(this);
}

public function loadBackground(target_mc:MovieClip,url:String){
container_mc=target_mc.createEmptyMovieClip("background_mc",
target_mc.getNextHighestDepth());
container_mc.loadMovie(url);
}

function moveLeft(amount:Number,delay:Number):Void{
var thisObj:Background=this;
var eventObject:Object = {target:this,type:'exit'};
var xTween:Object=new Tween(container_mc, "_x",
mx.transitions.easing.Regular.easeOut,container_mc._x,amount,delay,true);
xTween.onMotionFinished=function():Void{
thisObj.dispatchEvent(eventObject);
}
}
}

In the fla:

// initialize our Background object
var myBackground:Background = new Background();

// set up a listener
var myListnerObj:Object = new Object;

// function to handle the exit event
myListnerObj.exit = function(evtObj) {
trace("Background shifted");
}

// subscribe myListnerObj to myBackground
myBackground.addEventListener("exit",myListnerObj);
// load the background
myBackground.loadBackground(this,"http://www.yoursite.com/images/01.jpg");
// move the background and trigger the event:
myBackground.moveLeft(-100,1.5);

I guess private static classes now makes sense. I haven't really had a chance
to apply some of these concepts in real world applications yet, but when I do,
I'll have more options to consider. Thanks everyone.

TruLine,

[quoted text, click to view]

You can dispatch any event you like at any time in, well, practically
any way you please. If you're doing so in a class, you must define three
properties in your class ...

public var addEventListener:Function;
public var dispatchEvent:Function;
private var removeEventListener:Function;

.... you must initialize the EventDispatcher class in your constructor ...

mx.events.EventDispatcher.initialize(this);

.... then, whenever you want to dispatch an event, you use the
dispatchEvent() method.

dispatchEvent ({type: "onWhatever", target: this});

The object in the parentheses must have a type, which defines what event
you're creating, and I find it good to have a target, which refers back to
the class instance that raised this event. Outside of that, you add
whatever you want. If you want the onWhatever event to pass a string that
says what side of the aiming device the mouse is on, when it rolls away, you
might type this ...

dispatchEvent ({type: "onWhatever", target: this, side:"left"});

In your case, you might have the aiming device dispatch an event on
event onRollOut of the movie clip that defines your aiming device.

Check out Ken Toley's tutorial here ...

http://www.macromedia.com/devnet/flash/articles/creating_events.html

.... it's where I learned how to raise events and listen for them.

[quoted text, click to view]

Buttons are certainly real world scenarios. But if you would rather
raise an event based on something else, it's up to you. What part don't you
get?


David
stiller (at) quip (dot) net
"Luck is the residue of good design."

TruLine,

[quoted text, click to view]

Well, bro, break it down. If something is too big to swallow, break it
into small pieces.

[quoted text, click to view]

If we do it here, then everyone benefits. Which is the whole point of a
public forum, right? :)

[quoted text, click to view]

Then you haven't swallowed the too-big piece yet.

I posted earlier what the basics are. Have you added three properties
to your class and defined them as :Function? Have you initialized your
class as an event dispatcher?

[quoted text, click to view]

That's probably the best way to go. Roll up your sleeves and dig in.
Bring something to the table and I (or someone) will help you out. :)


David
stiller (at) quip (dot) net
"Luck is the residue of good design."

[quoted text, click to view]

ummmm...you don't wanna ask that!...lol...

You want to continue doing this here? The alternatives are email or my forum.

I have in front of me about fifteen different codes explaining
EventDispatcher. I see and understand what everyone thing does in all the
examples. But I cannot start one on my own...

You want to continue this here or you want to go to email or my forum...there
is nothing going on there at present. just put it up and there is not a
reference to it anywhere.

Gotta go do the Holloween thing with the kids...Check back at ya later...

Tim

Ps...upon continuing, I want to post a snippet and go over it line by
line...If you want to afford the time...

I'm highlighted and the following code is credited to gskinner's blog file--
http://www.gskinner.com/blog/archives/2003/09/using_eventdisp.html
Also, I have another code posted here that I will question as comparisons or
compatibility...
http://trulineint.com/forum.asp?file=33

// in MessageBroadcaster.as
class MessageBroadcaster {
// we have to declare the dispatchEvent,
// addEventListener and removeEventListener
// methods that EventDispatcher sets up:
function dispatchEvent() {};
function addEventListener() {};
function removeEventListener() {};

From my understanding, the above instantiates an intance of the functions
listed. we'll call these the blue collar functions okay?

function MessageBroadcaster() {
// set instances up as dispatchers:
mx.events.EventDispatcher.initialize(this);
}

As stated in the comment, this function sets the blue collar functions as
active(listening)

function sendMessage(p_msgtxt:String):Void {
// set up the event object:
var eventObj:Object={target:this,type:"message"}

Q1--Please define this fully. Is this "Target" an Object? if so, is it
talking about p_msgtxt or is it talking about eventObj?
can type be listed in a sequence...meaning can we say ...
type.color
type.size
type.movieClip...etc...
or, does this only apply to eventObj...
eventObj._name
eventObj.whatever...
or, is type merely going to trace as a String--p_msgtxt? or, is target
referencing the function? If so, can you send this function a signal that a
movieClip has been moused over or clicked? If so, can you record and set a
variable, or, will p_whatever hold the value sent globally? hole lotta places
to continue to here man...explain this one like you had to program the
computer!!

eventObj.msgtxt = p_msgtxt;

Assigning the eventObj the value of p_msgtxt...why? What good is assigning
this Hello World? If you're talking about an SQL query, can this eventObj
hold...
eventObj.authors
eventObj.titles
eventObj.prices etc...
I may be far off here and I apologize if I am. I came from database
connectivity and that has been my depth in OOP...as in...
set rs1 = server.createobject("adodb.recordset") "rs1." does a hellavu lot!!

// dispatch the event
dispatchEvent(eventObj);

sends the value stored in eventObj to the blue collar functions....ya know
what, I'm lost already...I'll see you below...
}
}

// in the FLA:
// instantiate a MessageBroadcaster:
myMB = new MessageBroadcaster();

myMB is a new instance of MessageBroadcaster class

// define an object to listen to myMB:

myObj = {};

Okay Here...

myObj.message = function(p_eventObj) {
trace("myObj received a message: "+p_eventObj.msgtxt);
}
// subscribe myObj to myMB:
myMB.addEventListener("message",myObj);

// trigger the event:
myMB.sendMessage("I love everyone!");

Why don't you pick this apart, and I'll question when your done!! I cannot
see any growth with outside of what is coded here. I can't see how to
manipulate this code to do anything I want to do. This code is small. rip it
apart and break it down, then I'll question you...here it is again without
interuption...

// in MessageBroadcaster.as
class MessageBroadcaster {
// we have to declare the dispatchEvent,
// addEventListener and removeEventListener
// methods that EventDispatcher sets up:
function dispatchEvent() {};
function addEventListener() {};
function removeEventListener() {};

function MessageBroadcaster() {
// set instances up as dispatchers:
mx.events.EventDispatcher.initialize(this);
}
function sendMessage(p_msgtxt:String):Void {
// set up the event object:
var eventObj:Object={target:this,type:"message"}
eventObj.msgtxt = p_msgtxt;
// dispatch the event
dispatchEvent(eventObj);
}
}

// in the FLA:
// instantiate a MessageBroadcaster:
myMB = new MessageBroadcaster();

// define an object to listen to myMB:
myObj = {};
myObj.message = function(p_eventObj) {
trace("myObj received a message: "+p_eventObj.msgtxt);
}
// subscribe myObj to myMB:
myMB.addEventListener("message",myObj);

// trigger the event:
myMB.sendMessage("I love everyone!");

You're welcome. Are you closer to understanding how this variety of
options may benefit you?


David
stiller (at) quip (dot) net
"Luck is the residue of good design."



[quoted text, click to view]

TruLine,

It sounds like you're very excited about EventDispatcher, which is a
good thing. I'm happy to help you with it, too, but keep in mind, I'm just
a dude, like yourself. I don't work for Macromedia; I'm a unpaid volunteer
who taught himself ActionScript over the years and believes in "giving
back." (Frankly, I'm lucky as heck my boss encourages me to contribute to
the forums, because it keeps me on my toes!) I only mention it because
because this particular thread is starting to get long. Before too long, I
may have to drop out.

Okay, let's see what we've got.

[quoted text, click to view]

Sure. These are functions provided by the EventDispatcher class, which
works as a "mix-in" class. Grant Skinner took one approach above, and
Kenneth Toley took another. The above three lines are identical in purpose
to the three lines Toley uses:

public var addEventListener:Function;
public var dispatchEvent:Function;
private var removeEventListener:Function;

Same thing. Either way you choose to do it, these three must be present
in the class.

[quoted text, click to view]

I'm not sure I would word it that way. Not saying you're wrong, but to
my understanding, the initiaize() method of the EventDispatcher class
initializes *this* class as an event broadcaster. In Skinner's example,
MessageBroadcaster is the class that becomes initialized as an event
broadcaster. But yes, in a sense, this initialization "fills out" the blue
collar functions with their instructions. The blue collar functions don't
"listen," per se. The listening happens outside this class altogether, by
whatever class instances are intended to "hear" the events broadcast by an
instance of this class.

By the way, Skinner's example (and perhaps Toley's) may give the
impression that an event broadcasting class can only be an event
broadcasting class. Not so. Any class at all can broadcast events, as long
as it initializes correctly to make use of the EventDispatcher class.

[quoted text, click to view]

While nicely written, this sendMessage() method is perhaps more
complicated than an illustration needs. Remember, this class is something
Skinner came up with. He wanted a MessageBroadcaster class with his own
vision of a sendMessage() method. He's using EventDispatcher in a more
generic sense. Arguably, this is an illustration of how to "wrap" or
"extend" the EventDispatcher class as much as it is an illustration of how
to use the EventDispatcher class.

In the above example, target refers to "this" -- which in this context
refers to *an instance of* of the MessageBroadcaster class. If you were
using EventDispatcher in your own class, the word "this" would refer to an
instance of your class, of course.

You don't *have* to use target, but it's a nice thing to provide.
Remember, you're broadcasting an event from an instance of this class to as
many instances of any other class that are subscribed to this one. By
providing a target in your message, those other classes can know who they
heard it from. Not necessary, but it can be helpful. The word "target" is
completely arbitrary.

[quoted text, click to view]

p_msgtxt is passed in to the sendMessage() method. As you can see,
p_msgtxt is a string. eventObj is a new object, created right here in the
sendMessage() method. In Skinner's example, he's choosing to create an
object first, then pass that object to the dispatchEvent() method of the
EventDispatcher class. In my suggestions earlier, I described how to do
that without creating an object first.

Skinner is using the p_msgtxt parameter, passed into sendMessage(), to
populate a msgtxt property in this eventObj object in the next line or so,
then he invokes dispatchEvent().

All you *must* do is provide a type property. In the simplest terms
possible: once you A) define your three "blue collar" functions and B)
initialize this class as an event broadcaster, you're done. You now have
the ability to raise an event any time you want. To do so, you simply use
the dispatchEvent() method with a type property.

e.g.
dispatchEvent({type:"onTruLine"});

That's it. When you raise the event is up to you. You might do so
based on an existing event of, say, a movie clip instance referenced inside
your class. You might do so inside a method of your class. Up to you.

Not the curly brackets {} inside the above method. Those mean, "this is
an object," and any properties inside the object are defined in name/value
pairs in the syntax property: value. In Skinner's example, he creates an
object first ...

var whateverObj = new Object();
whateverObj.type = "onSkinner";
whateverObj.target = this;
dispatchEvent(whateverObj);

.... which amounts to putting whatever properties you want into the
dispatchEvent() method's parameter directly.

[quoted text, click to view]

You can put whatever properties you want into the object that becomes
your dispatched event. Events are always objects. There isn't really any
sequence involved. Any outside classes that listen for events will simply
be alerted of the event, then access whatever property/ies of that event
they need.

[quoted text, click to view]

type defines what sort of event this is. Don't get confused by
Skinner's particular use of EventDispatcher. When you use, say, the
MovieClipLoader class -- look it up, quick -- you'll see that it raises a
number of events. It features onData, onLoadComplete, onLoadInit, etc.
These are the *type* of each particular event. This is the bare absolute
minimum you need to provide.

In your class, when you dispatch an event, you might dispatch an
onComplete event, an onHitWithASliceOfPizza event, or whatever you want.
You could have an Environment class that represents the passage of time. It
might occasionally dispatch an onFullMoon event, and all your Werewolf

[quoted text, click to view]

Too late. ;)

[quoted text, click to view]

You haven't mentioned a class yet.

[quoted text, click to view]

For any of these, I wouldn't use EventDispatcher. MovieClip instances
already have a mechanism for detecting events. There is no need for a
class, here. Or if there is, you haven't shown the need for it. I would
simply do the following:

mc_1.onRollOver = function() {
mc_2._visible = false;
}

mc_2.onRollOver = function() {
mc_1._visible = false;
}

mc_1.onPress = function() {
this.play();
}


David
stiller (at) quip (dot) net
"Luck is the residue of good design."

TruLine,

[quoted text, click to view]

The conversation has has veered all over the place, including insight
into private/public class members, static members, and EventDispatcher. :)

[quoted text, click to view]

Since you're asking, let me recap this whole thread right here. I think
this covers all our meandering.

Here's your original question:

[quoted text, click to view]

(That's just a guess, by the way, on how many arrows should be in front
of the quote.)

So, you seem to have some information, currently stored in a variable on
the main timeline. It sounds as if you want a plethora of movie clips to
"know" when this variable changes, without your having to tediously path out
to each of these movie clips and update their correlating variables.

To restate, I'll quote you again:

<quote>
var widget = someValue
...and then change this value anywhere in your application with a
simple...
widget = newValue?
</quote>

There are perhaps a dozen ways of handling your goal. Rather than
pathing from the main timeline to your movie clips, you might for example
path once from a class to the main timeline. If each of your movie clips
makes use of the one class, you only have to write the tedious path once.

Then again, you might store this variable as a property of the _global
object, which makes it easy to check from any movie clip. This would
exactly be as simple as ...

_global.widget = newValue;

Then again, you might decide that you have more than just this one
datum: that you might, in fact, have a dozen data to "be known by" dozens
of movie clips. Sure, you could create a dozen new properties in the
_global object. That would work just fine. Or you might want to actually
categorize this data (6 properties pertain to weather [in the realm of your
game] and 6 properties pertain to, oh, weapons).

So you might write two static classes to store this information, perhaps
Weather and Weapons. Then, instead of simply ...

_global.windSpeed;
_global.windDirection;
_global.numberOfWeaponsInUse;

.... your movie clip instances might seek ...

Weather.windSpeed;
Weather.windDirection;
Weapons.numberInUse;

Same thing -- still easily accessible in a global sense -- but
organized.

So this may be exactly what you need. I believe you're writing a game,
right? This is only reason I'm using game metaphors.

Now, to repeat my werewolf metaphor, let's say you have a bunch of movie
clips in your game that look like werewolves. These have walkcycles (so
they look like they're walking) and other typical characteristics that make
up an enemy in your game. You might, then, have an Enemy base class for all
enemies (all enemies walk), and you might have a Werewolf class that extends
Enemy (werewolfs are everything a generic "enemy" is, but they also change
skins and howl at the moon).

Here's where EventDispatcher comes in ... perhaps (only you will know
for sure, based on the needs of your game). If your Weather class keeps
track of a moon object, and occasionally the moon becomes full, you'll want
all your werewolves to A) transform from humans into wolves and B) howl.

This scenario pertains to your original question, because you have
something going on "in the main timeline" or "globally" -- because there is
only one moon in this game -- and you want dozens of movie clips (which are
consumers of your Werewolf class, and are therefore Werewolf instances) to
react in some way. Yes, my scenario is more detailed than simply
"declare[ing] a variable on the main time line, and manipulate[ing] them in
nested MCs without haveing to put the entire path," but I believe the
concept is the same.

You might, then, use the EventDispatcher class as a mix-in to your
Weather class. However it is that your moon object operates, there will be
some algorithm for determining when the moon is full. When this event
occurs (based on a timer, who knows?), you can raise an onFullMoon event
from your Weather class. Your Werewolf class may either A) have a listener
in it to "hear" this event from Weather or B) you might assign a listener to
each Werewolf instance as you create it, in the same way you assign a
listener to the MovieClipLoader class, the ComboBox class, or what have you.
In this scenario, any Werewolf instance that has been assigned to "listen"
for the onFullMoon event can respond to it.

e.g.
var weatherListener:Object = new Object();
weatherListener.onFullMoon = function() {
this.transformToWolf();
this.howl();
}
werewolfInstance.addEventListener("onFullMoon", weatherListener);

In the above, "this" refers to the Werewolf instance that has subscribed
to the event object raised by Weather -- namely, the onFullMoon event -- via
the addEventListener function (one of your "blue collar" functions).


David
stiller (at) quip (dot) net
"Luck is the residue of good design."

David, before you start, let's work with this suedo code...

Our main movie has one frame with a MovieClip as a splash screeen--1000 X 700
On this splash screen we have two movie clips as buttons.(let's attach these
to the _root "onClick" on the splash screen)
when we mouseOver on "mc_1", "mc_2._visible=false".
when we mouseOver on "mc_2", "mc_1._visible=false".
when we onMouseDown "mc_1", "mc_1.play"
(same for mc_2)

Let's go with this to clear up this EventDispatcher.