robotlegs events get cloned and redispatched on the shared dispatcher but there's no obvious difference between debug and compiled Air in that regard. And the eventMap should be listening directly.
I'm using RL in Air, but it's Air 1.5. But yes - there are Air robotlegs apps, it works just fine in air - not much difference except for the usual air-weirdnesses like not being able to use the stage from sandboxed content etc.
So if you compile a debug air app, and then run it in adl with FDB running, nothing shows in the flashlog?
One thing robotlegs makes it very easy to do - especially if you're using it from source - is to catch your events as they flow through the event dispatcher and then log them to screen in a textfield.
A final thought that might be relevant or might not - race conditions? Everything executes faster in the Air app than in the debugger, so is it possible that your event is firing before the code to catch it has run?
What kind of event is it? Is it an app event or a flash / air native event?
I'm not sure what you mean by a debug air app (vs a release). If I debug from flash builder it does write both to the console and flashlog.txt. When I export the air file it doesn't write to flashlog.txt.
I'd love any guidance from you on tracing stuff through the robotlegs dispatch system to an on screen textfield. that seems to be the next step in figuring out where the breakdown is.
i doubt that its a race condition because the event is fired in response to a button click, so all the app setup stuff should be done by then.
The event fired between the view class and the mediator is just a simple subclass of flash.events.Event that uses constants to define the event type.
Hi Gerry, when you compile the air file, you can set -debug = true or -debug = false (if you're using the command line). Choosing debug in flash builder (or flash IDE) compiles the swf with -debug = true AND then launches the ADL to pick up the trace.
Are you familiar with using the command line for amxmlc / adl / fdb? If you are then I would try that approach first.
On the logging to an onscreen textfield, it can be as simple as handling your event with a logAndDoThings() function, which then also dispatches a LogEvent.EVENT_LOGGED or whatever event on the shared event dispatcher. This LogEvent needs to have one other property - a message - to which you would pass the toString() of the event that triggered it.
Create a view / mediator pairing which is just a textfield (in the view) with a public function like traceToScreen(message:String) which appends the message.
In the mediator, listen for the LogEvent and pass the message to view.traceToScreen(message);
Also make sure that you've overridden clone() in your custom event. That often catches people out (though that should be causing probs in FlashBuilder debug as well so I doubt it's that).
If you're still stuck then I'm back in about 18 hours... maybe someone else will have some ideas too,
As far as the event cloning goes, I specifically didn't override the clone method because all the robotlegs demo projects don't, so i assumed that like bubbling its not necessary. I'll try that, although i'd think that wouldn't break the app only when exported and installed.
thanks for all your help! i'm glad robotlegs has an active community, i think i made the right framework choice for my company's new project.
Support Staff6 Posted by Shaun Smith on 30 Jul, 2010 10:32 AM
If the Robotlegs demos don't override clone() in their events then it is due to an oversight on our part - it is considered best practice to always override clone(), even for non-bubbling events. The Flash Player does not allow one instance of an event to be dispatched more than once, so clone() must be overridden when re-dispatching (for example, when re-dispatching a view event along the event bus).
I'm still working on tracking the event through the framework, but in the meantime I've created a simple project to reproduce the issue. its 1 view, 1 mediator, 1 event, and 1 context. the app is a single button. when you click it, it traces something out and alerts something and sends an event. when the event is caught in the mediator, the mediator traces something out and pops up an alert.
if you import the fxp into flash builder 4.0.1 with the latest air stuff and debug it, you will see that the mediator catches the event and output is traced to flashlog.txt as well as the console.
if you install the included air file you will see that the mediator never pops its alert, and no messages at all are written to flashlog.txt.
i'll continue to try stuff, but i thought that you guys might be able to track this down in 5 minutes. This is starting to smell like either a dumb rookie mistake by me or an air bug.
Support Staff9 Posted by Shaun Smith on 30 Jul, 2010 09:13 PM
The problem was that you were linking against the RL and SwiftSuspenders source without adding the required compiler arguments to keep the metadata from being stripped (the Flex compiler strips all non-standard metadata by default). The RL SWC file includes these compiler arguments for you, but when linking against the source, you need to add them yourself:
Right-click your project, go to Flex Compiler, Additional compiler arguments, and add the following: