Tutorial details:
Written by: Flashjunkie [email:flashjunkie@canada.com]
Difficulty Level: Intermediate
Requirements: Flash 4
Download FLA This tutorial will show how to create a Rock-Solid-Will-ALWAYS-Work-Advanced Double-Click based on actual time passing, not based on frame playback in a movie timeline.



What's the difference?

For starters, if you increase the FPS (Frames Per Second - or framerate) of the playback of your movie, your user suddenly has to double-click that much faster for Flash to detect it correctly. Even worse, Flash animations play back at a different rate on different CPU's. Someone on a 486DX has to double-click a lot SLOWER for frame actions to detect the double click than someone on a 500MHz P3. Because the code runs so much slower! How much slower? A piece of code I tested took 20ms to run on a 450MHz P3. It took 580ms to run on a 486DX! Over half a second longer! That means you can never truly guarantee the speed of your double-click detect EVEN IF you always have your Flash animations playback at the same frame rate.

(NOTE: Animations also play back SLOWER when in a web browser window than if they are a standalone ".swf" file.)

The solution?

A) Create a double-click detect that operates only in one frame.
B) Compensate your code for the variability of CPU speeds.

That's why there are two steps to this tutorial.

STEP 1:

Find out just how fast (or slow) the CPU that the Flash animation is running on really is.
Here is Frame 1 of the CPU tester:



Frame 2 says "GoTo Frame 1".
There is a variable on the workspace in Frame 1 called "speed". That's just so you can see the results live. The ".swf" file embedded here shows the results...

That's it.

When you start up a Flash animation, Flash starts its own timer. The timer keeps counting forever until you stop the animation. You can ask Flash what the value of that timer (in milliseconds) is at any time. You say "GetTimer". So all this code does is:

(A) check the time
(B) count to 1000
(C) check the time again.

The difference between those two times is the number of milliseconds it took your processor (while running Flash) to count to 1000.

I call that difference "CPUlag".
On a 486DX I tried this on, it took 580ms to count to 1000. Over half a second! On a 450MHz P3 it took only 20ms. One fiftieth of a second.

Now that we know how much lag our processor has, we can use that information to slow down the double-click detect to accommodate slower processors. Since on a really fast CPU the lag is going to be less than a fiftieth of a second, we can safely assume we will never need to compensate for faster CPUs. Since the CPUlag on slower processors is exactly proportional to the speed at which that CPU will read the Flash scripts, I simply add the CPUlag to the double-click detect speed.

This variable is called "gap" and it represents the amount of time in between the two clicks.
350 ms seems to be about a comfortable double-click gap (plus CPUlag).

This may seem like a lot of work for nothing but it will be the difference between the double click working for EVERYONE out there on the net or just people with fast CPUs.

STEP 2:

You have to decide what it is you want your double-click to do.
For this example, we will simply "GoTo" the next frame. In frame 1 of the movie, the window is open. In frame 2, the frame is closed.
Now for some programming questions...

What is a double-click? You do it hundreds of times a day on your PC. But it is MUCH more than just the computer testing for two clicks....
It has to test the gap between the first click and release. What if the user clicks and holds?
...and the gap between the second click and release. What if the user double-clicks then holds?
...and the gap between the first release and second click. What if you click and release fast enough... then pause too long... then click and release fast enough again?
...and the gap between the first release and second release. This is the final test. If you click, then release fast enough, then click again fast enough, finally release that second click fast enough...

THEN and ONLY then is it a double-click.
And how fast is fast enough? That's our variable "gap". (Which we added CPUlag to.)
From personal tests I found 350ms (plus CPUlag) seems to work about right.

Here we test for the first click and release being close enough together to pass:


Here we test for the second click and release being close enough together AND the gap between the two releases:


The only real trick is that if a person clicks once, releases, then pauses TOO LONG before clicking again, well then the second measured click is actually a first click. Therefore, instead of going back to frame 1 we switch the second click variables to be first click variables and stay in frame 2.

Note that even though there are two frames here, they do not run consecutively according to the movie's playback head. The only time we move from frame 1 to frame 2 is if the user has clicked the button.