So I’m updating an old Flash project to AS3, and I need a quick solution to add a few scrollbars onto a few textboxes. So I get out the Flash CS3 UIScrollBar. Only problem is, it’s not working. Works in a standalone FLA, but when I bring it into my app, there’s no scroll bar, no arrows, and the component is unresponsive to textfield content changes.
The UIScrollBar class is a simple scrollbar component that ships with Flash CS3 and CS4, that when associated with a given TextField, enables you to scroll that TextField. Simple, right? Or it should be. After cursing the gods for yet another buggy Flash component — I mean, I thought the days of hacking through the Flash component set to get it to frakin work were done with! So after slogging through a few useless hacks — like purposefully populating the textfield with a gazillion line feeds to get the scrollbar to initialize, then deleting them — I figured out a solution.
There must be a bug with the component, because it was not registering new text being added to the TextField. If the TextField was populated with more text than vertical space allows before the UIScrollBar initialized, then the scrollbar would work. But this was the exception to the rule, since most textfields in the app would be dynamically populated form an XML file. So I needed a way to force an update of the scrollbar when the content in the TextField had changed.
When converting from a Flash CS3/4-based project, to a Flex-based project, there are not just one or two conversion paths to consider, there are many, all of which depends on the Flash project in question.
I’m on a discussion on LinkedIn, in which one guy asks if we know anyone who can do a Flash-to-Flex conversion project, which evolved into a discussion on techniques. Rather than post a pages-long reply, I thought I’d post it here instead:
First, for any Flash-to-Flex conversion to go smoothly, you’ll need at least one person on your team with a good dose of real-world experience with both Flash and Flex-based RIA projects (Flash banners do not qualify ;)), to guide the conversion process and make sure the best deployment strategies are implemented.
As far as the conversion path, there are several possibilities. Depending on the kind of project, you may want to migrate some, most or all of the project to Flex. When migrating from Flash to Flex, you’re not just migrating code, you’re migrating from a visual asset instantiation and state management environment to a purely coding-based methodology (if we forget for a second about Design View in Flex Builder).
As reported on the Canadian Net Neutrality action website SaveOurNet.ca, “The CRTC has said that it will consider public opinion in determining the outcome of the traffic shaping hearings set to take place later this year.“ As Canadians, we owe it to ourselves and this great nation to hold governmental institutions charged with guarding the public trust accountable to the purpose for which they were created. We need to send ISPs in Canada the message that this kind of censorship shall not be tolerated, and should not be allowed. Check out the details on SaveOurNet.ca, and send in your action letter to the CRTC.
Looking back on the book projects I participated in over the course of 2008, I notice that the two ActionScript 3.0 books I served as principal tech editor are both out. The ActionScript 3.0 Migration Guide by New Riders/Pearson is a compact guide illuminating some broadstrokes of migration from As2 to AS3. The ActionScript 3.0 Visual QuickStart Guide by Peachpit Press from my Community MX colleague Derrick Ypenburg, is a great primer on the basics of ActionScript 3.0, which is also a useful primer for those converting to ActionScript 3.0 for the first time.
There’s an interesting back story to the AS3 VQSG: I was actually commissioned to write this book, and got as far as writing the outline and scope of the text. At the time I just started writing two books, this one and the Professional Flex 3 book, and it didn’t take me long to realize that writing two heavy books at once would be career suicide, as I would have no time for client work (a man’s got to eat, right?) But I can’t just drop the book: I am honour-bound to find myself a replacement. So I call up my colleague Derrik Ypenburg: we talk about the book, he agrees to take on the project, and we decide that I’ll stay on as the tech editor. Derrick did a great job of writing the text, and at times the project felt more like a collaboration, a co-creation than an editing job — even though Derrick did all the hard work ;) — which is how all team projects should be. Well done Derrick.
Okay I was going to wait until after MAX to blog about stuff, but this cannot wait: as of about 7:30pm PST, at Adobe MAX 2008 SF, the sneak peeks announced that ColdFusion
9 will have server side ActionScript 3.0 capability. I’ve been waiting for this since Macromedia Comm Server, never mind FMS…
Correction: they didn’t say ColdFusion 9, they said they were working on this for a future version of ColdFusion Server.
You know, Flash Catalyst (aka Thermo) is cool, I mean way cool. And CoCoMo, and the next version of FMS with RTMFP is cool, and Alchemy just rocks the house, and Configurator is nice in a nostalgic kinda way (for me). And Gumbo, well it is definitely cool, but it’s not really news.
I mean, I was blown away enough by the sneak peeks Flash Player Multicast (via RTMFP), Nitro (SWF widgetization), Durango (realtime drag drop HTML/Flash/AIR component mashups), the Content Intelligent Toolkit, MeerMeer (multi-browser realtime virtualization)…
But what did it for me, the whole payoff for travelling across the continent from Toronto to San Francisco to go to MAX, was very last on the list. Server-side ActionScript 3.0, with
the next a future version of ColdFusion Server.
If that were it, well, I would think, hey, that’s cool. But it’s how you can do it that totally rocks the house, that’s got me dancing in the streets.
There are three ways, from what I could tell:
1. ColdFusion tags on the server with ActionScript 3.0 in a <mx :Script> block which generates HTML (and whatever other server-side code I would guess).
This brings the power of AS3 to ColdFusion developers. Combined with the new eclipse-based ColdFusion IDE which can sit alongside any other Eclipse Plugin (like Flex Builder), and CF will be a whole new ballgame.
2. MXML & AS3 in Flex Builder.
Now you can author your MXML and AS3 in Flex Builder for the client-side code calling a Service operation on the server… written completely in ActionScript 3.0 inside a
<mx :Script> tag, no ColdFusion, using a .sas file on the server.
3. AS & SAS in the same MXML file in Flex Builder, compiled using
the next v. a future version of ColdFusion Server.
This is the one that did it for me, the one that brought home the bacon, oh yeah!!! :)
So now, as a Flex developer, I don’t have to know server-side code to create a service or a remote object on the server. I can just write:
<mx :Script runat="client">
<mx :Script runat="server">
Update Nov.19,3:30am PST: Sorry if you saw the wrong MXML in the last five hours, wordpress kept trying to correct the invalid XHTML of the MXML tags, but it’s fixed now.
…and I’ve got code running on the client and the server, all in ActionScript 3.0,
in the same file.
Now I don’t have to be freakin’ Java or PHP or CF expert just to code a backend-enabled Flex app.
Adobe, you frakin’ rock.
In the last article on Community MX, we looked at how to use Flex Builder as the ActionScript 3 editor for a Flash-compiled project. But if you are using any Flash CS3 components, Flex Builder is unable to recognize those classes. In this article, we will take a look at how to get Flex Builder to recognize the Flash CS3 Component classes for editing ActionScript 3 files in Flash CS3 projects.
How do we get Flex Builder’s code assist to recognize Flash CS3 Component classes?
( I’ll give you a hint: you find all the fl.* class locations in the Flash CS3 installation directory, and reference them as external source paths in Flex Builder )
For the full, step-by-step explanation, the tutorial is available here on Community MX.
If anyone has tried to use System.showSettings() and wondered why it wasn’t working, I noticed that in all three reference manuals — AS3 ref, Flex 2 Lang ref, Flex 3 Lang ref — the Camera class has contradictory information about which class the showSettings method belongs. Must have been a typo left over from the AS2 days, and accidentally got duplicated. All three pages say the same thing:
Note: The attachCamera() method will not invoke the dialog box to Allow or Deny access to the camera if the user has denied access by selecting Remember in the Flash Player Settings dialog box. In this case, you can prompt the user to change the Allow or Deny setting by displaying the Flash Player Privacy panel for the user using Security.showSettings(SecurityPanel.PRIVACY).
If getCamera() returns null, either the camera is in use by another application, or there are no cameras installed on the system. To determine whether any cameras are installed, use the names.length property. To display the Flash Player Camera Settings panel, which lets the user choose the camera to be referenced by getCamera(), use System.showSettings(SecurityPanel.CAMERA).
The first reference is correct: the showSettings method belongs to the Security class in AS3.
Logged a bug here as well.
This week while writing a tutorial for the Flash-Flex Integration series, I came across this very strange error whenever I tried compiling my Flex project using a skin which had a boundingBox clip on the timeline, using a Button skin template in the Flex Skin Design Extension for Flash CS3:
Unfortunately this error occurs whenever you place any kind of MovieClip (and I suspect any non-drawing object as well) on the timeline.
The solution, it would seem, is to simply declare the object on the skin timeline:
Which seems very odd to me, given that UIMovieClip is a dynamic class.
Just to verify for myself that this was true, I placed the following code on the timeline:
- import flash.utils.*;
- trace("class: "+describeType(this).@name+"\nextends: "+describeType(this).@base+"\nis dynamic: "+describeType(this).@isDynamic);
Which, sure enough, returned
is dynamic: true
This is very puzzling to me. I’ve logged a bug on the Adobe JIRA bugbase. I’m hoping they patch it soon or release a technote; people using the extension should be aware of this issue, or much tearing-out-of-hair may ensue.
Update 2008-04-18: Just discovered that Jesse has found the same bug, and it’s not really a bug but a quirk of the Flash compiler not automatically declaring class instances on the stage.
My guess is that this error is appearing because normally when you associate a class linkage with a MovieClip in the library, you need to declare your stage instances, as automatic stage object declaration is turned off. Same here, except the class associated with that container is UIMovieClip, which is not a custom class where you can place your object definitions. I still think there needs to be a mention in the FCK documentation about this.
As soon as I saw Jesse’s post I smacked myself in the head proclaiming “Of course!”
Some weeks are just like that.
I posted a request on the Flex 3 Livedocs, and Stephen Gilson from the Flex doc team was kind enough to include full details on the SWF metadata tag in the comments section of the page. According to him, the SWF metadata tag was undocumented by mistake, and will be added in a future documentation update. In the meantime, check out the comments on the livedocs page.
I always wondered if this day would come. Now, hopefully, it just might.
Following is a reply to a post on the Open at Adobe blog entitled Is dead code ever a good line?
If someone cares that the program continues, and is will to commit their resources, why shouldn’t the code be released? If the code is good enough, and doesn’t include other properties, why not release it? If a community is available to control and govern it, why not? If the product was good enough to build a market on its own right, why should we believe it can’t continue?
So, to both of my readers
, what do you think? Should dead code be released? Are there examples of it working, or failing? And what do you think are the steps that would help us decide?
I knew exactly what I would write. The same thing that’s been on my mind since I started doing serious actionscript development back in 2002, and the one reason I switched to being a Flex developer:
“I think the answer is hell yes, particularly in Adobe’s case.
I’m going to take a moment and gripe about a typical situation which underscores the importance of this point.
I can think of a few situations in the past where open sourcing the code for the Macromedia Flash v2 (i.e. MX 2004) components would have saved a lot of developers, including myself, from a lot of pain and grief. The fact that Macromedia had abandoned the v2 component code back in 2005 (maybe earlier?), and yet would not open source it, left the Flash development community with little alternative than to use 3rd party component frameworks, because patching up holes in the component framework was simply not a legal option. I remember back when the v2 components were released, a few bright stars in the community found fixes and patches for them, but were unable to distribute this code because of the closed policies surrounding these components. This made a lot of people extremely unhappy.
None of the alternate component sets were satisfactory, because none of them were as complete or feature-rich as the v2 component set. And so we waited for someone, anyone to step up to the plate. We waited for MCOM to complete its vaunted component set, which would supposedly save us all from the bugginess of the v2 architecture. But by the time they were released, Flex 2 and AS3 was just around the corner — why bother?
I say this not to gripe for the sake of it, the past is the past, but to emphasize that Adobe should never, ever, EVER repeat this mistake ever again. This one goof nearly killed component-based development for the Flash Platform back in the day, only to be saved at the 11th hour by Flex 2 and AS3. So obviously
MacromediaAdobe has learned since then.
Many of us cheered a massive hurah when Adobe announced plans to open source the Flex SDK. Alas, we were now saved from a fate worse than death by having to use closed source components. To the Flash developers in the trenches, the ones who sweat blood and tears to make Flash live up to its potential, we are glad not to have to hack our way through closed code with a chainsaw just to build good apps. Thank you for opening up, and later open sourcing the Flex SDK.
But lot of developers working with legacy AS2 code are still not happy. I’ve even seen development teams violating the EULA and decompiling the entire component architecture, just so they can fix a few things and put out a stable version of their application. So it would be a bit of an understatement to say that it would be a saving grace for them, or if nothing else offer some sort of closure on the issue for the rest of us who have moved on, if the
MacromediaAdobe Flash v2 component set were open sourced, at long last. Better late than never.
And while you’re at it, Flex 1 & 1.5 and all the cool MM Dev Kit components that rarely saw the light of day outside of Flex 1-land.
Adobe, if you really want to embrace the open source movement, you need to do this, for your loyal community of Flash developers who have stood by the technology through the years and helped nurture it to what it is today.
A plea from a passionate Flash and Flex Developer.“
Everyone who feels the same way that I do, lend your voice here or on the Open at Adobe blog, and maybe we can finally get that train into the station at long last.