The entire OLAP package in Flex has sparse API documentation, but there are several ‘how-to’ examples out in the land of live-docs. This usually doesn’t bode well, because it generally means a tech-writer never talked to the development team to figure out what all the dependencies are on the various properties. We have the source, but chasing it down ourselves sucks.


A precursor into what doesn’t work:

  • OLAPAttribute.displayName does NOT work on subsequent dimensions. It will only work on your first dimension which is usually the ROW_AXIS. However, the OLAPLevel.attributeName will always expect to look up the OLAPAttribute.name.
  • The allMemberName even though it’s defined on the OLAPHierarchy, it must be actually set on an OLAPAttribute which is displayed for that dimension.

Now onto the real problem:

Generally to sort your cube, you do a 2-dimensional sort to the original flat dataprovider then assign this to the cube dataprovider.  And in most cases this seems to work OK, until your CATEGORY_AXIS is based on anything to do with Time (which is a lot of the time actually). In most cases you’ll have a two-tier hierarchy of year and month / quarter, but the problem appears to be most prevalent with months. Even though your original source is sorted correctly, some months will be placed out of order, especially if you’re using the allMember level which it builds on the fly in the query.

The Fix:

So the fix involves re-arranging the member IList in building the OLAPQuery to the appropriate OLAPSet. In addition to fixing the sort issue, now is the time to re-arrange the allMember level to where it seems logical for your application. Accounting applications generally read left-to-right, so summary total’s are generally shown on the right hand side.

The way know if you’re working with the allMember level that it created for you in the sort method, is to look for the OLAPMember.hierarchy.allMemberName and compare that to the current OLAPMember.name

The way to correctly resort months involves a bit of kludgery but I haven’t found a more elegant way around it. In the OLAPAttribute for the dimension you specify the dataField to the integer of the month (generally this is string from a formatter), and assign a displayNameFunction to use a DateFormatter to turn this into something meaningful at the UI level. Even though the name of the OLAPMember is a string, it’s actually a string cast of the original value to the dataField (hence the actual integer value). You can then re-cast this back to an int to do a numeric sort (so you don’t end up with 0, 1, 10, 11, 2, 3, etc).

Now you might think an easier way to do this is to just use a SortField, however since you’re original Object is transformed to a flash_proxy and lost in the process relative to the OLAPGrid, the internal numeric sort method to Sort will throw an error that it can’t find the property that you originally wanted to sort on (eg month).

This should get your columns back in the order in which they were meant to be in.

private function getQuery(cube:IOLAPCube):IOLAPQuery
… //Setup the rest of the dimensions / sets to associate to the correct axis

var list:ArrayCollection = cube.findDimension(“timeDimension”).findAttribute(“Month”).members as ArrayCollection;
list.sort = new Sort();
list.sort.compareFunction = compareSortMonth;

var moSet:OLAPSet = new OLAPSet();

private function compareSortMonth(a:OLAPMember, b:OLAPMember, fields:Array = null):int
if (a.name == a.hierarchy.allMemberName) return 1;
else if (b.name == b.hierarchy.allMemberName) return -1;

var aMonth:int = parseInt(a.name);
var bMonth:int = parseInt(b.name);

if (aMonth < bMonth) return -1;
else if (bMonth < aMonth) return 1;
else return 0;

Look Ma! Adobe finally did it. Flash Player 11.4, AIR 3.4 multi-threading. Let the thread-locking games begin!


I updated Quicken because I was forced to, and we all loathe Quicken in one fashion or another, generally those of us in UI seriously need a job there. It would take months if not years to re-do this thing right, but then again what is their incentive? It’s a cash cow, no updates / improvements / bug-fixes, but everyone has to keep pony’ing up every 3rd year.

So I came across this one, in using it. OMG, what a retarded warning, so much so it will just make an JR / BASIC / ENTRY-LEVEL / etc, programmer laugh, and the rest of us to just cringe.

This one has been bugging me, and a few other people who were trying to figure out ultimately what version of SQLite is embedded in AIR. Running a SQLStatement of: ‘SELECT sqlite_source_id()’ gives us this result: onSQLresult result key sqlite_source_id() value 2010-12-07 20:14:09 a586a4deeb25330037a49df295b36aaf624d0f45.

As per SQLite.org this method returns the code characteristic for which your embedded version has been built against. Using the canonical timeline viewer, going back a few pages now of (200 entries) we find this one:

And low-and-behold down near the bottom: 2010-12-07 20:14 [a586a4deeb] Version 3.7.4 (user: drh, tags: trunk, release, version-3.7.4)


So it turns out, that the modified version of AIR 3.1 SQLite is based on 3.7.4 – and the real question of foreign key support is at least there – I was able to test against it using a simple CREATE TABLE, but according to the documentation- this is parsed but not enforced. Lets hope that is now wrong too – since even Adobe Employee’s couldn’t come up with this one.

Not sure how well some of us actually read this, but there is 1 section in particular that I find to be fairly interesting, and another is well, lets just say hopefully they learned since AS3 quite frankly is used in mission critical software.

Type inference: Type declarations will only be necessary in certain strategic places. Everywhere else the compiler will automatically infer suitable type declarations and treat the whole program as statically typed, even though the programmer does not have to state any types. Thus the convenience of untyped programming can be approximated quite well, while providing the performance advantages of typed programming.

So two comments on this one, one trivial the other not so much:

  1. Trivial – A lot of code-hinting programs will probably need some rework on giving the correct intelli-sense, since usually with RegEx it would be fairly straight forward (look for the next whole word after the colon where it’s declared). If I understand this correctly, basically what Adobe is hinting at is that the type declaration is only needed at the original source of the declaration? For code editors, this now means going back up the symbolic link chain to find where the parameter / class variable was originally created – this is really no small feat, and I would imagine would cause some parsing concerns.
  2. Opinion – Since when amongst any serious fundamental programmer is untyped “convenient”? Every major development platform that I know of, ALL uses strongly typed. Java, the entire C family, heck even databases do this with affinity. Seriously, it’s not convenient except anywhere more than one class is used. Typed languages have equal weight in performance (no prototypical look up), but also on the human – after all we are the ones who write this stuff, and well documented, well written code is hinged upon knowing exactly what type / interface you are dealing with at the moment.


Compatibility: The next version of ActionScript will be an evolution of ActionScript 3, but in some instances may not be completely compatible with ActionScript 3. We expect that any migration from ActionScript 3 will be significantly less burdensome than the move from ActionScript 2 to ActionScript 3. Regardless, we are exploring options for tooling that would either ease or automate this transition.

Adobe, please for the love of code, please don’t make us go through that again.


And lastly, a note on the Flex roadmap which obviously is of keen interest to me.

RSLs for Apache-released versions of Flex:
Now that Flex is a community-driven project, it is no longer appropriate nor practical for Adobe to sign the resulting Apache Flex RSLs. This means that when using an Apache Flex release, framework RSLs will not be cached globally by Flash Player, but rather per domain in the web browser.

Per domain in the browser?! Are you freaking serious? What’s the point of relying on a framework that is essentially stable and publicly available, only to have every single domain and sub-domain have to deal with loading their own copy? Wow I hope Apache is able to sign this sort of thing, and has the capacity on its servers to handle the request load.

Lastly, Flash nor Flex is dead as many in our industry fret – HTML5 is just another shiny ball that so many chase after looking for the proverbial development “fountain of youth.” Like outsourcing, it won’t be all that it’s cracked up to be and live up to it’s over-hyped promises, but instead will have it’s place in the world under certain circumstances.