--- In [email protected], "Ralf Bokelberg"
<[EMAIL PROTECTED]> wrote:
>
> Haha Amy, that's a good one. Maybe it should :)
>
> But seriously, dispatchEvent is nothing more than a function call,
> which calls all the event handler methods. Of cause you can think of
> pathologic examples like Paul likes to do :) But this is really the
> same with function calls. It is completely synchronous and there is
> nothing like "three lines later it does something strange to my
code".
> It would be really bad, if something like this could happen.
>
> I would be happy to reconsider, if you can provide me with a
example,
> which does what you were seeing.
I'm doing this from memory, because it looks like the client is
working on how the search functionality works, but here's the place
that the functionality broke:
protected function profilePageLoaded(e:CollectionEvent):void{
/* Make sure we don't keep triggering
this function for an old
SearchProfiles */
var coll:ArrayCollection=e.currentTarget as
ArrayCollection;
coll.removeEventListener
(CollectionEvent.COLLECTION_CHANGE, profilePageLoaded);
dispatchEvent(new Event(PROFILES_CHANGED));
//ok to load a new page of results on
whatever SearchProfile is current
_isGettingProfiles=false;
updateCache();
//check current _searchProfiles to see if we
need to load more pages
if
(_searchProfiles.loadedProfiles<_searchProfiles.profileCount)
loadPageOfProfiles();
}
Note that the _isGettingProfiles switch is still _after_ the
dispatchEvent code. I moved it there from after updateCache (which
doesn't care about or change this value), because when I had it
_below_ that, the dispatchEvent would cause other code to execute the
function that registers for this event again...but it wouldn't
register for the event because that variable was still true. By
moving it up a line (but still after the dispatchEvent, since that's
where I felt it was more understandable for the people that have to
maintain the code), it still executed before the event listener
kicked in.
Hope this clarifies;
Amy
