I actually took this from production code!

I’ve had it with events in ActionScript 3! They are annoying to structure, annoying to extend, annoying to dispatch but most importantly annoying to consume – and I consume events a lot more than write or dispatch my own.

But! The idea of listening for stuff I really do like. I have some ideas about how this could be done a lot easier. Oh, and please stick around until the very end of this post.

Background

For those who can’t remember exactly, events in AS3 are consumed by listening for certain events and passing a function, that will be called when this event occurs. The function will always be invoked with the event type, that you listen for – and only that argument will be given to the callback. You cannot define extra arguments in any way or not accept the event argument. Let’s for example listen for when the use clicks a button – which is the MouseEvent.CLICK event (of type MouseEvent of course):

public function init():void {
  var myButton:Sprite = new Sprite();
  ...
  myButton.addEventListener(MouseEvent.CLICK, buttonPressed);
  ...
}
private function buttonPressed(me:MouseEvent):void {
  trace("the button has been pressed, hurray");
}

We abidingly accept the me:MouseEvent argument even though we don’t intend to use it.

The event object has information about the event, about who sent it, information related to the bubbling nature of events (that very few people ever use in ActionScript 3) and additional specific attributes only relevant for specific events. For instance, if we have several buttons representing different related actions, we can examine the event.target

private var selectRed:ColorButton;
private var selectGreen:ColorButton ;
private var selectBlue:ColorButton;
public function init():void {
  ...
  selectRed.addEventListener(MouseEvent.CLICK, selectColor);
  selectGreen.addEventListener(MouseEvent.CLICK, selectColor);
  selectBlue.addEventListener(MouseEvent.CLICK, selectColor);
  ...
}
private function selectColor(me:MouseEvent):void {
  var color:ColorButton = me.target as ColorButton;
  if (!color) {
    throw new Error("color selected was not actually a color");
  }
  switch (color) {
    case selectRed: trace("you chose a red Papa Smurf"); break;
    case selectGreen: trace("you chose a green Papa Smurf"); break;
    case selectBlue: trace("you chose a blue Papa Smurf"); break;
  }
}

Here, we do use the MouseEvent-object, but we cast the target property to the type we expect it to have and then we need to check, if the cast went well. Because, technically we could have used the same function as a listener for something else somewhere else (even though we know we didn't) and thus target could have been something entirely different.

Personal experiences

I've just checked a recent, larger project with 185 (home-made) classes. In general I try to minimize my event usage, but a lot of things I have to use events for event though I don't really need them, so I ran a simple script counting how many times I had a function that took an event as an argument, and how many of these actually used the event object. The result was 121 functions accepting an event as argument (10 of those had default null values), and in only 4 of those I actually used the event argument (one of them a KeyboardEvent, the others were all the same home-made PageEvent). 83 of the events accepted were MouseEvents (which is no surprise), and never was the me:MouseEvent variable used in the function body.

Then, I tested an even earlier project from before I started minimizing event usage (almost maximized it back then). It consisted of 50 (home-made) classes. It had 113 functions (a lot more per class than the above) accepting event arguments (16 of those defaulting to null) and 74 of those were MouseEvents. And this time around, I used the event argument 25 times, but 18 of these usages were accessing event.target or event.data and casting it to the right class. Thus, yes I did use the event argument in some cases (22% of the time I accepted an argument), but in most of them I still had to do manual casting of the event.target (or event.data) attribute to get the type I knew I was accessing. This leaves only 7 "true" usages or about 6%. Please see the background section about why using the event object for casting only just moves the problem around and makes the code even more verbose.

Dream scenario

So, what would I like instead? Something intelligent, that allows me to accept the arguments I need when I need them. For instance, take this snippet here:

private var close:CloseButton;
public function init():void {
  close.addEventListener(MouseEvent.CLICK, closeDialog);
}
private function closeDialog():void {
  someDialog.fadeToOblivion();
}

It is simple, I do not need any argument, so I do not expect one.

A often used situation is when you have several instances of the same type and attach the same listener to all of these, then you use the event argument's target attribute for switching on which instance was invoked and handling the result correspondingly:

private var downloadLowRes:DownloadButton;
private var downloadMediumRes:DownloadButton;
private var downloadHighRes:DownloadButton;
public function init():void {
  downloadLowRes.addEventListener(MouseEvent.CLICK, download);
  downloadMediumRes.addEventListener(MouseEvent.CLICK, download);
  downloadHighRes.addEventListener(MouseEvent.CLICK, download);
}
private function download(db:DownloadButton):void {
  switch (db) {
    case downloadLowRes: open("file_360p.avi"); break;
    case downloadMediumRes: open("file_720p.avi"); break;
    case downloadHighRes: open("file_1080p.avi"); break;
  }
}

The function expects a reference to the button clicked - not to an event, who references the button clicked, because only the actual button reference is necessary.

Finally, a more elaborate example of different other component listeners expecting just what they need and nothing else:

public function init():void {
  // listen for selections in a dropdown
  countryDropdown.addEventListener(Event.SELECT, selectCountry);
 
  // listen for checkbox changes
  acceptTermsCheckbox.addEventListener(Event.CHANGE, acceptTerms);
 
  // listen for focus changes between password input fields
  passwordInput.addEventListener(FocusEvent.FOCUS_OUT, checkPasswords);
  passwordConfirmInput.addEventListener(FocusEvent.FOCUS_OUT, checkPasswords);
 
  // listen for three different radio buttons changing
  languageDanish.addEventListener(Event.SELECT, selectLanguage);
  languageSwedish.addEventListener(Event.SELECT, selectLanguage);
  languageNorwegian.addEventListener(Event.SELECT, selectLanguage);
 
  // listen for submit button presses
  submitButton.addEventListener(MouseEvent.CLICK, submit):
}
private function selectCountry(country:String):void {
  selectedCountry = country;
}
private function acceptTerms(accepted:Boolean):void {
  termsAccepted = accepted;
}
private function checkPassword(fe:FocusEvent):void {
  if (!(fe.relatedObject in [passwordInput, passwordConfirmInput])) {
    // focus moved away from either input field
    // show mismatch alert if texts are not the same
    passwordMismatchAlert.visible = passwordInput.text !== passwordConfirmInput.text;
  }
}
private function selectLanguage(language:LanguageRadioButton):void {
  switch (language) {
    case languageDanish: load("texts_da.xml"); break;
    case languageSwedish: load("texts_se.xml"); break;
    case languageNorwegian: load("texts_no.xml"); break;
  }
}
private function submit():void {
  sendForm(withParameters);
}

One notable example among the above is, that if an event is needed, you can always have it. I only dislike events, when I don't need them but have to accept them anyway. When I actually need it, they do come quite handy - like the FocusEvent.relatedObject used in the above example.

Announcement

Actually, I have made the above work! It is a dirty, dirty triple-hack, but it feels quite sweet to use on both ends. I need to clean it up a lot, need to come up with a good name for it and need to benchmark it to see, that it doesn't kill performance (too much).

So please, stay tuned. But do not fear commenting on the above ideas anyway.

Related posts:

1. Link sharing spam on Facebook

1. Setup
2. Direct children
3. Descendants
4. Conclusion

I was playing around with E4X last night working on an upcoming blog post about the capabilities of E4X. While playing, I was thoroughly reading the ECMA-357 standard, and found that there are some special rules about assignment and compound assignment, that produce truely unexpected results.

I will try to summarize common pitfalls and provide valid work-arounds.

Setup

This post will for most examples work on the following document:

var e:XML = <employees>
	<person>
		<name>John</name>
		<age>35</age>
	</person>
	<person>
		<name>Joe</name>
		<age>25</age>
		<hobby>Swimming</hobby>
	</person>
</employees>

Sometimes other documents will be used explicitly.

Direct children

How would you go about changing the hobby of Joe to running? Well, we could traverse all the way to the node:

e.person[1].hobby = "Running";

This of course works as expected. Actually, we ought to be able to skip the index [1], as only the second person has a hobby and thus only this node ought to be the target for the update:

e.person.hobby = "Running";

But no, this throws a runtime-error:

TypeError: Error #1089: Assignment to lists with more than one item is not supported.

But it is not a list with more than one item, is it?

trace(e.person.hobby.length()); // traces 1

The issue here (I expect, I had a hard time figuring out what the spec actually said about it) is, that the second-to-last list in the assignment target has more than one item:

trace(e.person.length()); // traces 2

This can be tested by introducing some extra level of nodes and try to update one of these:

var more_nodes:XML = <employees>
	<person>
		<name>John</name>
		<age>35</age>
	</person>
	<person>
		<name>Joe</name>
		<age>25</age>
		<hobby>
			<primary>Swimming</primary>
			<secondary>Sewing</secondary>
		</hobby>
	</person>
</employees>
trace(more_nodes.person.length()); // traces 2
trace(more_nodes.person.hobby.length()); // traces 1
trace(more_nodes.person.hobby.primary.length()); // traces 1
more_nodes.person.hobby.primary = "Running"; // no error, updated as expected

Voila, it works. What this means is, that the error is not related to the actual XMLList, that you are assigning to – but to the XMLList, that is the parent of this in the statement. We could actually have reached the desired result by adding an extra level to reach the text node inside the (single) hobby node:

e.person.hobby.* = "Running"; // no error, updated as expected

In this case again, the second-to-last XMLList (the target object for the assignment) has a length of 1, and the update can be accomplished.

Descendants

But if we really just wanted to update the single hobby, that we know only one of the employees have, then we would normally try:

e..hobby = "Running";

Now things start to get really interesting. Because, what happened? No error was thrown, but the document after this update looks like:

<employees>
  <person>
    <name>John</name>
    <age>35</age>
  </person>
  <person>
    <name>Joe</name>
    <age>25</age>
    <hobby>Swimming</hobby>
  </person>
  <hobby>Running</hobby>
</employees>

That is, the existing hobby was unchanged, but a new hobby node has been appended to the end of the outermost node? The statement works the same, as if I had just written:

e.hobby = "Running";

Which would do exactly that – create and append a new hobby node to the outermost node and set its text value to “Running”. But the two lists aren’t identical in the original document:

trace(e..hobby.length()); // traces 1
trace(e.hobby.length()); // traces 0

But again, assignment to xml (and xmllists) does not really have to do with the last part of the assignment target but the penultimate. And again, adding an extra level to reach the text node(s) works:

e..hobby.* = "Running"; // no error, and this time updated as expected

Why the previous statement seemed to ignore the descendant-part of the statement, I’m not really sure. Could be a bug, could be a loop-hole, but it definitely does not make sense.

There are many other ways to reach the same list of the single hobby node when simply consuming, but they cannot all be used in the same way when updating:

e..*.hobby = "Running"; // throws the same Error #1089 about more-than-one element lists
e..*.hobby.* = "Running"; // and it works again
 
e.descendants().hobby = "Running"; // throws the same Error #1089 about more-than-one element lists
e.descendants().hobby.* = "Running"; // and it works again
 
e.descendants('hobby') = "Running"; // compile-time error
// the parser simply does not allow assigning to a function invocation
e.descendants('hobby').* = "Running"; // and it works again
 
e..*.(localName()=='hobby') = "Running"; // compile-time error
// the parser simply does not allow assigning to (what looks like) a function invocation
e..*.(localName()=='hobby').* = "Running"; // and it works again

Conclusion

Be aware that assignments to XMLLists does not care about the last list – it is the second-to-last list, that must contain only one value. Internally, a statement like:

expression.property = value;

Is not a new thing at all, but it is handled in a new, special way, when expression has a value of either XML or XMLList. Thus, if you either get compile-time errors, runtime-errors or nodes appended in completely wrong places, just add extra level of element traversal with the wildcard-identifier .* to reach the text node of the single node you want to update.

No related posts.

As promised, the code has been uploaded to Bitbucket. Please enjoy and by all means request access if necessary. Please refer to the new project page here for details.

Related posts:

1. Announcing MXHR4AS3: Multipart/mixed-file download by Flash clients

Introduction

I have implemented the MXHR client to be able to use multiple concurrent http-streams to load the files even faster. This is done in order to make sure that the MXHR client can have the same advantage as conventional downloading, where concurrent streams perform better than simple queued streams.

The MXHR client is implemented pretty straight-forward in AS3 with 3 simple classes – MXHR, MXHRFile and MXHREvent. The serverside implementation, that I choose, was in PHP, and since the folks at Digg did not provide one such sample implementation, I did my own. It is done in PHP 5 through a single class MXHR taking file names and building a aggregated response (in conformance with specifications of course) – and it supports caching.

Results

Some example download times by my tests:

Try it out for yourself here:

• Conventional single-threaded download
• Conventional multi-threaded download
• MXHR-based single-threaded download
• MXHR-based multi-threaded download

As you can see, when the files are cached there is almost no difference between MXHR-based single- or multi-threaded download. And both are significantly faster (both cached and uncached) compared to either type of conventional download.

Source

I will need to do a little bit of further testing and clean-up before I put the full source-code up for download, but when I do, it will be on Google Code Bitbucket under the site license.

Related posts:

1. MXHR4AS3 Released
2. Flash development and the practice of Scripted Layout
3. Using AddThis with Flash

The latter category includes e.g. the for-each-in construct, different number types, class introspection or built-in class look-up by string, but these are my top 6 AS3 features, that I find myself constantly missing when fixing or improving scripts in older versions of ActionScript:

Number 6: Default values for parameters

if (!scale) scale = 1;

It is very simple, it doesn’t really look nice (at least the first couple of times you read/write it), but it gets the job done and it is consistent with how other languages does it. If it is the best possible choice for implementation, I cannot really say, but I wouldn’t be without it now that I have it – though I can easily think of improvements.

Okay, you are going to ask anyway, so here it is: It can be greatly improved by adding the ability to add parameters by name like in Python – e.g.

ftp.connect(host="www.server.com",username="administrator",password=password_input.text);

It looks a bit strange but it is a great improvement – just compare it to how you need to specify the third (useCapture) and fourth (priority) arguments to addEventListener whenever you need to specify, that you want it to use weak references (the fifth argument set to true) – it does not look that good and could be a lot easier to use with named arguments.

Number 5: E4X

firstChild.firstChild.childNodes[i].lastChild.firstChild.attributes.id

XML-based configuration files have been around for ages. I have done banners back in Flash 5, that used external configuration files for texts, layout, flow, paths, connection properties or something similiar. Of course, back then you always loaded the ignoreWhite script (wasn’t it XMLNitro.as from Branden Hall?), but you still had to either create your own serialization schemes, load someone else’s or go through the staggering pain of navigating through the XML-node tree through simple node references without knowing their names in advance.

With E4X we have been equipped with XPath-like traversal schemes, that still allow for basic node traversal, but makes it infinitely much easier to reach that specific node, that you need and know the name (and maybe some of the path) of.

Number 4: Instantiate movieclips – even across SWF’s

No more duplicateMovieClip madness

I did a large isometric chat world in the good old Flash 5 days (and it only just recently got improved – which meant doubling the version number from Flash 5 to Flash 10 – now that is rare) and split code out in several FLA-files compiled to several SWF-files. But as everything needed to be possible to lay in-between each other all graphics needed to be in the same SWF-file. Which meant they had to come from the same FLA-file (unless we used swfmill or something similarly fancy, which were in their infancy back then). Everything had to be exportable from the library and as items in the library couldn’t really be linked to classes directly, all item script had to be placed on the timeline. Of course it was a big mess and already back then we were hoping for a better way of loading content from external files (did anyone ever find out how to utilize “shared libraries” for actual production value?).

And now we have this feature – it is so much better. Create a symbol in a library in any FLA-file, load the resulting SWF-file in your production and instantiate any symbol from it and attach it anywhere you like. Clean and beautiful and exactly what we needed back then – and when going back, you really get that feeling again.

Number 3: Error handling and run-time validation

When it doesn’t say anything, does that mean no error happened?

Imagine having put your AS2 production live, have it loaded in the browser and an error happens (because you visually can see that something is wrong) – how the h¤ll do you find out what happened? There were the old debugger, but it was crap – simply crap. You could only hope that you had enough trace’s spread around to debug based on your flashlog.txt file.

With AS3 we got run-time validation. If something is wrong, we (most of the time) get a huge ugly error popping out. It might look bad, might give bad user experience (if so, they ought to stop using the debug player though) but to the developer it gives the necessary feedback (thank you stack trace). And not to mention all the other advantages that run-time validation gives.

Number 2: Function scoping

I simply hate delegate.

When doing pseudo-OOP like in ActionScript 2 (or AS1 or JavaScript), you constantly need to bind your functions as methods of your class instances in order to be sure, that if passed by reference, they are invoked in the right place. In ActionScript 3, this is no longer necessary. Basically, when passing a reference to a method of a class to someone or somewhere else, the scope of the method (being the originating instance) remains intact:

var a:Sprite = new Sprite();
var b:Object = new Object();
var c:Sprite = new Sprite();
b.addChild = a.addChild;
b.addChild(c);
trace(a.numChildren); // traces "1"

Anyone using AS3 knows this by now, but this was just to re-iterate and give an example.

Actually, it is not function scoping. It is more about creating a clear distinction between functions and methods. Functions are anonymous and created inline and don’t really use a “this”-scope but a reference scope. Methods are attributes of classes and are always invoked on instances of the class.

It does remove some “scriptability” in ActionScript, as currying and similar tricks aren’t as useful anymore and actually you never use “normal” functions at all – only methods. But intelligent use of patterns can have the same effects as such minor tricks and though they require more typing, they produce cleaner and often more intelligent, re-usable code. But that is the target of a whole other discussion.

Number 1: The display-list instead of depths

myClip.getNextHighestDepthLowerThanTheDepthOfTheMenu()

Depth. The most annoying part of AS2. I didn’t realize it back then, you were so accustomed to writing foo.createEmptyMovieClip(“myclip”, foo.getNextHighestDepth()) and then swapDepths’ing it all around afterwards, but now that I don’t need it anymore but have to go back to using it – it is so time consuming.

At first, the display list sounded a bit scary to me and the very first demos of the language explaining MXML and layout schemes gave horrible flashbacks to the script-consuming “layout engine”, that Java and SWING employs. But most of us never use any of those layout schemes, simply add items to stage on coordinates with the display list being the best tool to ensure proper depth management. Thank you!

Please leave comments, if you have other features than you constantly find yourself missing, or in other ways believe you can improve this list. Oh, and if you have suggestions for other lists, then by all means add them here.

Related posts:

1. Minor change in handling NaN positions in Flash Player 10,0,22
2. Advanced E4X – Assignment to XMLLists

If the x- or y-attribute of a DisplayObject is set to NaN, in previous players this caused the attribute to be set to -107374182.4. In the latest player, the attribute is set to 0.

The value -107,374,182.4 is -2,147,483,648/20. Flash uses “twixels” for positions, which is a twentieth pixel. Thus the lowest possible value x or y can hold is -(2^31)/20 which is exactly -107,374,182.4. This means, that when rendering DisplayObjects with a position in either direction with a value of NaN, the position was instead rendered with the lowest possible value for this attribute previously, but now it is rendered with this attribute set to 0 instead.

Thus, it is not a bug per se, but it is a change in behavior in response to an error condition – namely bad positioning.

My test-page can be found here. Please try this page out and copy-paste the results in the comments, if you do not experience the same results as described above. The result in Flash Player 10,0,22(,87) on Mac is:

Player version: MAC 10,0,22,87
1 + undefined: NaN
typeof (1 + undefined): number
1 + (1 + undefined): NaN
typeof (1 + (1 + undefined)): number
sprite.x: 70
typeof sprite.x: number
sprite.x += undefined
sprite.x: 0 <--
typeof sprite.x: number

In the previous player 10,0,12(,36) the result was:

Player version: MAC 10,0,12,36
1 + undefined: NaN
typeof (1 + undefined): number
1 + (1 + undefined): NaN
typeof (1 + (1 + undefined)): number
sprite.x: 70
typeof sprite.x: number
sprite.x += undefined
sprite.x: -107374182.4 <--
typeof sprite.x: number

Note the second-to-last line – the value of x is different when “undefined” is added to the current value.

Some other test results from non-Mac versions as well as previous versions:

Player version: MAC 10,0,2,54
1 + undefined: NaN
typeof (1 + undefined): number
1 + (1 + undefined): NaN
typeof (1 + (1 + undefined)): number
sprite.x: 70
typeof sprite.x: number
sprite.x += undefined
sprite.x: -107374182.4
typeof sprite.x: number
 
Player version: MAC 9,0,159,0
1 + undefined: NaN
typeof (1 + undefined): number
1 + (1 + undefined): NaN
typeof (1 + (1 + undefined)): number
sprite.x: 70
typeof sprite.x: number
sprite.x += undefined
sprite.x: -107374182.4
typeof sprite.x: number
 
Player version: MAC 9,0,124,0
1 + undefined: NaN
typeof (1 + undefined): number
1 + (1 + undefined): NaN
typeof (1 + (1 + undefined)): number
sprite.x: 70
typeof sprite.x: number
sprite.x += undefined
sprite.x: -107374182.4
typeof sprite.x: number
 
Player version: WIN 10,0,22,87
1 + undefined: NaN
typeof (1 + undefined): number
1 + (1 + undefined): NaN
typeof (1 + (1 + undefined)): number
sprite.x: 70
typeof sprite.x: number
sprite.x += undefined
sprite.x: 0
typeof sprite.x: number

My very simple source FLA file is available here. The xtra info in the above is simply to make sure, that no other changes in handling NaN or undefined has happened.

Thanks to David Wulff, Anders Krarup and Katharina Berg for help in testing.

Update 4.07PM: It is actually mentioned in the release notes as: “Fix AS APIs’ inconsistent handling of NaN parameters on different platforms. (FP-612,FP- 903, FP-964/2200454)”. However, all these reports are about Windows installations only and they all mention, that all players before FP10 set the attribute to 0 and setting the attribute to -107374182.4 only happened in Flash Player 10,0,2 and 10,0,12 (and probably also the Linux-only 10,0,15). From my results however, it is clear that for Mac this issue has always been the case also in Flash Player 9, which is revealed in the comment about the fix as “inconsistent handling [...] on different platforms”.

It seems to be an actual desired result that this was “fixed” in order to bring the error condition handling back to the way it has always been in flash players for Windows in all previous versions before FP10.

Related posts:

1. Weird bitmap fill crash error in Flash CS4.
2. Using AddThis with Flash
3. Flash development and the practice of Scripted Layout

The for-in loop iterates over keys like this:

var items:Array = ["hi", "there", "bob"];
for (var index in items) {
	trace(index+" => "+items[index]); // traces "0 => hi", "1 => there" and "2 => bob"
}

The problem with this construct is, that it is actually meant to loop over properties of an object, not indexes of an array. This can be seen by the strange typing requirement – if I wanted to type the value of index in the above (which I really ought to), it must be typed as a String:

var items:Array = ["hi", "there", "bob"];
for (var index:String in items) {
	trace(index+" => "+items[index]); // traces "0 => hi", "1 => there" and "2 => bob"
}

If it was typed as a number, the compile-time validator would report an error:

1067: Implicit coercion of a value of type String to an unrelated type Number.

This makes the for-in loop quite flawed for array iteration.

The for-each-in loop however loops over values:

var items:Array = ["hi", "there", "bob"];
for each (var value:String in items) {
	trace(value); // traces "hi", "there" and "bob"
}
var numbers:Array = [2, 3, 5, 7];
for each (var prime:uint in numbers) {
	trace(prime); // traces 2, 3, 5 and 7
}

For these simple-valued arrays it might not seem like it matters, but what if we were working on an array of objects; maybe a list of XML nodes:

var books:XML = <books>
	<book>
		<author>John Smith</author>
		<title>The Book About Nothing</title>
	</book>
	<book>
		<author>Jane Doe</author>
		<title>The Book About Everything</title>
	</book>
</books>;
for each (var book:XML in books.book) {
	trace(book.author); // traces "John Smith" and "Jane Doe"
}

See how nice it is? There is however no compile-time validation of the type of the iterator variable (value in the above code), and this compiles just fine (but throws an error during execution):

for each (var book:Sprite in books.book) {
	trace(book); // this is never reached
}

But then comes the new Vector-type. Vector is generic, which means it can be typed to reflect the values:

var books:Vector.<XML> = new Vector.<XML>();
books.push(<book><author>John Smith</author><title>The Book About Nothing</title></book>);
books.push(<book><author>Jane Doe</author><title>The Book About Everything</title></book>);
for each (var book:XML in books) {
	trace(book.author); // will again correctly trace authors
}

I for one hoped, that this for-each-in loop would be type-checked at compile-time to verify, that my iterator variable had the same type as the elements of the Vector, but no, I can still change the type to e.g. Sprite and it compiles just fine (but of course still causes an error at execution). This is a clear weakness compared to the Java for-each loop, which does exactly that – checks the type of the iterator variable compared to the generic type of the iterable list.

One final note about the secret loop is, that the built-in editor in Flash CS4 does not highlight the word “each” as a keyword, which is quite strange. I can even use the word “each” as a variable name, which I clearly cannot with e.g. “while”, “for”, “function” or other reserved keywords. It seems like it is not a “real” keyword, just some extra word that can be appended to “for” and have a special meaning when present. Oh, and as can be seen here, the GeShi syntax highlighter doesn’t highlight it either ;) (UPDATE: Well, I if switched highlighting to AS3 it worked, so actually that was my own fault).

Nevertheless, for-each-in loops are a great asset and especially when working with XML and the new notation E4X for XML traversal.

Related posts:

1. Why events suck in ActionScript 3
2. Advanced E4X – Assignment to XMLLists

One of the main things, that I conceptually did in a different way on this site is, that I created tweens before I needed them. Actually, I created tween objects without even knowing what I wanted to tween at the time.

E.g. the “sound on/off” button (which unfortunately was removed just before launch) was implemented in a very simple way. On the class I kept a reference to a tween-object, and I created an instance for this as soon as the sound started playing (in continuous loop):

var background_music:Sound = new BackgroundMusic();
var sc:SoundChannel = background_music.play(0,100000); // to infinity and beyond
soundtween = new GTween(sc.soundTransform, 0.3);

In this way, I can simply make the sound start fading by changing the volume-attribute on the proxy object of the soundtween-property:

soundtween.proxy.volume = 0; // fade out

Though, as some might remember, you cannot simply change the volume-attribute directly on the soundTransform-property of your SoundChannel. You need to copy the SoundTransform instance to a local variable, change the volume and re-assign the soundTransform-property. However, GTween takes care of this in a very simple way:

soundtween.setAssignment(sc, "soundTransform");

This is not only useful for sounds but also for all the other transform objects like DisplayObject.transform.colorTransform, DisplayObject.transform.matrix and other objects that require re-assignment before having an effect.

I will furthermore in additional posts describe how I have used GTweenTimeline for rapid prototype development with very nice transitions.

No related posts.

This feature does currently not work – see list of updates below

ShareThis is a great service for adding shareability to your website in a very simple way. It even includes the “tip a friend” option, so you don’t need to code that for your own site. I will describe how to embed it from flash.

Note 2009/05/19: Due to changes in the ShareThis API popup-functionality is broken currently (both in my example and in some of my live projects). I have filed a bug with ShareThis to fix this ASAP.

Note 2009/05/21: ShareThis have now fixed the above bug but there is still a minor JavaScript error thrown. The popup works now though as it should from both JS and Flash.

Note 2009/06/08: ShareThis now broke it again. And this time their support staff doesn’t answer. Please see an example implemented with AddThis instead.

Note 2009/06/19: ShareThis finally fixed it again. They wrote a mail on the 17th to me stating the bug was reintroduced when they implemented CDN, but would be fixed in the next release. Let’s hope it stays that way.

Note 2009/08/14: ShareThis has recently implemented a brand new version of their service – and surprise: it is not backwards compatible. Thus my popup example is broken again. I will investigate and fix soon.

Note 2009/08/17: ShareThis has promised to deliver a flash API within a few weeks. Let’s see what happens then…

You can do that in two ways, either by using a overlay div in HTML or creating a popup (that might get blocked). The prettiest and most user friendly is of course the overlay, but in order to have HTML overlays on top of Flash elements, you need to set the Flash wmode to transparent. This has a strange and unfortunate side-effect (which has been bug-reported to Adobe), that the keyboard defaults to standard US layout. For US websites, this is not a big problem, but for a Danish website it matters a lot. There are many differences between US and DK keyboard layout including Danish special characters and the location of the @-sign. Thus, wmode-transparent cannot be used for Flash-objects having input fields requiring users to enter text (which could contain special characters) or an email address (which contains the @-sign). Thus we need to use the popup-solution.

First, simply go to sharethis.com publisher section and customize your widget. Instead of placing the widget code snippet where you want the button, put it in the <head>-section of your website. The code snippet I got was:

<script type="text/javascript" src="http://w.sharethis.com/button/sharethis.js#publisher=636e055b-a4a2-4f9c-872c-b7aa9a701bb0&amp;type=website&amp;send_services=email&amp;post_services=facebook%2Clinkedin%2Cmyspace%2Cdigg%2Cdelicious%2Ctwitter%2Creddit%2Ctechnorati%2Cwordpress%2Cblogger%2Cgoogle_bmarks%2Cwindows_live"></script>

Then create a little javascript function like:

  function share(url, title) {
    var s = SHARETHIS.addEntry({
      url: url,
      title: title
    }, {button:false,popup:true});
    s.popup()
    return false;
  }

Finally, simple call this function from Flash using ExternalInterface:

var url:String = "http://www.barklund.org/blog/2009/05/06/using-sharethis-with-flash/";
var title:String = "Barklund.org - Using ShareThis with Flash";
import flash.external.ExternalInterface;
ExternalInterface.call("share", url, title);

See an example here – the javascript function is invoked both from a regular HTML link and from a simple Flash file using just the above ActionScript.

Related posts:

1. Using AddThis with Flash
2. Minor change in handling NaN positions in Flash Player 10,0,22
3. Announcing MXHR4AS3: Multipart/mixed-file download by Flash clients

But Mario Klingemann’s presentation about reading QR codes in Flash was the most (technically) inspiring presentation in my opinion and I could immediately see a bunch of ways in which, I could use this for all different sorts of purposes – in real life advertising and not just for the fun of it. I really feel that I could join this project and make it into a complete library and so far I’ve written him a mail offering my help (and a minor possibility for optimization).

But credits also go to Grant Skinner, as his talk on important things to learn as a new web developer (in Flash in particular) gave me some good inspiration for my own job as head of development with developers of my own needing help and guidelines.

Related posts:

1. Flash development and the practice of Scripted Layout
2. Weird bitmap fill crash error in Flash CS4.