tag:robotlegs.tenderapp.com,2009-10-18:/discussions/problems/137-problem-with-events-and-air-applicationRobotlegs: Discussion 2013-04-28T10:00:32Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/24117802010-07-29T19:02:29Z2010-07-29T19:02:29Zproblem with events and air application<div><p>Hi Gerry,</p>
<p>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.</p>
<p>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.</p>
<p>So if you compile a debug air app, and then run it in adl with
FDB running, nothing shows in the flashlog?</p>
<p>That's freaky.</p>
<p>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.</p>
<p>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?</p>
<p>Sounds frustrating!</p>
<p>What kind of event is it? Is it an app event or a flash / air
native event?</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/24117802010-07-29T21:05:12Z2010-08-27T19:20:08Zproblem with events and air application<div><p>Hi Stray,</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>thanks,</p>
<p>gerry</p></div>Gerry Kohtag:robotlegs.tenderapp.com,2009-10-18:Comment/24117802010-07-29T21:23:51Z2010-07-29T21:23:51Zproblem with events and air application<div><p>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.</p>
<p>Are you familiar with using the command line for amxmlc / adl /
fdb? If you are then I would try that approach first.</p>
<p>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.</p>
<p>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.</p>
<p>In the mediator, listen for the LogEvent and pass the message to
view.traceToScreen(message);</p>
<p>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).</p>
<p>If you're still stuck then I'm back in about 18 hours... maybe
someone else will have some ideas too,</p>
<p>Stray</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/24117802010-07-29T22:41:43Z2010-08-27T19:20:08Zproblem with events and air application<div><p>Thanks Stray,</p>
<p>I'll try out your suggestions and report back.</p>
<p>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.</p>
<p>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.</p>
<p>g</p></div>Gerry Kohtag:robotlegs.tenderapp.com,2009-10-18:Comment/24117802010-07-30T10:32:45Z2010-07-30T10:32:45Zproblem with events and air application<div><p>Hi Gerry,</p>
<p>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).</p></div>Shaun Smithtag:robotlegs.tenderapp.com,2009-10-18:Comment/24117802010-07-30T18:23:35Z2010-08-27T19:20:08Zproblem with events and air application<div><p>Hi helpful support folks,</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>thanks,</p>
<p>gerry</p></div>Gerry Kohtag:robotlegs.tenderapp.com,2009-10-18:Comment/24117802010-07-30T18:52:46Z2010-07-30T18:52:46Zproblem with events and air application<div><p>Hi Gerry, I'd love to help but I use project sprouts / the sdk so I don't have flash builder.</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/24117802010-07-30T21:13:17Z2010-07-30T21:13:17Zproblem with events and air application<div><p>Hi Gerry,</p>
<p>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:</p>
<p>Right-click your project, go to <code>Flex Compiler</code>, <code>Additional compiler arguments</code>, and add the following:</p>
<p><code>-keep-as3-metadata+=Inject -keep-as3-metadata+=PostConstruct</code></p>
<p>After doing so, the debug and release versions run the same for me. It's weird (and slightly annoying) that the compiler kept the metadata for the debug version in the first place.</p></div>Shaun Smithtag:robotlegs.tenderapp.com,2009-10-18:Comment/24117802010-07-30T21:14:41Z2010-07-30T21:14:41Zproblem with events and air application<div><p>By the way, trace statements are removed by the compiler when doing a release build.</p></div>Shaun Smithtag:robotlegs.tenderapp.com,2009-10-18:Comment/24117802010-07-30T22:03:00Z2010-08-27T19:20:09Zproblem with events and air application<div><p>Thanks Shaun,</p>
<p>That totally worked! BTW, is this kind of stuff captured anyway? As a robotlegs noob I'm sure I'll run into other things like this.</p>
<p>You guys rock,</p>
<p>g</p></div>Gerry Kohtag:robotlegs.tenderapp.com,2009-10-18:Comment/24117802010-07-30T22:12:01Z2010-07-30T22:12:01Zproblem with events and air application<div><p>It's a pleasure, glad you're back on track!</p>
<p>Yes, all public issues are captured into this knowledgebase to help with future trouble shooting :)</p></div>Shaun Smith