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]
[mailto:[EMAIL PROTECTED] On Behalf Of Mark Doberenz
        Sent: Monday, January 15, 2007 10:31 PM
        To: [email protected]
        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.
        
         
        On 1/15/07, Battershall, Jeff <[EMAIL PROTECTED]>
wrote: 

                
                This is a tough one - and I'm getting a similar behavior
with fileupload - duplicate completion events in subsequent calls to the
same Event/Command/Delegate. I'm having to parse out the duplicates on
the client side and I've yet to determine the culprit.   You'd think
that there's a new instance of each Event, Command and Delegate classes
responding to each gesture, but somehow something is getting persisted
and producing a ghosting effect after the first call to the same class.
The remote object instances in ServiceLocator are getting persisted,
that's for sure, and I don't know if that has anything to do with it. 
                 
                Jeff

                        
                        -----Original Message-----
                        From: [EMAIL PROTECTED] ups.com
<http://ups.com/>  [mailto:[EMAIL PROTECTED] On Behalf Of
Thijs Triemstra 
                        Sent: Monday, January 15, 2007 4:04 PM
                        To: [email protected] <http://ups.com/>

                        Subject: Re: [flexcoders] Cairngorm Duplicate
Remote Object Return Events 
                        
                        
                        I'm having the same problem with NetConnection
and Cairngorm, it triggers more and more NetStatus events everytime I
reconnect to the server. The server doesn't show any reconnects so it's
a clientside thing but not sure why.. I also tried removing the
listeners but nothing changed. 

                        Thijs

                         

                        Op 15-jan-2007, om 19:01 heeft Martin
Wood-Mitrovski het volgende geschreven:


                                

                                > One theory I have about what 'might'
be happening is that before I make
                                > my servce call, I'm adding event
listeners for the result/fault and
                                > these may be duplicate ones, because
the remote object instance is being
                                > persisted in ServiceLocator. However,
I tried explictly removing the 
                                > listeners before adding them and no
dice.
                                
                                sounds like the most likely thing to be
happening.
                                
                                try setting a breakpoint on where you
remove / add the listeners and check that 
                                the references are the ones you expect,
i.e. you are not trying to remove a 
                                different listener or something.
                                
                                

                                

                

                


                 
                
                


         

Reply via email to