This week I’ll be mostly getting my head around effects. Unfortunately missed Tink’s LFPUG presentation, but just been doing a catchup with the video and resources, I think worth re-posting here…
(Update: 28/10/2008 here)
Having been chastised for using these ‘unknown acronyms’ in my comment on jd’s weblog, I thought it worth writing a brief entry describing what these acronyms stand for and how they may be of interest for those purchasing or upgrading Adobe software.
Essentially this is all to do with volume licensing as an alternative to purchasing products through the Adobe store or other 3rd party suppliers. Volume licensing sounds like it is aimed at large organisations purchasing site-license. However the Transaction Licensing Programme facilitates as little as a single product license. The way the scheme works is to provide a transaction discount should you purchase multiple products in a single transaction based upon a point value for each product. TLP purchases may be made through 3rd party suppliers, but also through Adobe directly as in my case. There is no published price list so you need to request a quote.
The key point of interest to me was the Upgrade Plan which allows licenses to be purchased over 24 month subscriptions. Essentially this means I effectively have already paid to cover my CS4 upgrade. This is the point I was trying to make on jd’s weblog. He acknowledges that trial versions of CS3 products not being available until mid November is a ‘Pain point’ and he provides some explanation including the phrase “The big shipping versions get released first.”. Well I’m a AOO TLP upgrade licensee who’s just been told I may have to wait until the ‘end of November’ for it to physically ship to me. If it is painful for ‘users’ who haven’t paid for the software yet, imagine the pain for those who have paid for the software, but may have to wait until the end of November.
So while the Upgrade Plan offers some value, fulfilment seems less than ideal especially given this Key benefit documented on the Adobe site: “Get timely notifications of new upgrades, so you can stay on top of new product releases.”.
This is now my latest bug-bear. For Adobe to see how the customer experience could be improved in this regard, they need only look back to the now discontinued Macromedia DEVNET Pro subscription, where serial numbers and downloadable installers were immediately available to subscribers from day one of a new product shipping.
If this was fixed, I could now be blogging about cool new stuff in CS4 rather than fuming over this and wondering if I would actually be better-off purchasing through conventional means.
Received my Adobe License Fulfilment email on 26th. Logged in and was able to request media for the upgrades, but at the time couldn’t see serial numbers or any way of downloading. However just checked again today, and the serials are there and I now have downloads in progress – and at a good bit-rate. So I’m feeling a lot happier now than when this post was originally published. While the process has not been entirely seamless, this time is far better than my previous experience with CS3 where I had to wait for physical media.
Really haven’t spent enough time ‘finenessing’ Flex based UIs recently, so especially looking forward to a something of a fast-track on Flex Effects in Tink‘s presentation.
Always good to hear how others work with their clients too in the “ActionScript in Commercial Environment”session.
When researching ActionScript libraries to include in a project, it is tempting to simply look to see that it has an open-source license and just use it. However closer reading may often reveal that the license burdens the developer with responsibilities which may make use of the code irreconcilable with the project requirements. Grant Skinner has published a valuable plain English summary and comparison of the common source code licenses. My take from it, is that if the source you are hoping to use is published with any license other than MIT, chances are you are not going to like some of the license conditions and you certainly need to research them.
When using the Adobe AIR Update Framework for the first time, you will be stepping through the associated documentation. You will probably initially decide to use a configuration XML file to govern the update process. The documentation presents the following line to inform the framework of the location of your config file:
Point the configurationFile property to the location of that file: as in the following ActionScript:
appUpdater.configurationFile = new File("cfg/updateConfig.xml");
If you are familiar with the File class, you will see that this is likely to generate a run-time-error, especially when testing in adl…
ArgumentError: Error #2004: One of the parameters is invalid.
at flash.filesystem::File/set nativePath()
If you are like me, you’ll probably want to place the updateConfig.xml file within the application directory next to the *-app.xml file. If so, the line of code you need can be written:
appUpdater.configurationFile = new File( File.applicationDirectory.resolvePath( "updateConfig.xml" ).nativePath );
or more compactly, using the “app:/” url scheme:
appUpdater.configurationFile = new File( "app:/updateConfig.xml" );
Over the past few months I’ve been getting my head around the likes of Cairngorm, PureMVC and better use of design patterns in general. So looking forward to tonight’s LFPUG to see what the Slide Framework For Flex adds to the mix. The other stuff on large datasets looks pretty good too!
A little while ago I got around to building my version of an alert tool sampler, using it as an exercise to learn Cairngorm. (The documentation for which I have found particularly poor with the exception of a few gems such as David Tucker’s excellent Cairngorm ‘Getting started’ tutorials.)
Typically AIR developers will all want to take advantage of the Update capability, but in it’s original form requires some work. Rich Tretola’s UpdateManager did the job, but I wanted more programmatic control, interception of events and a slightly different UI work-flow, and set about creating my own. Just as that phase of the work is completed, I find Adobe’s Update Framework on labs which although beta, does a much better job. I wish it was there a week ago.
Also, I just took the opportunity to update to AIR 1.1. Unfortunately updating Flex to use the new AIR is a little messy (in that it requires manually copying some files rather than running an installer) and means moving to the 3.0.2 stable build of the Flex SDK. However it is not difficult and the instructions to follow are here.
If you are using DataGrid in a Flex/AIR application, the chances are you will at some stage hit the following RunTime error…
TypeError: Error #1010: A term is undefined and has no properties.
.. with a traceback indicating the error occurred within DataGrid.as. At which point you will stare at your own code for a while and wonder why.
In my circumstance I pinned this down to clearing the contents of the data provider and repopulating when there is an item renderer active on the DataGrid. A use-case that probably doesn’t come up that often in web-based Flex apps, since if the user clicks another control to trigger an update, the item renderer is exited at that point and the edit committed prior to the dataprovider changing.
In an AIR app, we have native menus available to us. When the user employs native menu selection, the item editor remains active. If that menu option triggers a repolpulation of the data provider (use-case example File>Open), we then get the error.
The workaround is pretty simple. A call needs to be made to destroyItemEditor() on the DataGrid instance before repopulating it’s data. In a simple application this is no great problem. But if you’ve gone to the effort of using something like the PureMVC framework to separate Data Object from View Components, the data object isn’t supposed to have any knowledge of the view. So in my case thefix is quite crude – when issuing the open command, a notification to destory item editors will be issued so any view component that uses them may destroy their editor prior to the repopulation.
My contention is that it should be the responsibilty of the DataGrid to destroy the item editor if the dataprovider updates.
I have this logged as a bug with Adobe (SDK-15280), along with sample code demonstrating the issue. Feel free to review and vote for the bug if you are in agreement with my point and comment further therein if you disagree or have better suggestions to offer.
I’ve just been trying to delete a node and all its descendants from an XML object selected on the value of an attribute. Having read the “ECMAScript for XML (E4X) Specification” (PDF) as linked to from the Flex documentation I expected to be able to write the following…
however the above code will generate the following Flash Player runtime error…
TypeError: Error #1119: Delete operator is not supported with operand of type XMLList
The solution is simple if not obvious. The above code should be rewritten to ensure a single node is returned rather than a list…
Distilled from this actionscript.org thread.
When you come to build your first Flex/AIR application that needs a native menu (Application menu on a Mac, or Window menu on a Windows PC), you’ll probably find your way to the “Windows, menus, and taskbars” section within the documentation. From there you’ll navigate to “Working with native menus” and spend some time studying “Creating native menus” before going on to view the example code. At this point you’ll probably have a shock at how much AS3 code needs to be written to implement such a simple menu. Not at all what you are used to in Flex.
If you are thinking there must be a way to do this using a component. You’d be right, but it is documented in the “Using the Flex AIR components” “About the FlexNativeMenu control“section not the “Windows, menus and taskbars” section.