Scott Morgan

While flying back from Toronto the other day I thought of a new URL - flashmorgan.com. I visited a comic book store in Toronto, maybe it inspired the new domain name, it is somewhat super hero-ish. It’s a little more exciting then scottgmorgan.com. I don’t know how many complaints I have received from people who can’t find my site because they forgot the g in scottGmorgan.com. The new domain is much easier and shouldn’t cause any problems.

There is no need to update your bookmarks (unless you want to of course), I am not getting rid of the old scottgmorgan.com domain anytime soon.

Tags: domain name, Flash, morgan

I kept running into blogs using the same theme I was using so I decided it was time to switch it up. This new theme isn’t my final choice. I am going to be experimenting with a few new themes over the next little while. And if I find the time (highly unlikely) I may even design my own. When searching for a new theme I noticed there are a lot of bad themes out there. Anyone know of a site that has good quality WordPress themes? Please post the link in the comments below if you know of any.

Tags: Themes

First there was the Ford Fusion (the server side vehicle), then there was the Ford Edge (the corporate newsletter of the bunch), and now the Ford Flex (the highly customizable utility vehicle). What’s next, the Lincoln or Mazda CS3? Maybe the Mercury Air, or the Ford Premier. The Jaguar XK already comes with the Flash Player installed in the dash. Anyone else think this is coincidence or conspiracy?

Tags: Adobe, Conspiracy, Ford

I have been meaning to add this to my blog for quite some time now. I have read a few postings related to this topic but I am surprised there aren’t a lot more people complaining about this. Personally I feel Adobe really dropped the ball with this bug. I guess I should explain what the bug is before I go on.

Lets pretend we’re creating a button, now I know most of my readers are developers and for the most part we would never create a simple button like this using multiple frames on the timeline. But we all know that designers love to use the timeline and create button states using frames and frame labels. I actually think this posting will help designers as much as it will help the developers who are working with said designers.

Now lets pretend our button has 3 states, up, over, and down and each state is represented on the timeline, 5 frames apart and the frame is labeled the same as each state. So the first frames label is “up”, the 5th frames label is “over”, and the 10th frames label is “down”. On each frame there is a MovieClip named button and each key frame has the same graphic just tinted differently to differentiate the states. Then on our code layer we set up MouseEvents for each state MOUSE_OVER, MOUSE_OUT, and MOUSE_DOWN, in each of the event handlers we move the playhead to each frame using the gotoAndStop method while passing in the frame label that we want the playhead to move to. Ok, so this is all straight forward. Very flash 4. The interesting part of this is when you try to access sibling displayObjects on the same frame right after we call gotoAndStop.

To illustrate this bug lets add a layer below the layer that has our button on it. On this layer add a keyframe at frame 5 and add a MovieClip, whatever you want, import a picture draw a shape, it doesn’t matter. Just as long as you give it an instance name of overClip. Right after we call gotoAndStop(’over’) try and trace (overClip). If you are not completely following me right now here is a picture of what my timeline looks like:

And our code will look something like this (excuse the timeline code, but it is the easiest way to demonstrate this bug).

button.addEventListener(MouseEvent.MOUSE_OVER, rollover);
button.addEventListener(MouseEvent.MOUSE_OUT, rollout);

function rollover(e:MouseEvent):void {
     gotoAndStop('over');
     trace('the instance name of the overclip is: ' + this.overClip.name);
}

function rollout(e:MouseEvent):void {
     gotoAndStop('up');
}

In the rollover function you will notice I added a trace that traces out the name property of the overClip that appears on the out frame (or frame 5 for those of you who like numbers). If you were to run this code you will notice that the rollover works, the playhead moves to frame 5 and visually you see the change, however, the trace statement throws the following error “TypeError: Error #1009: Cannot access a property or method of a null object reference.” Null?? How can that be, the playhead is at frame 5, and the overClip is on frame 5, why is overClip null? Good question! The other odd thing is if you trace out numChildren right after the gotoAndStop(’over’) call it will return the correct number of child displayObjects. How can the player know how many children there is but still throw an error saying we’re trying to access a null object reference?

This was a very common practice in AS2, especially in highly creative sites with both Flash Designers and Flash Developers. And as more creative shops start embracing Flash 9 I think this issue will become more common.

Well, the first thing I thought to do was to call stage.invalidate() before I called gotoAndStop(’over’), in theory this should force a redraw and fire the render event. Well it did fire the render event but I still couldn’t trace out the clip on frame 5. Arghhh!

The one thing I did notice is the error is only thrown the first time rollover is called. Everytime after that the reference to overClip traces out fine. So this got me thinking. It looks like displayObjects do not register until the current frame cycle is complete. For those who do not know, a frame cycle is two parts, first the code executes, once the code on that particular frame executes any display updates are executed (adding overClip to the timeline is a display update).

The first approach to get around this bug I thought up was to kick off a EnterFrame event in the rollever function, after the EnterFrame event is fired, it still didn’t trace out overClip. Then I thought maybe I need a second frame cycle to register everything because technically the EnterFrame event fires at the exact moment the playhead hits the frame which is exactly the same problem we already have. Ok, so lets allow for two EnterFrame events to fire, kill the event, and trace out overClip. Guess what, that works. Here is the code for this approach.

var count = 0;

button.addEventListener(MouseEvent.MOUSE_OVER, rollover);
button.addEventListener(MouseEvent.MOUSE_OUT, rollout);

function rollover(e:MouseEvent):void {
     count = 0;
     gotoAndStop('over');
     addEventListener(Event.ENTER_FRAME, rolloverDelay);
}

function rolloverDelay(e:Event):void {
     count++
     if (count == 2) {
          removeEventListener(Event.ENTER_FRAME, rolloverDelay);
          trace('the instance name of the overclip is: ' + this.overClip.name);
     }
}

function rollout(e:MouseEvent):void {
     gotoAndStop('up');
}

Yes this works, but imagine how complex this mess of code would get if we had a complex 12 state button with animations on each state. Not very practical.

The only way I could come up with to get around this issue was to create an EnterFrame that fires right off the bat, moves the playhead to the last frame of the timeline, and then returns it to the first frame. This ensures that everything that exists on the last frame will be registered and you will be able to access it immediately following the gotoAndStop(’over’) call. The key to this approach is only items that are still in the display list on the last frame will register. If you have a blank keyframe after overClip it will not register if the last frame of the timeline is beyond that. Here is the code for this approach.

button.buttonMode = true;
button.addEventListener(MouseEvent.MOUSE_OVER, rollover);
this.addEventListener(Event.ENTER_FRAME, frameentered);
this.addEventListener(Event.RENDER, rendered);

function frameentered(e:Event) {
     this.removeEventListener(Event.ENTER_FRAME, frameentered);
     if (overClip == null) {
          stage.invalidate();
          this.gotoAndStop(totalFrames);
     }
}

function rendered(e:Event):void {
     if (this.currentFrame == this.totalFrames) {
          this.gotoAndStop(1);
     }
}

function rollover(e:MouseEvent):void {
     trace('the instance name of the overclip is: ' + this.overClip.
}

Excellent, we’re making progress. But we are working with a very simple example, a two state button (up and over). What if we had a more complex button, say 4 states (up, over, down, and disabled), and at each state different assets were added to the timeline like so.

I know, I said complex, and this timeline is far from complex, where are all the tweens, and hundreds of layers, guides, and masks. Well, lets just pretend all that fun stuff is there for now.

If we were to try the last approach with this more complex timeline we still wouldn’t have access to the clips on the over and down frames. This is because we moved the playhead from the first frame to the last frame and back to the first frame again. The playhead never touched anything in between so the clips on the over and down frames would not have been registered yet.

The first approach I came up with to register the clips on all the frames was quite innovative, so I thought. Basically I used the currentLabels array property of MovieClip. For those who don’t know, the MovieClip class now contains a currentLabel and a currentLabels property. The currentLabel returns a FrameLabel object if one exists for the current frame that the playhead is currently on. A FrameLabel Object contains two properties, name, and frame. The name property is the frame label name and the frame property is the frame number (int) of the current frame the playhead is on. The currentLabels property of MovieClip returns an array of FrameLabel Objects containing all the FrameLabels for the targeted MovieClip. Using the currentLabels array I thought I could loop through each FrameLabel in the array and move the playhead to each frame label and once it is complete return the playhead back to the first frame. However, you cannot use a traditional for loop because the frame cycle will not occur until the for loop is complete. Instead I set up a counter variable and use an EnterFrame to move through each FrameLabel Object for targeted MovieClip. This approach is very similar to our previous approach with more stops in between. Lets call this approach the milk run. Here is what my code looked like for this approach.

button.buttonMode = true;
var count:int;
if (count == 0) {
     this.visible = false;
     addEventListener(Event.ENTER_FRAME, proxyframes);
     addEventListener(Event.RENDER, rendered);
}

function proxyframes(e:Event) {
     stage.invalidate();
     gotoAndStop(this.currentLabels[count].name);
     trace(this.currentFrame);
}

function rendered(e:Event):void {
     count++
     trace('render called' + this.currentFrame)

     if (count == this.currentLabels.length) {
          init();
          gotoAndStop(1);
          removeEventListener(Event.ENTER_FRAME, proxyframes);
          removeEventListener(Event.RENDER, rendered);
     }
}

function init() {
     this.visible = true;
     button.addEventListener(MouseEvent.MOUSE_OVER, rollover);
     button.addEventListener(MouseEvent.MOUSE_OUT, rollout);
     button.addEventListener(MouseEvent.MOUSE_DOWN, press);
     button.addEventListener(MouseEvent.MOUSE_UP, release);
}

function rollover(e:MouseEvent):void {
     gotoAndStop('over');
     trace(overClip.name);
}

function rollout(e:MouseEvent):void {
     gotoAndStop('up');
}

function press(e:MouseEvent):void {
     gotoAndStop('down');
     trace(downClip.name);
}

function release(e:MouseEvent):void {
     gotoAndStop('disabled');
     trace(disabledClip.name);

     //disable buttons if there was a parent clip parent.mouseChildren = false would also work.
     button.buttonMode = false;
     button.removeEventListener(MouseEvent.MOUSE_OVER, rollover);
     button.removeEventListener(MouseEvent.MOUSE_OUT, rollout);
     button.removeEventListener(MouseEvent.MOUSE_DOWN, press);
     button.removeEventListener(MouseEvent.MOUSE_UP, release);
}

So why doesn’t this work. Well if you remember what I said earlier, moving the playhead only registers the last frame that it was on. If you run this code you will notice the rollover and rollout methods return null but the release method traces out the correct value, this is because that was the last stop on our playhead milk run.

In order for this approach to work I would have to layout my timeline appropriately. Each state clip should be on its own layer with nothing after it (including blank keyframes) on the timeline, like so:

Now you will notice that the above code works, we are now able to trace out the extra clips that appear on each frame with a label. However, now that everything exists on the last frame we really don’t need to loop through each FrameLabel to register the clips, we can just use our first trick and move the playhead to the last frame, once it renders move back to the first frame. Even though the looping through the FrameLabels code is overkill for this example I thought I would keep it in so people know that capability exists.

So we are able to access sibling displayObjects now but there still is one functional issue. Since the frames are cascading on the timeline when the playhead is on the down frame both downClip and overClip are visible. Likewise, when the playhead is on the disabled FrameLabel upClip, downClip, and disabledClip are visible. That little bug is not going to slip by the creative department. Normally we would get around this issue by adding blank keyframes on the frame following where the extra clip was displayed. If we were to do this in our example the clips wouldn’t register because they do not exist on the last frame and we would be right back where we started. There are two ways around this, one involves more code (the developer approach), the other involves more keyframes (the designer approach). Both are valid.

The timeline approach basically consists of adding keyframes (not blank keyframes) on the frame after the frame where the extra clip appears and setting the alpha of the clip on the second frame to 0. This ensures that the clip is still on the display list in the last frame and allows it to register. With this approach your timeline would now look like so:

Depending on what else is happening in your application this approach may not work. This is when you have to resort to code (yay). Basically with code we do the same thing, however, instead of simply setting the alpha to 0 we’ll set the visibility to false. This only requires three extra lines of code which are included below.

stop();

button.buttonMode = true;
var count:int;
if (count == 0) {
     this.visible = false;
     addEventListener(Event.ENTER_FRAME, proxyframes);
     addEventListener(Event.RENDER, rendered);
}

function proxyframes(e:Event) {
     stage.invalidate();
     gotoAndStop(this.currentLabels[count].name);
     //gotoAndStop(this.totalFrames);
     trace(this.currentFrame);
}

function rendered(e:Event):void {
     count++
     trace('render called' + this.currentFrame)

     if (count == this.currentLabels.length) {
          init();
          gotoAndStop(1);
          removeEventListener(Event.ENTER_FRAME, proxyframes);
          removeEventListener(Event.RENDER, rendered);
     }
}

function init() {
     this.visible = true;
     button.addEventListener(MouseEvent.MOUSE_OVER, rollover);
     button.addEventListener(MouseEvent.MOUSE_OUT, rollout);
     button.addEventListener(MouseEvent.MOUSE_DOWN, press);
     button.addEventListener(MouseEvent.MOUSE_UP, release);
}

function rollover(e:MouseEvent):void {
     gotoAndStop('over');
     trace(overClip.name);
}

function rollout(e:MouseEvent):void {
     gotoAndStop('up');
}

function press(e:MouseEvent):void {
     overClip.visible = false;
     gotoAndStop('down');
     trace(downClip.name);
}

function release(e:MouseEvent):void {
     gotoAndStop('disabled');
     trace(disabledClip.name);
     overClip.visible = false;
     downClip.visible = false;
     button.buttonMode = false;
     button.removeEventListener(MouseEvent.MOUSE_OVER, rollover);
     button.removeEventListener(MouseEvent.MOUSE_OUT, rollout);
     button.removeEventListener(MouseEvent.MOUSE_DOWN, press);
     button.removeEventListener(MouseEvent.MOUSE_UP, release);
}

That’s it. Adobe, if you are reading this, please, please, please fix this bug. It is very annoying. It is obvious that Flash Player 9 was built with Flex in mind (aka no timeline) since that is all that was available when Flash Player 9 was released. I remember reading someone from Adobe admitting that on their personal blog, if I can find the link again I will post it in the comments below. I covered a lot here, but this bug goes even further. Sometimes Event.RENDER doesn’t even fire. In another related bug stop events on the first frame of nested MovieClip do not always work. Supposidly Adobe fixed this in version 9.0.45 of the player but as you can see by the comments on Emmy’s blog posting about the 9.0.45 release it was never really fixed. In fact we ran into this issue at work recently in the latest 9.0.115 version of the player.

I actually met with the Adobe Flash Player team last week and we discussed a lot of these issues, hopefully they will take these into consideration for the next release. To a developer they may seem like minor issues but designers and animators are going to have a difficult time getting around a lot of these bugs. If anyone else has any workarounds please feel free to explain them in the comments below.

P.S. this is my longest post ever, yay me.

Tags: actionscript 3.0, Bugs, flash player

I recieved an email yesterday from a Microsoft technical recruiter wanting to hire me as a Flash Developer, or as they called it, a Media Author. After I laughed out loud, sent it to a few colleagues who also laughed out loud, I thought about this for a second. Not about taking the job, I would rather be probed by aliens than work for Microsoft. I thought who in their right mind would take a Flash job at Microsoft? It would be like sitting on death row. Talk about a dead end job!

It is obvious Microsoft is trying to kill Flash, it will never happen, but when they do start to push hard, and Silverlight penetration reaches, I don’t know, double digits, why would they employ anyone using a competing technology. Probably because they know Flash is superior and it is going to be a severe uphill battle to even compete. Maybe they would hire me and brainwash me to be a Silverlight developer, then slowly hire every flash developer out there and “convert” them. Ok, maybe a bit far fetched, but would you put anything past Microsoft? I also find it humorous that they don’t even use the word Flash in the job title.

With that said, here is the recruiters email to me. My favorite line is “I am sure you would be interested in working in the Microsoft campus on exciting, challenging projects.” They couldn’t be more wrong.

Hello,

This is [name removed to protect the innocent] , Technical Recruiter with [name removed to protect the innocent], Seattle and a preferred vendor for Microsoft, Redmond in Seattle for contract and some full time positions.

I came across your resume online and as I was going through it, I would like to know more about what kind of roles you are looking for, what skills, areas you would like to work on, what you are passionate about and try to find suitable challenging positions for you . We do long term contracts which are generally extendable beyond a year, we do full time positions, we do contract to hire positions too. Depending on what you are comfortable with and what you are looking for, we will look, and help you find the right positions. I am sure you would be interested in working in the Microsoft campus on exciting, challenging projects.

Currently I have a long term contract position with the MSN Media Solutions Team at Microsoft, Redmond and they are looking for Flash developers.

1. Position: Media Author (Flash Developer)

Requirements:

Experience developing Flash site, components, and/or games. Proficiency in Flash, Photoshop, ImageReady or Illustrator.

Experience with Flash ActionScript

Some JavaScript experience, working knowledge of html, and web based design experience.

Experience in driving work through the software development process.

Experience in audio and video encoding and editing is a plus.

Do let me know if you would be interested and send your latest resume ASAP

Thanks and Regards,

[name removed to protect the innocent]

Does anyone else find this as funny as I do?

Tags: Flash, Microsoft, Silverlight

Better late then never right? For about a year and a half, maybe even 2 years now, developers have been requesting an Actionscript 3 Yahoo Maps API. To cool the fires I wrote the Yahoo Maps Communication Kit, which was a hack that allowed you to use the Actionscript 2 Yahoo Maps component in an Actionscript 3 application. I am glad to say that the Maps communication kit is no longer needed. Head on over to the Yahoo Flash Developer center and download the real Yahoo AS3 Maps Component.

The component looks great, out of the gate I did notice one bug though. They didn’t account for the MOUSE_LEAVE event. You can see this bug in this example, start dragging the map and move the your cursor outside of the map, if you release your mouse while you are still outside of the map and move your cursor back into the map you will notice the map is still moving. A very minor bug. I can’t wait to use this component. I already have a few ideas where I can use it.

Thanks Yahoo! Let’s hope this doesn’t turn into the Microsoft Live Maps AS3 component

Tags: actionscript 3.0, maps, Yahoo

My former peeps over at Yahoo just released 10 more components, 3 Flash and 5 Flex components. The also fixed some of the bugs that the community reported in the existing components.

For the Flash world Astra now contains an AlertManager, an AudioPlayback component, and a MenuBar component that works with the existing Menu component released in Astra 1.0.

For the Flex folk the kind gents on the Yahoo Flash Platform team have created an AutoCompleteManager, a few different ColorPickers, an IPV4AddressInput, a TimeInput component, and a TimeStepper component.

Nice work guys, and now that I am not part of the team and a user of Astra I say thank you for all your hard work.

Tags: astra, Flash, Flex

Since it won’t stop raining here in Southern California I brought the kids to the McDonalds in Burbank yesterday to burn off some energy in the play land. We ordered a couple happy meals with the incredibly shrinking cheeseburgers and I ordered a meal. While the kids were traveling through the miles of urine scented plastic caves I looked down at the receipt, to my surprise there was a one dollar “Eat in tax”. I have never noticed that before, I usually don’t study the receipts at McDicks but come on. Was there a VIP section with leather furniture that I somehow overlooked? Does McDonald’s charge this everywhere? I guess next time I will order it to go and bring the bags into the playland.

Tags: McDonalds, tax

Now that H.264 video is supported in Flash Player 9.0.115 and FMS 3 is on the horizon we are getting ready to flip on the HD switch in our video player. We have been lucky enough to try out a few beta releases of FMS 3 and have had great success with streaming H.264 video without too many changes to our core video player component (both AS2 and AS3). However, I ran into an issue yesterday with progressively downloaded H.264 video. The video would play but it was not progressively downloading, it would download the entire file before it began playing. Not the user experience we were looking for. The files played fine in Quicktime, and they played fine in Flash when streamed from FMS 3, just not progressively.

Time to hit Google. I found a few postings, not many, probably not too many people using H.264 yet (so I thought). Turns out the problem lies within the encoding of the file and where the “moov atom” is stored. The moov atom is essentially the header information of the file. To progressively play a file this data is needed before the first frame of video can play. This data contains the appropriate meta data the NetStream class looks at when determining the length, size, etc of the video. The moov data in my .mov files were stored at the end of my videos and that is why the video wouldn’t play until the entire file was downloaded. The moov data needs to be at the beginning of the file in order to progressively stream video.

I figured others must have run into this issue and someone must have wrote a utility to move the header bytes from the end of the file to the beginning. Byte manipulation isn’t rocket science, close, but not quite. While searching I found an interesting tech note on the Adobe site and it turns out Adobe’s own video editing software is to blame for this. The quote below is pulled directly from the tech note explains the issue.

“One important thing about playing an H.264 video file as progressive download is that the moov atom needs to be located at the beginning of the file, or else the entire file will have to be downloaded before it begins playing. The moov atom is a part of the file that holds index information for the whole file. Unfortunately, tools such as Adobe Premiere and After Effects place this information at the end of the file, but Adobe is working to fix this in a future update to the CS3 video production tools. This isn’t an issue for streaming the H.264 video files, however, so Flash Media Server users can breathe easy.“

Why didn’t Adobe address this issue? Obviously they rushed this feature to market, Silverlight supported H.264 video and everyone was raving about it. I don’t know if Silverlight progressively streams H.264 video when the moov atom is at the end of the file or not. Can anyone confirm? Or maybe this was some sick marketers ploy to entice users to buy FMS 3, i doubt that but conspiracy theories are so much fun.

Scouring the web I did find a utility that moves the moov atom to the start of the file. Renaun Erickson ported a C app to AIR that moves the moov atom and resaves the file. Very impressive! Unfortunately it didn’t fix my issues, Renaun’s app only works with .mp4 files and the files I was working with are .mov files. Using Quicktime Pro I exported one of the .mov files to a .mp4 to see if Renaun’s app would then move the moov atom. Still no luck. As a last resort I tried a simple Save As from Quicktime to see if it would restructure the bytes so the moov atom was at the beginning of the file. Guess what, it worked! My progressive downloads now worked. I created a simple batch and saved out all my progressive videos using Quicktime.

It baffles me that Adobe would not have put more thought into this problem especially when their own software is the culprit. They talk about CS3 suite integration and this is the furthest thing from that. Adobe mentions that they will be releasing a CS3 update to address the issue, hopefully sooner than later, unfortunately this does not help people (like me/us) who already have hundreds of H.264 assets with the moov atom at the end of the file. Re-encoding the video would be a huge process, we are already using the video assets for other streaming services, now that Flash supports H.264 we were hoping for an easy switch to our Flash video player. Most of our video is streamed, and that works great, unfortunately the progressively downloaded video wasn’t an easy switch.

In the end, the video looks great! Watching 1.2mb and 3mb fullscreen video in Flash is unreal. Now if we could just get support for variable bitrates!!

Tags: Flash, h264, video

Tonight my first public facing work since I started at Disney 3 months ago went live. Usually when you start a job you start out slow, do the odd update here, maybe add a widget or two to a page a few levels deep. Not this time, I was tasked to rebuild Disney.com in AS3. Not only rebuild it but optimize it and add a few features.

This is Disney’s public face on the internet. <sarcasm>A small site</sarcasm>, only 23+ million unique users a month, needless to say there were a lot of stakeholders and a lot of people looking over my shoulder (and a lot of backseat qa testers :). Talk about new job pressures. That’s OK, in a sick, sadistic way I actually enjoy the pressure and stress of it all. You have to in this industry or it will chew you up and spit you out.

Now when you hit disney.com everything you see is AS3. If you visited the site before you will notice a huge performance improvement, most of this is simply AS3 being 10 times faster than AS2, however I did optimize a lot of the code while porting it.

The biggest item to change on the site is the carousel. Visually there isn’t much change (other than the opening animation build) from the previous version, it’s what’s under the hood. The carousel is now built using Papervision, unfortunately all of the features I built into this component are not yet live on the site (stay tuned for another update in the near future). Just like the previous version you use the arrow buttons to rotate the carousel. You can either click the arrows to rotate the carousel one tile at a time, or hold the mouse button down over one of the arrows and rotate the carousel until you release the mouse button. When the carousel stops it centers on the tile closest to the camera and plays an animation for that given tile. You can interrupt the animations at anytime by clicking either of the arrows which forces the animation closed and then rotates the carousel.

Check it out, let me know what you think, and remember, this is only the beginning. There is some real cool stuff on the disney.com horizon.

Tags: actionscript 3.0, disney, Papervision3D