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();

(more…)

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?
(more…)

To describe the problem succinctly: when you’re trying to create a horizontal menu using unordered lists (<ul> and inline <li>), for some reason, in Firefox (2 - I don’t know about 3 which just came out last week), if there is any whitespace between a closing </li> tag and the opening <li> tag of the next item, that whitespace actually displays. At first it looks like a margin spacing issue, but after some tests it’s clearly not. In fact, what baffles me is that ANY text between the closing </li> and the opening <li>, that text actually gets displayed inline! Which makes no sense, because I didn’t think that the <ul> element could have a text node as a direct child. Apparently it can, in Firefox at any rate.

The solution, as I have discovered is to set your <ul>’s display attribute to “table”. I don’t believe IE7 and certainly not IE6 understand display:table, so this is a non-IE fix, but then again, IE wasn’t exhibiting the whitespace behaviour. Here’s some sample code.

 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"

	"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">

<head>

<title>Untitled Document</title>

<style type="text/css">

    *    { margin:0; padding:0; }

    ul {

        list-style-type:none;

        list-style-position:inside;

        margin:0px; padding:0px;

        display:table; /* This is used for firefox */

	/* to avoid the horizontal whitespace bug */

    }

    li {

        border:1px solid black;

        display:inline;

        margin:0px; padding:0px;

        border-collapse:collapse;

    }

    a {

    }

</style>

</head>

<body>

    <ul>

        <li><a href="#">Line 1</a></li>

        <li><a href="#">Line 2</a></li>

        <li><a href="#">Line 3</a></li>

    </ul>

    <p>Other stuff....</p>

</body>

</html>

As I put together a solution for this brave soul, I encountered a few interesting challenges, and a few frustrations. Thought I’d document it here because I couldn’t find anyone else who had addresses the intricacies of having two SWF share a SharedObject and monitor the status of that shared SharedObject so they could respond to a change in status.

Here’s the basic principle:

• Application 1 creates a local SharedObject and sets an initial status
• Application 1 also registers an enterFrame event listener that listens for a status change on the SO
• Application 2 accesses the same SO and at some point, changes the status
• Application 1’s enterFrame handler detects the status change, and responds to the event.

As I write this, I see there’s an opportunity for a custom event class that does all this, but I’m going to leave that to the real gurus. I don’t pretend to have that intimate a knowledge of ActionScript to be able to pull that off. I should also point out at this time that the original EE user’s question was for AS2, so this solution is only tested in AS2, though since the issues I was running into were related to variable scope, I would only imaging that an AS3 implementation would be easier, if anything.

Here are the challenges I encountered:

• how to launch one EXE Projector from another EXE Projector
• how to share a SharedObject between two Flash movies (SWFs)
• how to continuously monitor the value of a shared SharedObject

(more…)

 Zeitguys is such a cool name, and I’ve always thought it would be neat to call our employees a “zeitguy”, so I came up with these shirts. Then I just went nuts and I realized, hey, other people might think this was cool too. So the Zeitguys Apparel store at Zazzle.com was born.

Check it out! The stuff’s not expensive, shipping is cheap, and if you’re at all geeky, you might get a kick out of our newest: the propellerhead “I’m hip. I’m with it” or the glasses with [iiii] (four eyes - get it???). I slay me.

Cheers!

 The poster wanted to create a popup window using HTML and JavaScript that would open when the page first loaded, but then, if the user navigates away from that page, and then came back, would not bother them by popping up again.

 Here’s the solution:

The command for a popup window is:
window.open();

To make the window open when the user first comes to your page, you put the popup in the HTML <body> tag like this:

<body onLoad=”window.open();”>

There are some additional parameters you can pass to window.open() to do things like set the name, the size etc.

If you want to make sure the popup only happens once per session for a user (so it doesn’t pop up every time) you need to set a session cookie.

The session cookie is stored on the person’s computer and is erased once they close their browser window. This is useful for making sure that the NEXT time they visit the site, they will see the popup again.

If you don’t want the user to ever see the popup again after the first time, use a regular cookie that doesn’t expire, or expires in a very long time.

These are some excellent tutorials on setting and reading cookies. You’ll have to brush up on your JavaScript skills a little.

http://www.quirksmode.org/js/cookies.html
http://www.w3schools.com/js/js_cookies.asp

For a general tutorial on JavaScript, check these guys out:
http://www.w3schools.com/js/default.asp

Here are all the parameters you can pass to window.open to do all sorts of neat things with the popup window. This page is a little technical, so maybe wait until you’ve got a basic window working before trying to tweak the popup window with help from this link:
http://www.w3schools.com/htmldom/met_win_open.asp

Cookies will probably be the hardest part for you to implement. So I’m just going to copy and paste some code here, straight out of the w3schools tutorial, with a bit of explanation and some specific code for you:

first, in the <head> of your HTML page, start with your <script> tag:

<script type=”text/javascript” language=”JavaScript”>
// the rest will go inside here (see below)

</script>

Okay, now, copy and paste the following functions into the area we’ve left for the Script tags.

function mySetCookie(c_name,value,expiredays)
{var exdate=new Date()exdate.setDate(exdate.getDate()+expiredays)
document.cookie=c_name+ “=” +escape(value)+
((expiredays==null) ? “” : “;expires=”+exdate.toGMTString())
}

function myGetCookie(c_name)
{
if (document.cookie.length>0)
  {
  c_start=document.cookie.indexOf(c_name + “=”)
  if (c_start!=-1)
    {
    c_start=c_start + c_name.length+1
    c_end=document.cookie.indexOf(”;”,c_start)
    if (c_end==-1) c_end=document.cookie.length
    return unescape(document.cookie.substring(c_start,c_end))
    }
  }
return “”
}

// —————————————-

Okay, those are the functions we’ll use to set and retrieve the cookie to see if the user has already seen the popup window.

Now here’s the custom code that you’ll put after the code you just copied and pasted (still inside the SCRIPT tags). We want to check if the user has already got a cookie. If so, it means the user has already been to this page and (presumably) seen the popup already, so we don’t display it again. Otherwise, we display it.

function showPopupOnce() {
   var hasSeenPopup = myGetCookie(”has_seen_popup”);
  if (hasSeenPopup == null || hasSeenPopup == “”){
     // the user has never seen the popup, so show him!
    window.open(”http://mywebsite.com/popup.html“, “myPopupWindow”);
   }

   // either way, set the cookie so the user will never see the window again
   mySetCookie(”has_seen_popup”, “true”, 365); // 365 days = 1 year
}

// ——————————

Okay, great, now the only thing to do is make sure that the showPopupOnce() function runs whenever the page loads. Go into the <body> tag and change it to this:
<body onLoad=”showPopupOnce();”>

That should do the trick.

Tom

 Now it gets better. Every month they will feature a new, full album for free download. Come check it out here.

Here are some lessons learned:

• Make sure you enable Bluetooth in your cellphone first. It defaults to off. The Motorola V361 Manual proved quite helpful in this regard. Main Menu > Bluetooth Link > Setup > Power > On.
• Next you must set your headset in Bluetooth Pairing Mode. For the Motorola H350 / H500, you make sure it’s turned off, and then press and hold the “Phone” button on the front of the device. Hold the button down (for about 10 seconds) until the blue light around the Motorola icon (also on the front of the device) remains lit, solid blue (not flashing). Now you are in “pairing” mode, which enables this to “bond” with other devices.
• Now, on the cellphone, go to the Bluetooth configuration screen. Main Menu > Bluetooth Link > Handsfree > Detect. This will take about 3 seconds and it will detect your earpiece. Interestingly, it detected it as an H500. Hey who knows, maybe I have an H500 instead. At any rate, now the whole kit and kaboodle works fine.

So there you have it. Setting up your Motorola Bluetooth Headset for the first time.

Not sure yet how this is going to “change my life”. Doubt it highly. If anything, it will just add one more stressor as there is yet one more thing that I ought to be doing with my time. Meh.

The first step is going to have to be customizing this template. Damn. More things to do and learn.