Peter Hall's Flash MX blog. Regularly updated Flash community news and insights into development with Macromedia Flash MX.

This page is powered by Blogger. Isn't yours?
Wednesday, December 12, 2007

new as3-xpath build 0.2.4 released

We just released a new build of the XPath library. It's just a couple of small bugfixes, and tweaks, but if you are using it already, you might like to update to the latest 0.2.4 release.

Tuesday, December 11, 2007

mxml syntax proposal for styles and events

Don't you think it's a bit funky that you set styles in exactly the same way that you set a property in MXML? And isn't it a bit confusing that you add an event listener in exactly the same way too? Actually, it's not that confusing. It's pretty cool and works quite nicely - I couldn't really see a better way. Except, I'd like to tweak it a little bit...

The first problem is, you can't have a style or an event named the same as a public property, if the object is going to be used in MXML. The other problem is that, when you look at some MXML code, and you see various attributes being set, you can't immediately tell if it's setting a property, listening for an event or setting a style. Events listeners are nearly always added in-line, and there are quite a few cases where it is better practice to use in-line styles instead of CSS (ask me after class). So, all in all, it's not a rare consideration. A third problem isn't so important to you and me, but the developers who create MXML editors would be able to simplify some of their code if they could depend on a namespace instead of having to figure out if a given attribute represents a property, style or event.

My suggestion is a very small change to what we have already. Adobe should simply define a namespace for events and another for styles. The Flex compiler does something completely different with each of these, so the namespaces should help Adobe to simplify their own code too.

Here's an example of what it might look like:

  <mx:VBox style:verticalGap="3">
     <mx:Button event:click="onClick(event)" />
  </mx:VBox>

The extra namespaces would have to be declared at the top of every MXML file that used them, but that is not a big deal if that is mostly generated by a decent editor.

I made a bug report for this a while back, but never thought about it again. So feel welcome to vote for it if you agree that it's a good idea. Also on the report, I suggested how the same feature could be extended to allow some interesting custom extensions to MXML, by handling attributes in custom namespaces.

Saturday, November 10, 2007

Getting Started with EcmaScript 4

John Resig posted a nice video, showing how to get the ES4 Reference Implementation up and running. The Reference Implemenation is an in-progress implementation of the next generation language, based on the current proposals. In the future, both ActionScript and JavaScript will implement this specification.

In the video, John doesn't show much of ES4 that we don't already have in AS3, but he shows how to get the engine running and how to run code with it. You can find more information about the new features in the language overview whitepaper, or on the rest of the EcmaScript site.

In recent weeks, the guys involved with ES4 have made huge leaps in making this available to the "masses". In particular, Dave Herman made binaries for Windows available for the first time. Previously, the step of having to compile and run the source code with cygwin might have been slightly too high a barrier for most. I was very impressed by the speed with which this was done, once the demand was known.

Wednesday, October 24, 2007

Memorphic is hiring

We have a couple of vacancies opening up in our South African office. The job is in Stellenbosch, but will probably move to Cape Town early next year. More information here.

Tuesday, July 24, 2007

How to really hide a component in Flex

Ok, so it sounds obvious: myComponent.visible = false;. But actually this doesn't do everything you might want it to. If the parent is a VBox or an HBox then there will be a gap, where the component should be. You can set its height to zero, but then there is still the verticalGap or horizontalGap to worry about.

You can get around that still, by using getStyle and subtracting the gap. But this is starting to get ugly. Another options is to remove the child altogether, which is fine in many circumstances, but can get screwed up if other children are being added and removed.

The solution I found is to use the includeInLayout property, in combination with visible. Setting includeInLayout to false means that the layout engine will not leave gaps or spaces around the component, but it will still be drawn if you don't set visible to false too. Here's an example with states:

<?xml version="1.0" encoding="utf-8"?> 
<mx:Application 
     xmlns:mx="http://www.adobe.com/2006/mxml" 
     layout="vertical">
 
     <mx:states> 
          <mx:State name="hideText"> 
          <mx:SetProperty target="{myText}" 
          name="includeInLayout" value="false" /> 
               <mx:SetProperty target="{myText}" 
                    name="visible" value="false" /> 
          </mx:State>
     </mx:states>
      
      
     <mx:Button label="hide text" 
          click="currentState = 'hideText'" />
     <mx:Text id="myText" text="hello, this text will 
     be hidden or shown, depending on the buttons" />
     <mx:Button label="show text" 
          click="currentState = ''" />
</mx:Application>

Easy!

Btw if you are wondering why I'm not blogging much these days, I've been working on building a development company in UK and South Africa. Memorphic has been growing nicely over the last year, in numbers and in the skills of our developers. So, let's just say I've been busy!

Wednesday, June 28, 2006

exciting times

Sometimes, a picture just captures a moment in history.

Monday, May 15, 2006

AS3: loading external data at compile-time

Sometimes it's useful to load data into your application from a file, without having to load it at runtime. If you need to do that, here's how.

  [Embed(source="data.xml", mimeType="application/octet-stream")]
    private static const MyData:Class;

  private function init():void{
    var ba:ByteArray = new MyData() as ByteArray;
    var myString:String = ba.readUTFBytes(ba.length);
    trace(myString);
  }

It would be nice if you could set the content type to text/plain or text/xml, and get something a bit less raw than a ByteArray, but it's still nice that we can do this.

Since the data is available from compile-time, you can even use it as the value for a constant:

  [Embed(source="data.txt",mimeType="application/octet-stream")]
  private static const MyData:Class;

  public static const MY_CONST:String = setConst();

  private static function setConst():String{
    var ba:ByteArray = new MyData() as ByteArray;
    return ba.readUTFBytes(ba.length);
  }