Archive for the ‘Flex’ Category.

Flex4.6 mobile maxChars bug/problem and workaround

Bug-note to self, and workaround while waiting for the bug-base to migrate from Adobe to Apache.

I’m using in a Flex 4.6 mobile project and found that setting the maxChars property to 512 caused exeption:

Main Thread (Suspended: ArgumentError: Error #2006: The supplied index is out of bounds.)
flash.text::StageText/set viewPort [no source]

However setting maxChars to something much smaller (e.g. 10) was fine. From experimentation, seems that the biggest number to which maxChars could be set without causing the problem was 481. I have no idea what that number relates to. Anyway the database field my TextInput corresponds to is 512 chars max so that’s the number I need.

The workaround:

Setting maxWidth on the TextInput seems to solve the problem. But rather than insert a constant I want the TextInput to flex to the width of it’s container, so the following seems to avoid the problem:


id        ="textInputId"
maxWidth  ="{skinableContainerId.width}"
maxChars  ="512" />


The future of Flex :

Flex 4 Spark VideoDisplay (measure, overlay, skin)

In a previous article I described some of the steps required in Flex 3 in order to keep an overlay position in sync with a VideoDisplay component. With the release of Flex 4, VideoDisplay is one of the components to be updated. Via VideoPlayer, it gets a Spark makeover. Internally its core, or ‘view’, has been reimplemented using Open Source Media Framework. For anyone wishing to keep an overlay in position over the view, however, the same key issue remains:

None of the various width or height properties of the VideoDisplay component describe the width or height of the contained view.

So, to get the properties of the view we need to delve deeper into VideoDisplay and use the mx_internal namespace. Even then, the ResizeEvent.RESIZE event is broadcast by VideoDisplay before it’s view dimensions (column B) have been updated to the new site.

In that previous article I observed that if, after each resize, I added an Event.EXIT_FRAME listener, I could guarantee that the VideoDisplay’s view had been sized by the time it was called. I observed that the same is true in Flex 4. However EXIT_FRAME didn’t feel like the right place to be doing this. So with a closer look at the component life cycle we can see that handling the FlexEvent.UPDATE_COMPLETE event is more appropriate. Column C shows the view’s width/height after UPDATE_COMPLETE has been broadcast. It colours red when a value  disagrees with column B (RESIZE). And so, it is column C that contains the values we want to use while managing our overlay.

Sample 1 : Comparing width/height after resize, then updateComplete

Using this information and Flex 4’s new component and skinning architecture, we can build quick and simple to use video overlay component rather than messing about with external listeners and calculating positions as we did in the previous Flex 3 examples.

Reviewing what Flex 4 includes ‘out of the box’…

  • VideoDisplay : a non-skinable component that wraps an osmf ‘view’. It translates much of the osmf api and events to what we are accustomed to with Flex 3.
  • VideoPlayer : A skinable component provides hooks for skin parts. A required part is an instance of VideoDisplay. The others are the buttons and controls we’d normally expect when giving the user control of the video.

The VideoPlayer and it’s skin are overkill for this example, so we’ll create something far simpler…

  • VideoDisplayOverlayContainer : A container component who’s children will overlay a VideoDisplay
  • VideoDisplayOverlayContainerSkin : A simple skin, providing the required videoDisplay skin part.

This way, overlaying the video is as simple as giving the container some child components and a layout (defaults to basic layout). In the example that follows we overlay a label instance to each of the four corners and the centre of the view…

    id     ="videoDisplayContainer"
    source ="VideoSampleForFlex.mp4"
    width  ="100%"
    height ="100%" 	>
    <s:Label text="A" top="2" left="2" backgroundColor="0xffffff" backgroundAlpha="0.4" />
    <s:Label text="B" top="2" right="2" backgroundColor="0xffffff" backgroundAlpha="0.4"  />
    <s:Label text="C" bottom="2" left="2" backgroundColor="0xffffff" backgroundAlpha="0.4"  />
    <s:Label text="D" bottom="2" right="2" backgroundColor="0xffffff" backgroundAlpha="0.4"  />
    <s:Label text="O" verticalCenter="0" horizontalCenter="0" backgroundColor="0xffffff" backgroundAlpha="0.4"  />

Sample 2 : Overlay container component

View source

Flex builder 4 help system (CHC) and backups

(Edit: Of course this should have been titled Flash Builder 4)

One of the changes with Flash builder over previous Flex Builder products is in the help system. The help files are no-longer bundled and indexed by eclipse help. Instead a new help application is installed which attempts to combine the documentation with community content.

I must admit to not receiving this application particularly well in the first instance. However I have seen it develop over a number of weeks and as an AIR application it is expected to continue to develop independently of major product release cycles.

Since it is a new product, some rough edges can be expected. There is already a technote (cpsid_83103) relating to getting context-sensitive help working correctly in a fresh install of Flash Builder 4.

Randy Nielsen’s post on using the help client provides a good orientation for new users.

However I think there are some other things that system administrators at least (and users who backup their user-directories – particularly to the cloud) should be aware of…

1. The many names of adobe help

On a Mac it installs application “Adobe Help” into /Applications/Adobe. The main application window when running is titled “Adobe Community Help”. And you will see this application widely referred to in Adobe communications as CHC or Adobe Community Help Client. If you ever look for the preferences files for the application, you’ll find them in ~/Library/preferences/chc.xxxx.1 (where xxxx is a 40 digit hex number). Note: missing is the usual “com.adobe.” prefix.

2. Downloading the help files.

The help files need to be downloaded to your local system in order for the application to work. The current version of the application ( only displays local content if the network is not available. Otherwise it always displays content from the web. This seems slightly wasteful and slow. Though we can expect an option to default to local content irrespective of network connectivity in future versions.

3. Help file size

You can manually control the downloads via Preferences>Updater settings then  “Manage now”. This will show a table of help files, whether they are current or not and their size. The size however is slightly misleading. It refers to the zip file size and therefore the network bandwidth required to download the help package. Once unzipped however, the disk-space used is a considerably larger number. I find that the help packages for Fb4 and associated stuff expand to use 563Mb.

4. Where the help files are stored

On a mac the help files are expanded and stored in the user’s preferences folder. ~/Library/Preferences/chc.xxxx.1/Local Store/Help

To me this is not the right place to be storing such content. Help content is not preferences and is not necessary ‘per user’. Preferences are usually backed up. There is absolutely no need to be backing up this content – to do so is a waste of storage, network bandwidth and machine time. Once all Adobe products are integrated with CHC, the help folder will be considerably larger than my current 563Mb.

In summary

Adobe Help, Adobe Community Help Client (CHC), is currently in its infancy as an application, but will be soon in the hands of many, many users. As an AIR application, the development team have far more flexibility to make releases between major product cycles. I hope and believe that the points I highlight (and location of help files in particular) will be addressed in coming releases – they have all been submitted to the team – not just blogged here. However they are blogged here because I think storage suppliers could be in for a field day unless sys-admins are made aware, and add rules to their backup process to omit the help files.

Flex 4 and Flash builder 4 final, finally released

It’s been a long time coming, but looks worth the wait. Lots of improvements and a fundamental change (enhancement) to the skinning components in the form of Spark. Although Flash Catalyst isn’t released yet, there’s still scope to get to grips with the developer side of the Spark skinning architecture in the meantime.

Although the charting components have now been open-sourced, i.e. you don’t need the professional licence to access them, significant differences make the premium version vital for heavy development e.g. Performance profiler, Memory profiler and network monitor. For more detail check the Flex version comparison chart.

Andrew Shorten’s post on the Official Flex Team Blog is a good start point for getting into this release.

my first Flex 4 spark : component + skin = ResizeableTitleWindow

With Flex 4 having been in beta for ages and hopefully soon to be released, it really was time I started to get my head around the spark components and how to approach to skinning them. Rather starting off with the usual button, I thought I’d kick off with getting a ResizeableTitleWindow going. Of course a few others have already created variants. I think everyone using Flex at some point needs a resizeable version of TitleWindow. To that end, looking at the TitleWindow specification page of the Flex 4 wiki, clearly Adobe planned on implementing resize behaviour on the TitleWindow. It doesn’t seem to be implemented yet. So in the meantime my version is as close as I think I can get to that specification.

The end result (view source enabled):

My 1st spark skin

In the running example above, window ‘A’ is a normal instance of spark.components.TitleWindow. This leads me to my first spark skin. If you are viewing on a windows or linux platform it won’t look any different from normal. In that case it is simply using spark.skins.spark.TitleWindowSkin. However if you are viewing on a Mac you’ll notice that the close button is located at the left of the title bar rather than the right. This is where a Mac user will expect it to be – but the default in Flex is currently to the right, no matter what platform. This was achieved through the most basic technique of skinning a spark component : clone an existing skin, adapt it and apply it. To that end, spark.skins.spark.TitleWindowSkin was cloned to creacog.spark.skins.TitleWindowMacSkin, and a couple of lines changed swap around the closeButton and title. We switch skins if we are on the mac platform by loading the compiled Mac style sheet in the preinitialize handler of main.mxml.

This technique of cloning is one thing that initially feels slightly wrong with spark. It leads to a lot of duplicate code which is something developers normally do their best to avoid. The reasoning seems mainly to facilitate Flash Catalyst workflow, where skins are predominantly the domain of interaction designers for whom duplication is the norm and code re-use doesn’t really figure. However until and unless Flash Catalyst matures into a product that can support round-trip editing, there’s a good chance that developers will be making a lot of use of diff tools and duplicate code across skins is something we’ll probably just get used to. The subject has been discussed in detail in a number of other blogs and their comments:

Implementing and skinning ResizeableTitleWindow

We now need to know a little more about the mechanics of spark skinning. I must admit having previously read some blogs and watched some video posts of how simple spark skinning is – and I got it until sitting in-front of an empty editor scratching my head – where to begin? The key thing that crystallised it for me was to read the skinning contract.

So, first was to create the component class. This extends spark.components.TitleWindow. It adds a new optional skin part of resizeHandle of type UIComponent. Essentially we need something the user can click on no matter what it’s appearance. was created extending with the new event constants for resizing. Using the creacog package is the main deviation from the specification – for obvious reasons.

Catalyst was used to create the ResizeHandleSkin. A simple custom component with two states: up and over. It has a semi-transparent white background that transitions it’s alpha on mouse over. Importing ResizeHandle.fxpl into the flex project resulted in slightly odd packaging. Simply moving ResizeHandle.mxml to the creacog.spark.skins package brought it into structure consistent with the rest of the project.

spark.skins.spark.TitleWindowSkin was again cloned, this time to creacog.spark.skins.ResizeableTitleWindowSkin. To that 3 new lines is all that was required to add an instance of the resizeHandle skin part – positioned front-most and at the bottom right corner. It could be any size and positioned anywhere, but the logic behind resize adjusts the width and height of the component, leaving it’s x and y untouched.

creacog.spark.skins.ResizeableTitleWindowMacSkin is a further clone, this time with the closeButton skin part positioned to the left for mac users.

Finally we use styles (being careful of  the new namespace syntax) to the  notify the flex framework to use creacog.spark.skins.ResizeableTitleWindowSkin (and substitute creacog.spark.skins.ResizeableTitleWindowMacSkin on the Mac) whenever a ResizeableTitleWindow instance is drawn. If we omitted this step, the ResizeableTitleWindow instance would be created, but it would fall back to using the TitleWindowSkin which does not include the resizeHandle skin part and therefore the resizing functionality would be ignored.

Summing up

This new approach to skinning components feels far superior to what we have been used to in Flex 3. I’m slightly scared that the workflow from designer  via catalyst could result in inflexible skins (at least in the short term), as post-production work is required of the developer if the skin is intended to take on runtime styling for example. Lack of any sign of round-trip capability means skin production is currently one way from catalyst. i.e. tweaks or changes within catalyst will create a new output and it will be for the developer to merge the changes with additions s/he may have implemented on previous skins.

Looking forward to getting going on some real flex 4 projects.

to learn more about Flash Player internals

Being of a Computer Science background I think it useful if not important that developers have some understanding of what’s going on behind the scenes. It can be a real time saver in choosing the right approach in solving a particular problem. In the Flex framework for example, we have full access to the source code via the open source SDK. However for some decisions it is handy to know the low level implementation. The Flash Player tends to be something a black-box with our knowledge constrained to the documentation which largely covers the ‘what’ is available — but only at a high level ever covers the ‘why’ or ‘how’.

To that end it is especially good to see Tinic Uro finding enough time to blog more frequently recently particularly with the changes for Flash Player 10.1. Tinic’s blog is essential reading for any Flash developer. The two most recent posts:

flash in the pan

So, Flash player 10.1 is available in beta and includes mobile device oriented new features such as multi-touch gestures. Smart! Makes sense with Adobe strategy of delivering to emerging mobile devices. However there are a few million of us already using desktops and laptops with track pads, mouse wheels and mouse trac-balls who are feeling a bit ‘inhibited’. Flash is being used more and more to deliver applications either via browser or the AIR runtime. Such applications immediately feel somewhat inferior when a user cannot scroll or pan a view as they normally would native applications. Arguably ‘Rubbish’ rather than ‘Rich’ RIA in such cases.

For a long time the MOUSE_WHEEL event has been part of the Flash API but only officially supported on the Windows platform (in browser). Original reasoning for not implementing support for the Mac platform can no-longer be argued as all Macs for a number of years have been shipped with the Mighty Mouse (2005) and now Magic Mouse or Trackpads. All of which facilitate mousewheel style interactions. All of which go further and support horizontal as well as vertical scrolling interactions or ‘panning‘. There are JavaScript workarounds for in-browser Flash on a Mac such as this solution on or this SWFObject based pixelbreaker solution. Fortunately Flash applications delivered via the AIR runtime can respond to MOUSE_WHEEL events without any such workarounds. However MOUSE_WHEEL currently only facilitates vertical scrolling in any case.

We need to facilitate horizontal as well as vertical scrolling (panning) of content in response to events from ubiquitous input devices.

A few prominent applications I use often, which suffer:

  • TweetDeck : AIR based. High discoverability of lack of horizontal scrolling support
  • Adobe online store UK : In browser Flex application – Flash being used in an attempt to emulate HTML – no vertical scroll wheel support for Mac users
  • Adobe Flash builder : Design view (Java application with Flash based view)
  • Adobe Catalyst : Art-board view (Java application with Flash based view)

Adobe actively invite comment and suggestions on their products. More widely/easily through the Feature request/bug report form. They have opened up the bug tracking system for a number of products. Flash player being one of them. There is an active bug report with regard to this issue and I would encourage anyone with an opinion to contribute to the discussion and/or add weight by voting. Just sign up and access FP-1262. There is an active drive from within Adobe to help from the community to improve the quality of Flash Player and AIR.

As for the solution I think I’d like to see something along the lines of… Extending the flash.display.InteractiveObject with a ‘panEnabled‘ boolean property defaulted to false which, when true, allows the object’s Panning behaviour/event broadcasting (akin to doubleClickEnabled mechanism). So, when panEnabled is true, if the mouse pointer is over the InteractiveObject, and the user makes a ‘pan’ gesture, the frontmost panEnabled InteractiveObject broadcasts events containing with the additional properties : offsetX and offsetY. Text based InteractiveObjects should default to panEnabled = true. Further, I’d quite like to see mechanisms to facilitate behaviours of nested pan-able objects. E.g. on a Mac, the front-most display object gets scrolled until it can scroll no further, then if the user continues the scroll input, the containing display object then scrolls.

In rounding up, the best place to contribute your opinions on this subject and have them heard by Adobe is here : FP-1262.

Editor bug in Mac OS X 10.6.1

UPDATE 22 June 2010 : Further to my even earlier bug report (FB-9398FlashApe has posted a work around by changing a Snow Leopard system preference.

UPDATE 10-Dec-2009: I’m pretty convinced now that this is an editor bug, not a Mac OS X bug. Essentially the editors are using default OS behaviour which I think is tailored for natural language editing rather than programme-code editing. Original post follows…

I’m currently finding in some applications that “word1.word2.word3” is being treated as a single word as far as the Option-Left Arrow and Option-Right Arrow is concerned on my Mac. This keyboard shortcut should hop word by word. But currently hops from one end to the other. Not an issue for most users, but pretty serious for a programmer working with dot-notation syntax.

I first experienced this working with ActionScript in Adobe’s Flash Builder Beta 2 and logged a bug report, but further investigation reveals that some unrelated applications show the same behaviour. I have now logged a bug with Apple, but in the meantime I would be interested to know if others are experiencing the same? Or if you are running 10.6.1 and not seeing this issue? Please add a comment – I’m still trying to work out if it is something installed on my system. I don’t think it is basic user preferences as I am seeing the same in another user-account on this system.

Editors incorrectly treating “word1.word2.word3” as a single word re opt-left and opt-right:

FlexBuilder 3 MXML and AS editors
FlashBuilder 4 Beta2 MXML and AS editors
Apple Mail
Apple OS textfields including:
Finder window findfield
Safari: form-textfields + google search field
editors with *correct* opt-left opt-right behaviour
Adobe Flash CS4 IDE ActionScript Editor
Adobe DreamWeaver CS4 editor
Apple XCode editor
Apple Finder – filename clicked and editable when renaming
Firefox form-textfields and goodle search field
  • FlexBuilder 3 MXML and AS editors
  • FlashBuilder 4 Beta2 MXML and AS editors
  • Apple Mail
  • Apple OS TextFields including:
  • Spotlight
  • Finder window find-file
  • Safari: form-textfields & google search field

Editors showing correct opt-left opt-right behaviour:

  • TextWrangler
  • Adobe Flash CS4 IDE ActionScript Editor
  • Adobe DreamWeaver CS4 editor
  • Apple XCode editor
  • Apple Finder – filename clicked and editable when renaming
  • Firefox form-textfields and goodle search field

overlaying VideoDisplay with constrained fluid layout

UPDATE 28 April 2010 : This subject is revisited in relation to Flex 4 spark components, here.

The problem: In Flex, how to overlay the video with something (e.g. a logo or caption) and keep the overlay relative to a corner of the actual video rectangle. Sounds like it should be a simple matter of creating a container and layering in the VideoDisplay instance and the over lay instance ? But…

In each of the following samples:

Video Display overlay Sample 1

In our first sample we simply place our overlay image using attributes ‘top’ and ‘right’ to keep the overlay’s top-right corner to 10px in from the VideoDisplay top-right corner.


It basically looks fine until you hit the play button and start resizing the panel.

View source

As you can see the actual video within the VideoDisplay is constrained by its rectangle and depending on the differing aspect ratios, there will either be black space at the sides or the top, and our overlay is faithfully anchored to top right corner of the VideoDisplay and looks odd unless the aspect ratios are equal.

So how to solve this?

Looking at the documentation for VideoDisplay, there are many width and height properties to play with, however none of these relate to the current width and height or position of the contained video rectangle. You might think while looking at the documentation that the videoWidth and videoHeight properties might give the values we are after, but not so. They only return the ‘original’ width and height of the loaded video.

Fortunately the OpenSource nature of the Flex SDK and the magic of, holding the command key on a Mac (control key on a PC) with the cursor over  the <mx:VideoDisplay> opening tag, then clicking it as it underlines,  (using in Flash Builder  or Flex Builder) will open the source for the VideoDisplay component within a new editor. Browsing through the code you will see at line 198:
mx_internal var videoPlayer:VideoPlayer = null;

It is this videoPlayer instance who’s properties we need to monitor to calculate our overlay’s position. The instance is not generally exposed through the VideoDisplay component’s api. Nor is it documented. However since it has been placed in the mx_internal name space, we can actually access it with namespace notation…


Where we replace ‘attribute’ with the property name we are after, so the following would be of use to us…


Video Display overlay Sample 2

In this second sample, we create a positionOverlay method and call it from the resize event of the VideoDisplay component. Within positionOverlay we use the name space notation to get the videoPlayer properties and use some basic maths to reposition our overlay based on the top-right corner of the videoPlayer instance rather than the videoDisplay instance.


Additionally we call positionOverlay from our applicationComplete handler to set the initial position.

View source

This basically seems ok, but play with it for a while and it is clear that something is wrong…

  • Resizing slowly, seems ok
  • Resizing quickly, and there seems to be some lag in the position of the overlay
  • Release the resize handle while resizing quickly and the overlay can be left behind in completely the wrong place

Having traced the videoPlayer instance properties from within the positionOverlay handler, it is apparent that while the videoDisplay properties are correct, the videoPlayer properties are as they were previously. i.e. as they were rather than as they shall be.

Video Display overlay Sample 3 – This one works properly!

This is where Player version 10 comes in. It added Event.EXIT_FRAME. (If your project targets a player older than 10, you will not see this event in your code assist.) If we use the exit frame event to defer the call to overlayPosition, we can then get measured values from videoPlayer and correctly position the overlay.

To do this I have created a new method positionOverlayOnExitFrame who’s job is to add an EXIT_FRAME listener who’s handler will be overlayPosition. The first job of which is to remove the listener, so that it only gets called once. By using a listener we need to change the interface of overlayPosition to accept an Event argument. But we are not interested in the event information and we still wish to call positionOverlay directly, so we have allowed the argument to have a null default.


Playing with the resize handle now, no-matter how quickly it is moved, shows no lag, and always drops in the correct place.

View source

Finally, just to re-iterate, source code zip for these examples is here.

Note: These samples were built against Flex SDK version 3.4.

Note: I haven’t found any official documentation relating to when Event.EXIT_FRAME arrived in the player runtime. The Flash CS4 documentation for Event.EXIT_FRAME indicates player 9. However unless you target player 10 in Flex/Flash Builder, you will get compile errors. If anyone has accurate references, please post to the comments – thanks.

Note: When you look at the source view, it appears ragged. This is because in creating the HTML, Flash builder simply converts tab characters to four space characters. Clearly not every tab in my code actually represents 4 characters and therefore what should look like neat columns becomes ragged. I have filed a bug/enhancement request. If you too would like this fixed, feel free to add your vote to FB-23060.

finding information on Flex 3 component lifecycle

Quickly creating re-usable components based on others, augmented with additional ActionScript behaviour using MXML is as simple as can be. However, to create a component from scratch using ActionScript requires a lot of detailed knowledge of how the Flex framework works and the component life-cycle in particular.

The Flex documentation attempts to describe the lifecycle, but can leave the developer with lots of unanswered questions. When I got more involved in developing components I found chapter 19 of Programming Flex 3 good for filling in the gaps.

This week a new and free paper has been published by DevelopmentArc that also explores the component life-cycle and the application life-cycle. A very well worth while read….

Understanding the Adobe Flex® 3 Component and Framework Lifecycle

Feel free to post links to other compent lifecycle resrouces in the comments.