Alex, as you suspected, makeRowsAndColumns is firing regardless of not scrolling through the list... It seems to fire a variable number of times and is triggered by a couple different methods up the stack trace. Here's the notable methods which are triggering calls to makeRowsAndColumns and I attempt to change state with a transition. I'm still not clear on how to solve this problem so advice is still quite welcome! :-)
Set "details" state the first time - timerHandler - timerHandler Set back to default state the first time - commitCurrentState - doPhasedInstantiation, validateDisplayList - ResizeInstance.onTweenEnd - Tween.timerHandler Set back to "details" state again - commitCurrentState - ResizeInstance.onTweenEnd - Tween.timerHandler - ResizeInstance.onTweenEnd - Tween.timerHandler Set back to default (applies to all successive calls) - Tween.timerHandler Set back to "details" (applies to all successive calls) - Tween.timerHandler Really appreciate the help so far! -James --- In [email protected], "Alex Harui" <[EMAIL PROTECTED]> wrote: > > Yeah, that would affect what you see. Put a breakpoint on > makeRowsAndColumns. If it gets hit during the transition, then you know > recycling is going on. > > > > ________________________________ > > From: [email protected] > [mailto:[EMAIL PROTECTED] On Behalf Of jandersen1978 > Sent: Friday, October 19, 2007 5:47 PM > To: [email protected] > Subject: [flexcomponents] Re: Custom ItemRenderer + variableRowHeight + > states + transitions = not working > > > > It is for List but it's not in Moxie... so you think that recycling > is in fact coming into play huh? hmmm... tricky indeed... so if the > renderer is switched out in the middle of a transition how do you > actually see the transition? Perhaps that's why I'm not seeing the > transition... > > --- In [email protected] > <mailto:flexcomponents%40yahoogroups.com> , "Alex Harui" <aharui@> > wrote: > > > > If this is for List or TileLIst, use Moxie and the dataEffects. > > > > > > > > Anytime the size of a renderer changes, the list class will re-render > > everything on screen and due to recycling will probably switch out the > > renderer under transition. > > > > > > > > ________________________________ > > > > From: [email protected] > <mailto:flexcomponents%40yahoogroups.com> > > [mailto:[email protected] > <mailto:flexcomponents%40yahoogroups.com> ] On Behalf Of jandersen1978 > > Sent: Thursday, October 18, 2007 8:08 PM > > To: [email protected] > <mailto:flexcomponents%40yahoogroups.com> > > Subject: [flexcomponents] Custom ItemRenderer + variableRowHeight + > > states + transitions = not working > > > > > > > > I'm working on a custom item renderer that basically will represent a > > title and then in the "details" state will add an extra paragraph of > > variable length. I'd like the renderer to adjust to the full height > > of the details text and I'd also like to use a resize transition for a > > nice smooth effect. > > > > I've got a custom measure method that sets the width of the title and > > description text components and then uses the textHeight of each to > > set the measuredHeight of the renderer. > > > > What I've got seems to be working until the I add the resize > > transition. When the transitions are added > > 1) the first time the renderer enters the details state it does seems > > to resize correctly and display the full text, however there doesn't > > seem to be any transition--the detail text is shown without a change > > in size and then a second later the size changes appropriately. (not > > quite what I'm going for) > > 2) when the state is set back to default, the renderer does resize > > back to it's original size with a nice smooth transition (good) > > 3) when the state is then set again back to "details" the details text > > is again visible but there is no change in the renderer's size... > > > > I can post code if that's helpful but I'd just love some general > > advice on how to approach this... By the way I'm not scrolling > > through the list so I'm assuming the renderer recycling isn't coming > > into play here... but maybe that's not a good assumption... > > >
