Tim, I would need to test it out, but off the top of my head I don't think binding would do the job. Let's say Sprite A was scaled up. Even though Sprite C's coordinates in relation to UIComponent B have changed, its actual coordinates in relation to Sprite B (its parent) have not changed, therefore I don't think any bindings would trigger.
Alex, that would work. I won't be able to just watch the event coming from Sprite C since it may actually be one of its parents that changes its scale or position, but if I take a broader approach of where I watch for bubbling events I think it would do the trick. Its unfortunate I can't do it just with regular sprites but I guess that's why they're lightweight. Thanks guys. I don't want to use much more of your time. I really appreciate your input and you've given me some good fuel to work with. Aaron On Thu, May 7, 2009 at 11:40 PM, Tim Hoff <timh...@aol.com> wrote: > > > > 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 <flexcoders%40yahoogroups.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 <flexcoders%40yahoogroups.com> [mailto: > flexcoders@yahoogroups.com <flexcoders%40yahoogroups.com>] > On Behalf Of Tim Hoff > > Sent: Thursday, May 07, 2009 9:32 PM > > To: flexcoders@yahoogroups.com <flexcoders%40yahoogroups.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 <flexcoders%40yahoogroups.com><mailto: > flexcoders%40yahoogroups.com <flexcoders%2540yahoogroups.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 <flexcoders%40yahoogroups.com><mailto: > flexcoders%40yahoogroups.com <flexcoders%2540yahoogroups.com>> > > > > <mailto:flexcoders%40yahoogroups.com<flexcoders%2540yahoogroups.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 <flexcoders%40yahoogroups.com><mailto: > flexcoders%40yahoogroups.com <flexcoders%2540yahoogroups.com>> > > > > <mailto:flexcoders%40yahoogroups.com<flexcoders%2540yahoogroups.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 <flexcoders%40yahoogroups.com><mailto: > flexcoders%40yahoogroups.com <flexcoders%2540yahoogroups.com>> > > > > <mailto:flexcoders%40yahoogroups.com<flexcoders%2540yahoogroups.com> > > > > > > > > > <mailto:flexcoders%40yahoogroups.com<flexcoders%2540yahoogroups.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 <flexcoders%40yahoogroups.com><mailto: > flexcoders%40yahoogroups.com <flexcoders%2540yahoogroups.com>> > > > > <mailto:flexcoders%40yahoogroups.com<flexcoders%2540yahoogroups.com> > > > > > > > > > <mailto:flexcoders%40yahoogroups.com<flexcoders%2540yahoogroups.com> > > > > > > > > > > > <mailto:flexcoders%40yahoogroups.com<flexcoders%2540yahoogroups.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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
