Currently Viewing Posts in Flex 3

DragManager workaround in final Flex3/AIR1

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]

  1. 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.
  2. 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.
  3. 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

  • <mx:states>
  • <mx:transitions>

which then become

  • <comps:states>
  • <comps:transitions>

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 flurry of events : Adobe/Flash/Flex

A busy few weeks starting tonight:

  1. [Thurs 21-Feb-2008] LFPUG – Thermo Special presentation from Adobe
  2. [Mon 25-Feb-2008] Adobe sponsored Pokercoder Tournament II  – you need to be a professional user of Adobe products to join in
  3. [Thurs 28-Feb-2008] LFPUG – presentations on ‘Successful Flash Games’ and ‘Practical Particle Effects with Flint’
  4. [Wed 5th March] FLUG – Beer, presentations and chat about Flex

bitten by the beta 3 DragManager Bug

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.

  • The fix isn’t available to me until the final version is released.
  • I can’t continue to use my application compiled against Beta 2 as the install process for AIR currently demands Beta 3 of AIR
  • Beta 3 AIR  demands Flex Beta 3 SDK.

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.

Three is the magic number at Adobe

Just as I’m about to head into hibernation for a week or so without computers or any connectivity, Adobe go and release all these goodies. Something to look forward to on my return…

  • AMF3 Specification
  • Blaze DS – Free LGPL Remoting and Messaging for Java (ok not three, but free!)
  • Flex 3 Beta3
  • AIR Beta 3

A good start-point to read more (a brief paragraph on each) is Ted’s OnFlex blog, and of course the Adobe labs site.

sensible(ish) code print from flex builder (on MacOS X)

Continuing the theme of occasional Flex Builder hints and tips…

Occasionally I need to see code printed on paper. Unfortunately the printing capabilities of Flex Builder, or more specifically in this case, Eclipse, are a bit messy…

  • the font is huge, and only 49 lines fit on an A4 page
  • if you have a background colour set to your code window, it gets printed – decimating your ink-tanks
  • printing is a two dialogue process – you have to go through Page Setup each and every time.

Of course in the actual Print dialogue, you have the standard Mac ability to change the page layout, paper handling etc, and save that detail in a pre-set. However…

The key things I want to achieve is to print 2up full duplex black and white, which gives me four pages of code per sheet of A4, and with a slightly smaller font size I get a more respectable 68 lines of code per ‘page’.

However I’ve found the following approach, once set-up, a little more convenient, and becomes a one-click print…

The Mac has a GNU enscript installed which converts text files to PostScript to send directly to CUPS. In my case I had to update the old Gimp-Print drivers to the current Guten-Print drivers in order to achieve duplex printing.

More information on Guten-Print and access to the drivers on SourceForge. The DMG contains good documentation and a simple package installer.

Once the new drivers are installed, and I’d recommend a new, additional, print queue be set up with appropriate defaults for your code printing, you need to set Eclipse to run an external script to print the currently active code window. From the menu: Run > External Tools > External Tools…

  • Name: enscript
  • Location: /usr/bin/enscript
  • Arguments: -2rT4v -DDuplex:true -diP5000 ${container_loc}/${resource_name}

Obviously you’ll need to tweak the arguments according to your personal print configuration.

External Tools Dialogue

option up and down

Kicking myself for not finding these sooner so, posting in line with the current trend of highlighting little Flex time-savers. Two ActionScript editor short-cuts (and probably apply to any Eclipse code editor?)…

1. Select some code in the ActionScript editor and press Option-Up or Option-Down, and the selected block of code gets moved accordingly. Or just place the cursor on a line if you only wish to move a single line. Saves a load of messing with Cut-Paste.

2. Need to duplicate a line? Place the cursor at the start of the line and press either CMD-Option-Up or CMD-Option-Down, and the current line (or selection if you have one) gets duped above or below the cursor respectively.

With either of the above, if you make a selection, you don’t need to be character accurate. The movement is applied either to the line touched by the cursor, or the lines touched by the selection. i.e. If you select part of a line, the whole of that line is included in the selection to be moved.

flex, mac, external browser

Ted Patrick has been quite prolific of late at publishing little productivity hints and tips. I think this one from a couple of weeks ago is worth echoing and noting the workaround for the problem it raises on a Mac.

We are setting up Builder to launch the help pages into an external browser. The key advantage of which being that the code samples can then be copy/pasted. On a Mac there is a recognised bug in eclipse that if you choose Firefox as the external browser, and it is NOT your normal system default browser. Basically Eclipse attempts to launch a second instance of Firefox which will generate the “Only one copy of Firefox can be open at a time” dialogue…

Firefox close dialogue

So to get around this, you have two options.

Option 1, if you have Firefox as your default browser for the entire system, simply choose “Default system Web browser” in the Eclipse preferences panel.

Option 2, if you want to keep something else set as your system default browser e.g. Safari, but would use Firefox for displaying Flex Builder help, you need to either edit or create a new external browser entry using a command structure as per comment 5 on the eclipse bug sheet. Essentially the following settings work…

  • Location: /usr/bin/open
  • Parameters: -a firefox %URL%

Flex Builder > General > Web Browser >Edit external browser

flash, flex and vice versa

I have a small AS3 project where I need to keep the SWF quite small. I really want to use the Flex Builder environment to do the coding, and ultimately produce a target or targets suitable for inclusion both in Flash and/or Flex projects.

Two very helpful posts of the last couple of days with respect to setting up a suitable environment:

essential actionscript 3 published today?

I don’t have my hands on it yet. I do have it on pre-order. Although at time of writing, Amazon is still showing it as ‘not yet published’, today is the official publish date. If it’s predecessors are anything to go by, this really will be the one book any ActionScript programmer should always have to hand. For more information and samples, check the author’s blog.

Update: Must be in high demand! Going to have to wait until at least 11th July 2007 for my copy.

Update (14 July 2007): my new “Estimated arrival date: 25/07/07 – 30/07/07” from Amazon.

good stuff coming in the form of Flex 3

It was pretty good to see some of the new stuff coming in Flex 3 during the developer day this week at Adobe Live London. We were a tough audience and didn’t give much of a WOW feedback – sorry! Largely I think because much of the new stuff demonstrated I think we might have claimed a right to expect – such as re-factoring support and improved work-flow with the rest of CS3.

Not covered on the day, but would have got a WOW from me is ‘Framework caching’, described by Ted on Flex today.

To me this was not expected, however I tend to think it has been a long-time coming and is one of the most significant improvements within Flash Platform in a long time. I came to Flash very late (MX2004) and primarily worked with components. (I came to Flex even later – V2.) It always struck me as a little odd that Adobe/Macromedia placed such great emphasis on keeping the plugin download small which then had the knock-on of vast quatities of band-width wasted as the same component code is transmitted time after time and where you least desire it -hitting the load time of your SWF. However now being able to cache the framework now means only the code specific to the application need be transmitted. Much more net-friendly. I can’t wait!

  • Latest

  • View Paul Evans's profile on LinkedIn
  • Twitter

  • Categories

  • Archives