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 [email protected], Aaron Hardy <aaronius...@...> 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 [email protected] > > <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 [email protected] > > <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 [email protected] > > <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 [email protected] > > <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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
