me is an argument. Using me makes the handler a method of the object using it and separates the handler from being just a generic function.
Handlers in movie scripts wouldn't use me, but handlers in behaviors would since they (more than none) would want to reference the specific sprite the behavior script was applied to -- and by sprite I mean sprite script object and not the sprite as it exists in the channel (or sprite(#)). me in a movie script is useless because its value would be null - at least when attempting to use it as a "this" kind of property. Otherwise, being used in a movie script handler, its expected as any other argument.
In a method handler though, like what you would use in a behavior, me represents the sprite the handler is attached to, at least when the handler is called for that sprite. This happens a few different ways, and here is where the bounds of me as an argument and me as inherently being the object calling the handler can be confused.
For example, in an on mouseDown me event in a behaviour, the me is implied and automatically passed as a result of the event being called in reaction to the user pressing the sprite with his or her mouse. However, if you were to manually invoke the mouseDown handler with mouseDown(), me will be void.
You can correct this by, if not obvious, passing in me as the first argument (assuming you are calling the handlerfrom another handler where me is defined as the current spite). You can also use the form me.handler(arg) to call the handler in the scope of me and have all arg arguments match to those specified in the handler after me.
Along the same lines you have sendSprite which you can use to invoke handlers for sprites. This acts much like events from director and user interaction in that any arguments passed in sendSprite are applied to those after me as defined in the handlers parameters as me is defined automatically as a result of the sendSprite call.
Code:
-- Director (Movie script)
on stopMovie -- no me
clearGlobals
end
-- Director (Behavior script on a sprite)
on mouseEnter me
mouseDown() -- incorrect, no me passed, mouseDown won't know me
mouseDown(me) -- me passed as argument
me.mouseDown() -- called from me, me automatically passed as argument
sendSprite(sprite(me.spriteNum), #mouseDown) -- me automatically passed
end
on mouseDown me -- me automatic if sprite clicked on by user
put me.spriteNum
end
I guess what I'm trying to get at is that technically me is an argument and is needed for handlers to be able to reference the "this" of the sprite the handler is created for and many times its provided automatically, but not always, especially if you personally call the handler by name.
Now, in coming from Flash you have a few options to help you account for the differences of generic movie script handlers (no me) and handlers specific to the flash sprite itself (using me). These are all handled through Flash's getURL to send events from the Flash player to the host application, beit the browser window or Director. Director recognizes any text passed through in this manner but pays special attention to text preceeded with lingo: or event: (which you can consider as protocols).
lingo: specifies a generic lingo command sent to the director movie. This typically is a movie script handler call. Any movie script handler you want to call you'd use lingo: for and call it like you would directly in director passing whatever arguments you need. Of course, as a movie script handler, me is not used so no confusion there.
Code:
// Flash
getURL("lingo: MovieHandlerName(arg1, arg2, argn)");
-- Director (Movie script)
on MovieHandlerName a, b, c
put a && b && c -- puts: arg1 arg2 argn
end
event: on the otherhand, is for calling methods specific to a sprite such as those in a behavior and those using, you guessed it, me. Using event:, however is more like using sendSprite--you're not calling the handler yourself, but using event with a comma separated list of arguments that will be used to decide which event is called and how. This consists of the handler name and the arguments passed to it; a handler that uses me in its parameter list but arguments that don't not include me (as it is applied automatically).
Code:
// Flash
getURL("event: HandlerName, arg1, arg2, argn");
-- Director (Behavior script attached to Flash sprite)
on HandlerName me, a, b, c
put a && b && c -- puts: arg1 arg2 argn
end
*Note the handler name is given as a direct name and not as a symbol (using #) as is the case with sendSprite.
Now when you have no protocol specified, what you get is a generic string passed to director. Director handles this by invoking a getURL handler in the sprite as though event: was used. This getURL handler is called (with me) passing in 1 argument, that being the string of that which was included in the call of getURL from within Flash.
Code:
// Flash
getURL("Anything you want can go here");
-- Director (Behavior script attached to Flash sprite)
on getURL me, str
put str -- puts: Anything you want can go here
end
Now, like with any events in director, there is an order of heirarchy when these events are invoked from Flash. So event: and generic getURL commands can just as easily be handled through movie scripts if the Flash sprite doesn't have the methods to handle them itself (or they can be passed to from the sprite scripts to movie scripts). That all depends on how you structure your movie(s). But remember that since they are passed to the sprites first, that me argument is going to be used for representing that sprite script object and that will have to be accounted for if handling the events through a movie script (in other words include the me argument and just dont use it since it will be null).
Code:
// Flash
getURL("Anything you want can go here");
-- Director (Movie script)
on getURL me, str
put str -- puts: Anything you want can go here
end
From flash to Director
Linear Mode
