The FC64 Open Source Commodore 64 Emulator for Flash that Claus and I created is a finalist for "Technical Merit" in this year's Flashforward Film Festival.
If you have some time and don't mind showing your support, we'd really appreciate a vote for the People's Choice award. As Jesse would say, "FC64 4 teh win!!!".
Thanks!
A friend of mine had been using the standalone version of FlexBuilder 2 and recently switched to the plugin version. He noticed that the IDEs looked different - the standalone version sported the Windows XP theme, whereas the plugin version didn't.
This isn't so much of a FlexBuilder trick as just a regular Eclipse trick. Because Eclipse is built on SWT, the widgets have the ability to take on the native look of the underlying operating system. The problem is that on Windows they default to the classic look.
The solution is a file named javaw.exe.manifest. In order to instruct SWT to draw with the Windows XP theme, the manifest file needs to placed next to the javaw.exe file that is used to launch Eclipse. By default, Adobe has taken care of this for you with the standalone version of FlexBuilder 2. If you're using a regular Eclipse installation with the plugin version of FlexBuilder 2, you have to do this step yourself.
It's an easy fix. Download javaw.exe.manifest from Eclipse.org and simply place it in the directory where javaw.exe is located. On my system, this was in C:\WINDOWS\system32. A simple restart of Eclipse does the trick and loads the Windows XP theme for the UI widgets.
There's been some talk lately on FlexCoders about Cairngorm's Responder interface and how to use it to handle results from a remote service. Personally, I don't use Cairngorm's Responder. Instead, I use the mx.rpc.IRsponder interface.
The differences are subtle, but I prefer IResponder for the following reasons:
To understand the last two points, some background on Cairngorm's Responder is needed. Cairngorm's Responder interface has two public methods:
public function onResult(event:* = null):void public function onFault(event:* = null):void
Typically, commands that you create inside of the Cairngorm framework will implement this interface. Commands generally make a remote method call and handle the results of that call all in one place. Every command that makes a remote method call will adhere to the Responder interface and define an onResult and onFault method.
In order to use the Responder interface though, you need a little bit of glue-code behind the scenes. When you define the remote service you have to explicitly add a result and a fault listener in the tag, like this:
// In Services.mxml <mx:RemoteObject id="someService" result="event.token.resultHandler( event )" fault="event.token.faultHandler( event )" ... />
Here you're saying that every result should invoke the resultHandler method and every fault should invoke the faultHandler (passing along the actual event object with it).
The call to the remote service normally happens in a business delegate. An example business delegate class looks something like this:
