http://www.adobe.com/>
> > > Blog: http://blogs.adobe.com/aharui
> > >
> > > From: flexcoders@yahoogroups.com
[mailto:
> > flexcoders@yahoogroups.com ]
> > On Behalf Of Tim Hoff
> > > Sent: Thursday, May 07, 2009 9:32 PM
> > > To: flexcoders@yahoogr
om/aharui
> >
> > From: flexcoders@yahoogroups.com [mailto:
> flexcoders@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
> &g
coders@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 Sprit
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 s
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 trigge
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 t
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, "Tim Hof
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 in
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 watch
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, Aaron Hardy wrote:
>
> Maybe I'm missing something really fundamental then; I didn't think
> Sprites di
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 Ho
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 localT
12 matches
Mail list logo
