If you are just displaying a comma delimited list in a non-editable cell, then labelFunction is the way to go.
If you *use the dataProvider API* to update the item, it will cause the labelFunction to run and re-display the new values. Also, if you find the loop and stay with the itemRenderer, use the set data() method to store your data in a variable and call invalidatePropdrties(), then do the work in commitProperties(). Set data() gets called often, but commitProperties is optimized. Tracy ________________________________ From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Tim Hoff Sent: Monday, July 07, 2008 12:04 PM To: [email protected] Subject: [flexcoders] Re: Item renderers cause processor to max out Ok, that makes sense. One other thing that might be contributing is: updateComplete="setGridHeight(event)" You might want to try: valueCommit="setGridHeight(event)" instead. Good luck Tom, -TH --- In [email protected], "Tom McNeer" <[EMAIL PROTECTED]> wrote: > > Hi Tim, > > Thanks for the reply. > > On Mon, Jul 7, 2008 at 10:54 AM, Tim Hoff [EMAIL PROTECTED] wrote: > > > What are you doing with this event in set data? > > > > dispatchEvent(new FlexEvent(FlexEvent.DATA_CHANGE)); > > > > It's a loop. > > > > > > > > > > You're absolutely correct, of course. Unfortunately, my error was NOT > dispatching that event, but rather including that line in the code I sent in > my post. > > In the actual code, that line is commented out (it came from an earlier > attempt). Yet I still seem to be generating a loop somewhere. > > Thanks for catching it though. It made the post even more confusing. > > -- > Thanks, > > Tom > > Tom McNeer > MediumCool > http://www.mediumcool.com > 1735 Johnson Road NE > Atlanta, GA 30306 > 404.589.0560 >
