OK, I was able to finally get somewhere with this... Here's what I was using in my Delegate in the login method...
var call:AsyncToken = service.login(username, password); service.addEventListener(ResultEvent.RESULT, responder.result); service.addEventListener(FaultEvent.FAULT, responder.fault); The problem was adding the event listeners to the service node... not a good idea, but like I said earlier, this is how Sam Shrefler was doing it on his tutorial. Here's what I changed it to... var call:AsyncToken = service.login(username, password); call.addResponder(responder); Now, I'm only getting one result every time I call the method. Hope this helps someone else. Mark On 1/16/07, Thijs Triemstra <[EMAIL PROTECTED]> wrote:
I'm using Cairngorm 2.1 here so I don't think it's something that changed in the newest version.. :( Your idea of the UID sounds like it will work but I'd prefer not send extra data back and forth and it also won't clean up these redundant event notifications.. It seems that cairngorm creates new instances of the delegate/event listeners etc every time, maybe there is a way to find a unique reference for them that you can use to filter out the extra events? but I guess that still creates a memory problem and the application will get slow after a while, something that would easily happen in a chatroom application for example.. question is: how does someone kill these event listeners with cairngorm? Thijs Op 16-jan-2007, om 20:08 heeft Battershall, Jeff het volgende geschreven: Well using mx.utils.UIDUtil.createUID() to give each RO call a unique marker and then checking for a match on result is a way to go, biut it certainly feels kludgey. I'd like to see some input from the Adobe consulting folks - perhaps this has been addressed in Cairngorm 2.1 - I'm using 2.0. -----Original Message----- *From:* flexcoders@yahoogroups.com [mailto:flexcoders <flexcoders>@ yahoogroups.com] *On Behalf Of *Mark Doberenz *Sent:* Tuesday, January 16, 2007 1:54 PM *To:* flexcoders@yahoogroups.com *Subject:* Re: [flexcoders] Cairngorm Duplicate Remote Object Return Events You're right, I was just calling them duplicate events, but repeated ones from earlier events is a much better way to say it. I'm coding up a Fluorine app for the middleware... I'm not all that sure how to use CF :( I'm basing my Flex app off of Sam Shrefler's Flex 2, Cairngorm, Fluorine tutorial: http://blog. <http://blog.shrefler.net/?p=10>shrefler.net/?p=10 Maybe his code needs to be tweaked for Flex 2.0.1 ?? Mark On 1/16/07, Battershall, Jeff <[EMAIL PROTECTED]> wrote: > > > Mark, > > Interesting discussion - interesting problem. BTW, I don't think these > return events are really 'duplicates' per se, but repeats of the earlier > return events. LIke > > First invoke > > returns event1 > > Second invoke > > returns event1 then event2 > > etc. > > Out of curiosity, what middleware are you using? I'm using CFMX 7.02. > > Jeff > > -----Original Message----- > *From:* flexcoders@yahoogroups.com [mailto: [EMAIL PROTECTED] > *On Behalf Of *Mark Doberenz > *Sent:* Tuesday, January 16, 2007 11:50 AM > *To:* flexcoders@yahoogroups.com > *Subject:* Re: [flexcoders] Cairngorm Duplicate Remote Object Return > Events > > OK, so maybe having a Singleton delegate wouldn't be a good idea. > > Here's a bit more I've found on the topic. > > I put a breakpoint at the Command result method and found that the > address location for the commands were changing. So, essentially, the > commands are being persisted which in turn are persisting new instances of > the delegate and the event listeners that are a part of those delegates. > Removing the event listener in the delegate first won't work because the > memory locations of the responder (the command) are changing. > > Essentially, every time you create a new cairngorm event, you will > create new instances of the delegate and then the event listeners, so the > same result will fire the event listeners multiple times when you've created > multiple cairngorm events. > > That's at least my take on the issue. > > I have an app where I'm trying to perform a LoginEvent and I noticed > that every time I hit the Login button, I was creating a new LoginEvent and > so the more I tried to login, the more results I was getting back. I tried > making the LoginEvent a private var on the view, and that seemed to work the > first time, but after that it wasn't passing the user data anymore. Not > sure what that's about. > > I don't like this fix because it would mean that there's only one > instance of each of the cairngorm events in the whole app. > > > On 1/16/07, Battershall, Jeff <[EMAIL PROTECTED] > wrote: > > > > > > I'm not sure a singleton delegate would do the trick - and then you > > might have threading issues - right? I'm kind of suspicious of the fact that > > the RO instances are being persisted in the singleton ServiceLocator. It's > > those RO instances' methods that are getting listeners attached to them. > > > > I'm going to try a couple of things - one is to explictly remove the > > event listener when the result comes over the wire. I've determined this - > > the remote object is invoked only once outgoing from Flex. It is the > > duplicate result events that are happening. > > > > One way to work around this would be to add a unique token to the rpc > > call as described in the Flex docs (search ACT in the Flex Dev guide) and > > only execute your return code when the token matches the one coming over the > > wire. I'm going to experiment with that as well. I think this may well be > > some sort of scoping issue caused by the level of abstraction that the > > Cairngorm framework stipulates. > > > > -----Original Message----- > > *From:* flexcoders@yahoogroups.com [mailto: [EMAIL PROTECTED] > > *On Behalf Of *Mark Doberenz > > *Sent:* Monday, January 15, 2007 10:31 PM > > *To:* flexcoders@yahoogroups.com > > *Subject:* Re: [flexcoders] Cairngorm Duplicate Remote Object Return > > Events > > > > I was seeing this same thing today with some stuff I was working > > on. I hadn't spent any time trying to remove the event listeners before > > adding them again though. So, I don't know if that would work, but > > apparently not. > > I wonder if the delegate should actually be set up as a Singleton so > > that multiple instances of the delegate weren't floating around cathing the > > events every time. This way, you could guarantee that only one instance was > > being used. Just a thought. > > > > I don't have the code in front of me, but if you're reinstanciating > > the delegate every time the command is called, then this could explain it. > > > > Try setting a breakpoint in your delegate and look at the memory > > address for "this" and see if it's changing each time the delegate's called. > > > > .
