Archive for January, 2008
GoogleReader and some great flash / flex blog entries
Thursday, January 31st, 2008 | actionscript, flex | No Comments
Google Reader has been the perfect resource for me to manage all the blogs (flash and otherwise) that I read everyday. I can categorize my feeds by label, view an aggregated feed of those feeds chronologically, and it even keeps track of new entries. I’ve even found some great new flash blogs via its recommendation system (I’m up to 40 now :O).
A couple entries of interest I’ve read lately and wanted to share:
Eric Feminella’s great Quick Tip blog posts:
Using a parameter class instead of an anonymous object to replace unwieldy method parameters
Using fully qualified paths to define custom event constants to avoid conflicts
This one deserves a post of its own when I have some time to really tinker with it but Metal Hurlant who created the AS3 Crypto Library has created an AS3 run-time compiler written in AS3 by porting parts of the Tamarin project’s “esc” compiler. You can create functions and even classes during runtime. Check out the live demo! Its an exciting time to be a flash developer.
The entity name must immediately follow the ‘&’ in the entity reference
Wednesday, January 30th, 2008 | flex | 2 Comments
If you’ve ever written code in a binding tag and gotten a special character error try html-encoding the character like you’d do if you were encoding regular text:
Error: <mx:TextInput text=”{(_feed.url && !_feed.isTemporary)?_feed.url:’Save Feed to generate URL’}” />
Works: <mx:TextInput text=”{(_feed.url &&Â !_feed.isTemporary)?_feed.url:’Save Feed to generate URL’}” />
It makes sense after the fact but before you actually do it, it just looks odd to html-encode your actionscript.
flex debugging adding ?debug=true to your debug file path
Friday, January 18th, 2008 | flex | 1 Comment
I’ve exhausted my resources trying to figure out how to disable Flex from adding the querystring variable ?debug=true to whatever file path you use when launching your app in debug mode. I have my debug path pointing to an html file with a custom html embed so this flag isn’t being used by it. It is however blocking me from appending my own variables which get encoded and made unusable :/
The only thing I came up with in google is this semi-related reference from: http://livedocs.adobe.com/labs/flex3/html/help.html?content=apache_3.html
“Flex Builder appends ?debug=true to the URL when it launches the browser. This query string parameter triggers a compilation with the debug compiler options enabled.”
Does any of the 0 people that read my blog have an answer or suggestion? I’m assuming a solution could be found regarding the use of “query string parameter overrides” and the flex-config.xml file. The investigation continues…
Using the class path resolution to your advantage
Sunday, January 13th, 2008 | actionscript, flex | No Comments
Heres a interesting, albeit questionable hack when extending flex classes that cockblock you with a private property or require you to extend several classes when you just want to tweak 1 line of insignificant code in the component.
You can grab the class you want to tweak and copy it to your project folder, mirroring its package with the appropriate folders. When classes get resolved your project folder gets checked before default system paths so your edited version will get compiled in.
I don’t recommend doing this, probably ever, but its been my best friend when I just wanted to tweak that dark 1 pixel line that the Panel component’s title bar receives via TitleBackground without making it a long and convoluted proccess. I don’t know how well this will work with Flex 3’s framework caching but its nice to know this quick and dirty method is there.
Conditional breakpoint: enterDebugger()
Sunday, January 13th, 2008 | Uncategorized | No Comments
Here’s a handy tip I recalled reading about but never really learned to appreciated until recently. You can run the package level function flash.debugger.enterDebugger anywhere in your code to break out into the flex debugger pragmatically. If you’ve ever had to step through the same break point repeatedly in the same debug session you can just throw this in an if statement instead and save some time and frustration.