This all sounds like overkill; since you are really only interested in UIComponentB knowing the position of SpriteC. If you make SpriteC public, is it possible to bind the x/y values for UIComponentB to uiComponentA.spriteC.x and y (localToContent)?
-TH --- In flexcoders@yahoogroups.com, Alex Harui <aha...@...> wrote: > > If you can use a subclass of Sprite that dispatches the events you need, that will be the least expensive solution in terms of CPU usage. If you can't use a subclass or you won't have so many Sprites that polling will matter, polling will probably be sufficient. > > Alex Harui > Flex SDK Developer > Adobe Systems Inc.<http://www.adobe.com/> > Blog: http://blogs.adobe.com/aharui > > From: flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] On Behalf Of Tim Hoff > Sent: Thursday, May 07, 2009 9:32 PM > To: flexcoders@yahoogroups.com > Subject: [flexcoders] Re: Tracking a sprite's position > > > > > > My thought was that since all of the Sprites of UIComponentA were > children, they would invalidate the display list of UIComponentA > whenever they were changed. I forget that Sprites are their own beast. > If you can't find a way to listen for changes to all of the Sprite's > position/size, and trigger action on the common canvas, enterframe > starts to sound more and more appealing. I'm still wondering though, > what you plan to do onEnterFrame, in order to re-position UIComponentB. > For a parent or sibling to know about a component's state (or it's > children), events and public vars/methods are usually employed. I'm > interested to hear what you end up doing for this edge-case. > Challenging for me, I can say. > > -TH > > --- In flexcoders@yahoogroups.com<mailto:flexcoders%40yahoogroups.com>, Aaron Hardy aaronius9er@ wrote: > > > > What would be invalidating UIComponent A's display list? It's my > > understanding that if Sprite B were to be scaled (which is likely--it > is > > a graphic editing app afterall) but not Sprite A, the display list of > > UIComponent A would never be invalidated, so updateDisplayList > wouldn't > > be called in that case. The same is true if Sprite C were scaled or > > moved but not any members of its parent chain. Yet UIComponent B still > > needs to stay stuck to Sprite C. Again, I definitely could be wrong. > > > > I guess the simple answer would be to make any tool or button or > > anything that scales or moves anything inside UIComponent A trigger > > UIComponent B to update its location, but I can already think of quite > a > > fiew places that would have to happen and it seems like future > > developers would intrinsically have to know that if they make a new > tool > > that modifies the position/scale of any of the elements that they need > > to trigger UIComponent B to update its position. Ugh. That's what I'm > > trying to avoid. > > > > Keep 'em coming if you've got 'em. It's not a dire situation so I'll > > save my dire need credits for later if needed. :) > > > > Aaron > > > > Tim Hoff wrote: > > > > > > > > > > > > Actually, in thinking about it a bit more, why not dispatch a custom > > > event in the updateDisplayList function of UIComponentA; that > contains > > > the coordinates of SpriteC. This will happen a lot less frequently > than > > > listening for the enterFrame event. > > > > > > -TH > > > > > > --- In flexcoders@yahoogroups.com<mailto:flexcoders%40yahoogroups.com> > > > <mailto:flexcoders%40yahoogroups.com>, "Tim Hoff" TimHoff@ wrote: > > > > > > > > > > > > Batting .000 so far. The only other thing that I can think of, is > to > > > > move UIComponentB into UIComponnentA, same level as SpriteC, and > bind > > > > the position of UIComponentB to the x and y (plus any offset) of > > > > SpriteC. Sorry that I couldn't have offered more useful help. It > > > > sounds like you have an interesting use-case. Good luck Aaron. > > > > > > > > -TH > > > > > > > > --- In flexcoders@yahoogroups.com<mailto:flexcoders%40yahoogroups.com> > > > <mailto:flexcoders%40yahoogroups.com>, Aaron Hardy aaronius9er@ > wrote: > > > > > > > > > > Unfortunately that isn't a great option in our case. The sprite > in > > > > > question is part of a graphical editor where dozens and dozens > of > > > > > sprites may be on the stage and they only provide a simple > graphical > > > > > representation so converting them to uicomponents would probably > be > > > > more > > > > > overkill than watching the sprite's position on each > enter_frame. If > > > > > you come up with any other ideas, please let me know. > > > > > > > > > > Aaron > > > > > > > > > > Tim Hoff wrote: > > > > > > > > > > > > > > > > > > > > > > > > No, you're right. My suggestion was more theoretical more than > > > > anything > > > > > > else. You may need to change the Sprites to UIComponents; to > get > > > > those > > > > > > events. > > > > > > > > > > > > -TH > > > > > > > > > > > > --- In flexcoders@yahoogroups.com<mailto:flexcoders%40yahoogroups.com> > > > <mailto:flexcoders%40yahoogroups.com> > > > > > > <mailto:flexcoders%40yahoogroups.com>, Aaron Hardy > aaronius9er@ > > > > > > wrote: > > > > > > > > > > > > > > Maybe I'm missing something really fundamental then; I > didn't > > > > think > > > > > > > Sprites dispatched move and size events and the > documentation > > > > doesn't > > > > > > > show any such events either. I'll do some more research > later, > > > but > > > > > > > please correct me if you know something I don't. > > > > > > > > > > > > > > Thanks for the response. > > > > > > > > > > > > > > Aaron > > > > > > > > > > > > > > Tim Hoff wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Using enterFrame is pretty expensive. I'd probably listen > for > > > > > > SpriteC's > > > > > > > > move and resize events in the common canvas and position > > > > > > UIComponentB; > > > > > > > > based on the event.currentTarget.x and y coordinates. The > > > events > > > > > > will > > > > > > > > have to be bubbled up from SpriteC to UIComponentA to the > > > common > > > > > > canvas. > > > > > > > > Use localToGlobal to find the desired coordinates to > position > > > > > > > > UIComponentB. You might experience a little lag; so the > two > > > may > > > > not > > > > > > > > look like they are connected though. > > > > > > > > > > > > > > > > -TH > > > > > > > > > > > > > > > > --- In flexcoders@yahoogroups.com<mailto:flexcoders%40yahoogroups.com> > > > <mailto:flexcoders%40yahoogroups.com> > > > > > > <mailto:flexcoders%40yahoogroups.com> > > > > > > > > <mailto:flexcoders%40yahoogroups.com>, Aaron Hardy > > > aaronius9er@ > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > Hey flexers, > > > > > > > > > > > > > > > > > > I have Sprite C which is inside of Sprite B which is > inside > > > of > > > > > > Sprite > > > > > > > > A > > > > > > > > > which is inside of UIComponent A. UIComponent A and > > > > UIComponent B > > > > > > are > > > > > > > > > both children of a common Canvas. I need UIComponentB to > > > > always be > > > > > > > > > positioned over the top-left of Sprite C (so it appears > to > > > be > > > > > > stuck to > > > > > > > > > Sprite C). ALWAYS. So if Sprite C is scaled or moved, if > > > > Sprite B > > > > > > is > > > > > > > > > scaled or moved, if Sprite A is scaled or moved, if > > > > UIComponent A > > > > > > is > > > > > > > > > scaled or moved or ANYTHING happens that would affect > Sprite > > > > C's > > > > > > > > > position, I need UIComponent B to always follow its > > > position. > > > > Is > > > > > > there > > > > > > > > > a good way to do this? My first thought is to poll > SpriteC's > > > > > > > > > coordinates on every enterFrame event, but it seems like > it > > > > might > > > > > > be > > > > > > > > > overkill. Thoughts? > > > > > > > > > > > > > > > > > > Thanks! > > > > > > > > > > > > > > > > > > Aaron > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
