Flexbuilder Debug Mode Dog Slow on Mac using Firefox

Quick find today.

Little while back debugging in FB 3.0.x became a brutal exercise in futility. Finally reached a point where I couldn't debug at all. At the time I was running FF2.x. Initially upgraded to FB3 with no change, well no change, except that suddenly I wasn't entering debug mode (bug: had GreaseMonkey Add-On installed - removing it fixed that). Once I was entering Debug again, it would grind my Mac to a halt. Switched to Safari and it worked perfectly. Figured out that Piclense / CoolIris addon for Firefox was in fact the culprit. I uninstalled that add-on and suddenly Debug mode was working just fine again. Lesson learned: If debugging against Firefox, be wary what add-ons you have installed. Hopefully this little lesson will help others.

Why no Sandbox Violation running from Bin?

Ever noticed that once you copy your html/swf files from the bin folder in your flex project to another file location, or just move the bin folder itself, your flex application no longer happily makes the remote data calls that only worked a minute ago in Flexbuilder? Well we ran into an interesting issue, when trying to push custom HTTP headers to a server. It worked fine while debugging in flexbuilder, and even double clicking on the html file in the bin folder worked. Yet the minute I moved the bin folder to say "program files\my proggy", the application would give a nasty error like this:

Error #2170: Security sandbox violation: file:///program files/my proggy/APITest.swf cannot send HTTP headers to http://myservice/DIRTNAPPY/.

I did some research, and there's actually tons of information out there that deals with this issue. First and foremost this article http://www.adobetutorialz.com/articles/1785/1/Local-Sandboxes does a very good job of explaining exactly what is happening behind the scenes.

Essentially Flexbuilder tells Flash that it should trust the bin folder... if you do a search on your development machine for the file flexbuilder_plugin.cfg, you should find it in a folder called FlashPlayerTrust in roughly the same area you normally find SharedObject files. If you open this file in a text editor, you should see pretty much every path to every bin folder for every flex project you have ever worked on. And suddenly everything gets so much clearer.

So I created a new file and placed it next to this flexbuilder_plugin.cfg file, and called it MyProggy.cfg. Flash is configured to read in all files in this folder and parse all paths out of it, and any applications run from these paths will be considered "localTrusted" and will act as they would when run from Flexbuilder. Inside this text file I put one line: "c:\program files\my proggy" and saved it. I then had to restart Firefox for the change to take effect. I also had added a text label to my application and bound the text property to {Security.sandboxType}.

Launching the app again from c:\program files\my proggy now showed the app running in localTrusted mode, and sure enough all my data calls worked just fine. Keep in mind, that all this only works when you intend to host your application on users machines, rather than on a webserver. It's simple enough to add the necessary text file when your application is being installed.

I should add that as a back up plan, you might want to consider trapping the Sandbox Error and then communicating to the user that they'll need to right click on the application, select Settings / click Advanced / then click on Global Security Settings Panel and add the appropriate path to the list of "always trust files in these locations". (still easier than making them go and create this text file themselves and saving it to the right location).

mx.controls.Text: preventing scroll on select

A minor annoyance in Flex that I've lived with for many moons now is that even though I will provide enough vertical space to show all the text or htmlText in a Text Control, when a user attempts to select the text, often times, the text will scroll up, hiding the first line. The easiest fix is to set selectable='false', and in most cases this will do the trick. There are times however, when a client will demand that text remain selectable. And that same client will be the first to complain about the apparently unnecessary scrolling of text.

I played around with this, but seriously, the mx.controls.Text class really doesn't give one much to work with. On browsing through the sdk source, I discovered I'd probably have better luck working with the wrapped UITextField. In the end I tapped into the scroll event and the alwaysShowSelection attribute of the UITextField to get me where I needed to go.

It's been a long week so I'm just going to post up a link to the solution here, and the source code here.

Dogtagit Flex 3 Project

I've been working closely with Threecast on a project for some time now, and they've made a demo site available for me to showcase. It's hosted on port 8888, so you're best off to try this at home. The application is built on SqlServer, .Net, Weborb and Flex 3 using Cairngorm. Feel free to have a look around, and play with it. This version has the login disabled and the data is reset on a regular basis - it's primarily just for preview purposes. You can view the site here:

http://demo.dogtagit.com:8888/beta/main.html

And if you want to sign up and try it out for yourself, you can go to their home page www.dogtagit.com here and sign up.

Sometimes cornerRadius just isn't enough

Two tips for coders new to Flex... if you want to have rounded corners in mx.containers like VBox, HBox, Canvas, etc, set the borderStyle to solid and the borderThickness to 0, and then set your cornerRadius to whatever you want. If the borderStyle is left at none (default), the cornerRadius attribute seems broken and ineffective.

The second tip, if you want rounded corners at the top and bottom of your Panel, there's a property called roundedBottomCorners which defaults to false. When set to true, you will see rounding both top and bottom.

Here's an example http://www.crazedcoders.com/demos/rounded/

I should point out that this has been blogged previously here.

Invalid Embed directive in stylesheet

On a few occasions now, for no really apparent reason, suddenly our Problem Pane will be spammed with tons of messages all sort of looking like this:

Invalid Embed directive in stylesheet - can't resolve source 'Embed(source = "/assets/common.swf", symbol = "AccordionHeader_disabledOverSkin")'.

In the past, sometimes it would only happen on a mac, other times windows machines. I've tried deleting my bin folder, cleaning the project, recompiling the swf's, moving the swf's around, changing the syntax in the css ever so slightly. I've googled this on many occasions and found no clear answer. Today I decided that I needed to know what caused this and if in fact I figured it out, to share it with you.

What ended up being the root cause of our problem is that in several places in the application we were referencing image assets directly in our assets folder, i.e. /assets/delete.png, which is often the case when our designers aren't keeping up with asset creation and developers just throw some image up as a placeholder for the time being. Now it just so happened that ONE of these references was incorrect and its Embed pointed to a file that did not exist. I discovered this when I commented out our style css references in the application, and saw the error only then. It was this broken reference that caused the above error. I fixed the reference to point to the right file, did a Project clean, and all the Invalid Embed Directive errors went away.

I should note that we had over 100 references to symbols in our css, and by default Flexbuilder only shows the first 100 errors. Unluckily the "unable to resolve 'assets/deleted.png' for transcoding in ...." was error number 138 and did not show up in the list. I had to change my preferences to show all 138 errors.

So the lesson learned is that when you get spammed with this error, it could well be that only one Embed tag somewhere in your app is actually broken, and that your css and swf is probably just fine.

Working With BlazeDS Beta 1

Last week we successfully ported an AIR application from amfphp to BlazeDS. The code for this application was almost completely generated by a new generator we're working on (coming soon!). With the announcement of BlazeDS, we kinda shelved our php generator and redirected our efforts in doing the same thing for BlazeDS. In the process, we put together our own version of the blazeds.war file that ships with BlazeDS beta 1, which we use as the starting point for all our BlazeDS projects. Here's a list of the changes we've made:

• Modified the context.xml found in the META-INF folder - the packaged one was producing Valve Errors
• Added the missing my-streaming-amf channel to services-config.xml, which I found in the BlazeDS samples war's config file
  
• Incorporated the latest Flex 3 Compiler Module files to allow server-side compilation of mxml files
• Created a very simple java class and a corresponding destination which will verify Blaze backend functionality
• Created a very simple Flex application that calls the above java class function test(string)
• Added 2 jars to WEB-INF, one is crazedTemplate.jar, which our new codegenerator (coming soon) uses, the other is sharpertools.jar, which the jar requires.
  

You can choose to go ahead and just use the application as is. It's only been tested on Tomcat / Win / OSX 10.5.2. If you don't intend on using our generator (coming soon!) to generate your java and AS3 Classes then you can go ahead and delete the 2 jars mentioned above. I really like this separation of compiler and essentially what was FDS. When FDS was originally released, it did both runtime compiles as well as Remoting, Messaging, Proxy and Managed Data Services. In our case, we never deployed anything that required runtime compilation AND furthermore, with each subsequent Flex release (2.01, Hotfix 1, 2 and 3), converting FDS projects that were set to compile on the server wasn't trivial. So we stopped using it. If I was super Java savvy I might have been able to figure out what parts I could yank out of my FDS application, but generally it seemed better to just leave it alone.

Now, with Blaze and the compiler war being separate, I've gone through the web.xml in this project and put comments to show which pieces are required by the compiler module and which pieces are required by Blaze. To get this back to being a pure Blaze non-Flex 3 Compiler Module, you'd just need to remove the appropriately marked sections from the web.xml and then remove all folders and files from WEB-INF/flex with the exception of:

• services-config.xml
• remoting-config.xml
• proxy-config.xml
• messaging-config.xml
  

Some of our clients have asked what the differences exactly are between BlazeDS and LCDS (prev. known as FDS). If you do enough research on the web, you can find several answers. From what I've seen, here's some differences I've found so far:

• BlazeDS does not support the RTMP Channel typically used by LCDS for data push (RTMP typically means firewall port challenges all around anyway!)
• BlazeDS does support AMF Streaming which offers data push like RTMP, however not nearly as scalable (100's vs 10000's of concurrent users)
• BlazeDS does support proxy so you can bypass the all too familiar sandbox issues when accessing remote data where no crossdomain.xml is present
• BlazeDS does not come packaged with the Compiler Module
• BlazeDS does not have managed dataservices. This means that you don't need the fds.swc (DataService & [Managed]) in your flex projects.. you will use either Consumer, Producer or RemoteObject Classes
• BlazeDS does support AMF3, RemoteClasses & Messaging with a "lite" version of push via amf streaming
  

To download the blazeBlank application click here. (as new builds of Flex 3 and BlazeDS are released I'll try to keep this application updated). This application currently uses Flex 3 Beta 3 and BlazeDS Beta 1. Be sure to visit the url /{context}/TestApp/Main.mxml to ensure that the application is working properly. (i.e. http://localhost:8600/blazeBlank/TestApp/Main.mxml)

Flex 3 (Beta 3) Badge.swf don't like spaces!

We just recently were challenged with trying to update to the latest Flex beta, and there have been a few changes to the way the seamless install badge.swf works. For one thing, this program now goes out and talks to an air.swf hosted by Adobe. The second, and far more annoying "feature" was that if you had an AIR file name like "Sample Application.air" and tried to publish that using the sample batch.swf provided in the SDK, the AIR Installer would fail, choking on the space.

I've hacked the badge.fla file using regex to put replace spaces with %20, and this seems to have fixed the problem for now. I also downloaded a copy of the air.swf from the Adobe site, threw it in the same folder as my badge.swf and changed the code to use that one instead.

You can get the whole bag of goodies here. I've included all the source and a ready to use badge.swf, as well as a working sample.

amfphp/flex/cairngorm Codegen - Source Available on Google Code

I've had quite a few people ask if they could get their hands on the php source for the code generator tool I published back in October here. My intention has always been to eventually get this out to the community, however the last couple months have been just crazy, with one release after another getting pushed out the door. So much demand for AIR and Flex applications, so little time...

Anyway, we finally had some time to get this thing cleaned up and out on Google code... you can find the source files at http://code.google.com/p/flexamfphpcairngormgenerator/source