If you are used to double-hitting the tab key after setting the marquee width, in order to then edit the height, then you are fine. You still need to do the same in CS4 beta.
My earlier rant on this : a little fireworks CS3 bug.
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.
I’m not usually one for echoing release announcements. Herewith one minor exception. With the arrival of a number CS4 betas on labs I was please to see “Subversion integration” being a new feature of DreamWeaver CS4. After a history of making simple Zip snapshot backups, and more recently using subversion along with the “Cloak/Uncloak SCM directories” extention and client tools such as SvnX, and SCPlugin it will be interesting to see how well the integration has been done. Looking good from the description.
Update: Unfortunately looks like Subversion is only supported through a server in this release. I really need it to be able to use the “file:///” protocol to access repositories on my local system without having to set up a server. Here is my entry on the Dreamweaver Beta Forum, feel free to add to it if you have opinions one way or the other.
Thanks to Sean for organising a second poker tournament and thanks to Adobe for sponsoring it once more. Last time I was a loser. Last night however I did a tad better. Still feeling a quite pleased with myself and slightly guilty for beating some far more seasoned players to get to the final table, then to be knocked out of the last six by the guy who went on to win the whole thing.
With today’s availability of release versions of Flex 3 and AIR 1, I’ve finally had a chance to apply the DragManager workaround that I had a moan about last month.
The flex documentation presents three configuration options for DragManager in AIR projects…
[Extract]
- Your main application file uses the <mx:Application> tag. In this scenario, you use the Flex drag-and-drop manager, and cannot drag and drop items from outside of AIR.
- Your main application file uses the <mx:WindowedApplication> tag. In this scenario, you use the AIR drag-and-drop manager, and can drag and drop items from outside of AIR.
- Your main application file uses the <mx:Application> tag, but loads the AIR drag-and-drop manager as represented by the mx.managers.NativeDragManagerImpl class. In this scenario, you use the AIR drag-and-drop manager, and can drag and drop items from outside of AIR.
Sounds all well and good. Except to use <mx:Application> within AIR, you lose functionality. For instance in my case while the window was re-sizeable, the content remained at the default size. What I really need is to use <mx:WindowedApplication>, but with the Flex DragDrop manager. A scenario not represented in the documentation.
Fortunately the workaround with files described in bug SDK-13983 so-far appears to work. However it is worth noting that in using it, a number of mxml tags change their namespace from mx to comps. In my case this affects
which then become
Possibly my reliance on this approach is due to the now legacy nature of the project - it was written in advance of the Apollo 1 alpha. However apart from this issue, very little has had to be re-written through the beta cycle of AIR.
A busy few weeks starting tonight:
I’ve just found myself caught out by this bug (SDK-13983) in Beta 3 (released December 2007), and the quite substantial change in behaviour.
My application which is only a prototype - but quite heavy, was essentially built from Oct 2006 through to April 2007 and worked happily in Apollo and in all AIR and Flex 3 releases since, until Beta 3, when the DragManagers of AIR and FLEX implementations diverged. The API remains pretty much the same, but the behaviour is quite different (documented here), and while my existing code compiles, it generates run-time error “ArgumentError: Error #2004: One of the parameters is invalid.” if the user dare drag my UI components, rendering it useless.
That it has been accepted as a bug and a fix/workaround created, and that that is visible in the public bug system is a good thing. It removes a lot of potential worry. That the fix is not available to the public (AFAIK we’ve had our last public beta before the final release) isn’t great for me as I am now in a catch 22.
It’s late, so this is going on hold until morning, at which point I need to assess the impact and time required to make the changes to adopt the AIR drag-and-drop manager, or hold on until I can force the switch to the Flex drag-and drop manager when the final release is available. Or beg Adobe for access to a build later than 191577.
This week it is a biggie with contributions from Adobe’s Serge Jespers and James Ward presenting Flex 3 AIR and Vega.
The event had reached capacity but with a new venue organised and more capacity, if you couldn’t sign-up over the last couple of weeks, you now have another opportunity.
Again it looks like a couple of really interesting subjects on 31 Jan:
More information is on the LFPUG site
I looked at using PureMVC previously for a simple tennis game, but left it aside in favour of building MVCish classes independent of any ‘framework’. I look forward to seeing if this decision saved or cost me time.
I haven’t got around to the obligatory 3D stuff yet. Personally I’ve always found it a bit of a red-herring, and one where the cost:benefit often falls short. So I’ll be particularly interested in seeing examples of good use.
