— tomauger.com

I was going through my archives and discovered a number of little demos and tests done in AS2, either to satisfy my own curiosity, or to answer questions posted on Experts Exchange. Here’s another one.

This demo illustrates the use of ExternalInterface to access the URI of the containing web page. This sort of thing becomes useful when handling deep linking within large Flash multi-page sites.

Workaround 1: Redesign

The solution is reasonably simple: tell your designers to insert a “landing” frame containing the stop() instruction in a frame BEFORE the actual frame that you will be jumping to. So, if you were doing gotoAndPlay(1), instead, have the designer insert a keyframe at frame 1, include the stop() action on that frame, and then duplicate that keyframe to frame 2, at which point you can start your animation loop. Now you’ll call gotoAndPlay(2).

Workaround 2: enterFrame()

Okay, so what if you don’t have the luxury of being able to modify the frame structure of the clip(s)? What if it’s rampant throughout your movie? We’ll make a little modification to our method for jumping to the frame in question.

(Bear in mind that this solution specifically addresses ActionScript 2 code):

buttonMC.onPress = function(){
	this.gotoAndPlay("down");
}
 
buttonMC.onRelease = buttonMC.onReleaseOutside = function(){
	this.gotoAndPlay("up");
	this.onEnterFrame = continuePlay;
}
 
function continuePlay(){
	this.onEnterFrame = function(){};
	this.play();
}

Here you can see that when we call gotoAndPlay() we attach an enterFrame handler that is responsible for doing two things:

1. call play() on the clip, to get it going again after the stop() was called from the frame script
2. clear itself (so you don’t call play() every single frame, essentially rendering any future frame script stop() commands useless)

Download Source

And to all you snobs…

Who are tempted to register just so you can post a snotty comment that “real Flash developers don’t use frame scripts anyway”, let me get a pre-emptive strike in. First of all, yes, you’re right. Real Flash devs have been trained (I didn’t say “brainwashed”…) to never use frame scripts. BUT, if you’re more than a grubby-haired teen working alone in his basement, you’ll know that in the real world we often work in these things called “teams”, where you have folk of all sorts of different expertise. We work with these guys called “designers” who can barely be convinced to open up the Actions panel and type the word stop followed by open and close brackets (“why!?!” they cry in despair. “Why the brackets??!”) and a (gasp) semicolon.

And these Designer types, they like to preview their flash movies. And they get really distressed when their buttons start flashing wildly and animating on their own. So we appease them by letting them do this one – and only this one – thing in an inline frame script.

Of course the proper way to do things is to call stop() on the movieClip in your Document Class init() method. And in fact, we’ve even found ourselves writing these complicated recursive methods that drill into every movieClip present on init and stop them programmatically. But like I said, often the designers live with the Flash far earlier in its project lifecycle than we do, so they insert all these little stop(); commands all over the place.

And there you have it.

Wow, speaking of “snotty”, those last two paragraphs were pretty snide. If you haven’t shut down your browser, purged my blog from your bookmarks (you did have my blog bookmarked didn’t you?) and removed me from your blogroll, well thanks for indulging my ranting ways. Speaking of ranting ways, just wait until you see my follow-up to my Apple rant. It’s a-brewin….

To me this seems like a basic problem in many Flash-based interfaces. I think Adobe did too, which is why in AS3 they completely revamped their approach to layering display objects.

This leaves those of us stuck back in AS2.0-land (because some customers insist they want their Flash published as FlashPlayer 8! ) scratching our heads. Kirupa, Senocular and other worthies have come up with an interesting technique which keeps a “top-layer” counter, increments it by 2 every time you want to swap depths. While this works perfectly well, there’s something about the technique that, to me (no offense guys: you’re genii), seems like quick-and-dirty (with the emphasis on dirty) code. At some point, I reason, one just HAS to hit that upper layer limit. I’m sure it’s like layer 65538 or something, but still – since you’re using SwapDepths() anyway, why can’t you just find that currently top MovieClip and swap the one you want with it. That way you’re never increasing the top layer count and away you go.

So here’s my take on a bringToFront function. (Note: this is an update to the previous version with some substantial improvements).

Here I’ve added the bringToFront function to the MovieClip prototype, so that you can use it with any movieclip as if it were a native method, like this: myMC.bringToFront();

Can you believe it? You go through the pain of creating a custom cursor in Flash, and then when the user does something pesky like roll the mouse outside the Flash area, your custom cursor (which is really nothing more than a MovieClip that follows your cursor in disguise) stays in its last-known position – wedged somewhere near one of the outer boundaries of your stage, but definitely not looking right, since the “real” mouse is now happily tracking (or whatever it is real mice do) somewhere else on the screen. Two cursors, one big egg in your beer.

After doing some research, it seems the most advanced thinking on the subject (other than those crackpots who tell you to look to external JavaScript to solve the problem – which is bogus) is to use a first-order predictor (velocity) to “guess” (well, “predict” to be precise) where the mouse would be during the next poll. Well, I tried to implement that and I found that the results left somewhat to be desired. Considerably somewhat.

The way this “first-order prediction” business works is: once the mouse leaves the stage, _root.xmouse and _root.ymouse no longer give us meaningful information, because Flash is unable to track the mouse position outside of its own “domain”. So if you’re relying on, say a test to see whether _root.xmouse > 0 to detect whether your cursor has exited stage left, you’re SOL – _root.xmouse will still be reading 4, or 10 or wherever your mouse was LAST time it checked. So what we want to do is to predict where the mouse will be next time, based on where it was last time. In other words: velocity. That’s your “first-order predictor”. And boy does it look good. At first.
As you may or may not remember from your grade X Physics class (I actually didn’t remember – I was too busy oogling my teachers emphatic retort to Newton’s law of gravity – yeah, you Centennial CVI boys know what I’m talking about) velocity can be measured as the change in distance (“delta”) between two points over time. Now since we’re not really dealing with time per se as much as mouse movement over a frame, the equation is simplified quite a bit. As in vx = x2 – x1. So now, if you want to see whether the mouse will be off to the left of the stage, you can just add the velocity into your test to see whether _root.xmouse + vx > 0. Following me? Of course you are.

But, just so I can be clear for myself: if the first time we checked the xmouse was at, say 5 (near the left of the stage) and the second time (now) it’s at 2, x2 – x1 = 2 – 5 = -3. So now we check to see where it will be next time: _xmouse + vs = 2 + (-3) = 2 – 3 = -1 < 0. Great. So the mouse is off the stage. Roll drums, toot horns.

The problem occurs when you “flick” the mouse rapidly off the stage. What’s happening is that now our velocity is changing rapidly, which means that our prediction underestimates where the next position will be, and usually undershoots the mark. If you think about it, you’re not moving the mouse, then all of a sudden you flick it to the left. But, since the mouse is a physical object, it’s subject to the laws of physics, as are you, and so the mouse doesn’t really go from 0 – 60 in an instant. Like a car, it accelerates. Which means that the velocity is increasing over time – so our wonderful first-order prediction is hokey because it’s basing its calculation on a constant velocity.

So I took it one step further and used acceleration in the calculation, rather than velocity. Or rather, in the second poll I still use velocity (because you need three coordinates to calculate acceleration, and at the second poll we only have two points), but in the third poll I discard the velocity predictor for my second-order predictor and get much more accurate results.

Enough mumb-jumbo. Give us the code already, right?