Mark, 
 
Thanks! - I haven't tried this yet, but it looks like you nailed it.
 
Jeff

        -----Original Message-----
        From: flexcoders@yahoogroups.com
[mailto:[EMAIL PROTECTED] On Behalf Of Mark Doberenz
        Sent: Tuesday, January 16, 2007 3:27 PM
        To: flexcoders@yahoogroups.com
        Subject: Re: [flexcoders] Cairngorm Duplicate Remote Object
Return Events
        
        
        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: [EMAIL PROTECTED] ups.com
<http://ups.com>  [mailto:[EMAIL PROTECTED] com] On Behalf Of Mark
Doberenz
                                Sent: Tuesday, January 16, 2007 1:54 PM
                                To: [EMAIL PROTECTED] ups.com
<http://ups.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] com <mailto:[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: [EMAIL PROTECTED] ups.com
<http://ups.com>  [mailto: flexcoders@ <mailto:flexcoders@>
yahoogroups.com <http://yahoogroups.com> ] On Behalf Of Mark Doberenz
                                
                                Sent: Tuesday, January 16, 2007 11:50 AM
                                To: [EMAIL PROTECTED] ups.com
<http://ups.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
<jeff.battershall@ dowjones.com <mailto:[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: [EMAIL PROTECTED] ups.com
<http://ups.com>  [mailto: flexcoders@ <mailto:flexcoders@>
yahoogroups.com <http://yahoogroups.com>  ] On Behalf Of Mark Doberenz
                                Sent: Monday, January 15, 2007 10:31 PM
                                To: [EMAIL PROTECTED] ups.com
<http://ups.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. 
                                

                        .
                         
                        


                

                


         

Reply via email to