Except the memory implications of rendering every row must be considered. And I still haven’t figured out what you’d do for renderers that don’t display any text.
And I’m pretty sure I could write a renderer that you could never figure out which children have text. But given all that, then start copying code from DataGridBase.as. CreateColumnItemRenderer, setupItemRenderer and some calls to validateNow should get the renderer in its “final state”, and code in FocusManager, addFocusables walks children in the two known ways of figuring out your children. If you run into TextFields, pull their text or htmlText and if you run into TextLines.... Not sure what you’ll do there. On 2/13/10 11:22 AM, "Tracy Spratt" <tr...@nts3rd.com> wrote: If you can get what you need easily from a “rendered” renderer, then it sounds like the hidden DG with all of the rows rendered might be the way to go. Tracy Spratt, Lariat Services, development services available ________________________________ From: flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] On Behalf Of Mike Sent: Saturday, February 13, 2010 2:10 PM To: flexcoders@yahoogroups.com Subject: [SPAM] Re: [SPAM] [flexcoders] Obtaining rendered text from a DataGrid I have no control over the dataProvider at all. Performance is not an issue, because the data extraction only happens once, and it can be time-sliced it so the webapp does not appear to freeze. Passing through multiple event handlers, including EnterFrame would be perfectly acceptable. > 3) Depth: Since you have no control over the renderers, you don't have any > way of knowing whether they're composed of containers within containers, etc. True. The routine needs to deal with that. > 4) Layout: Presumably, you want to have the text appear in the same order it > appears in the columns, and then within the individual renderers. There's no > guarantee that your iteration will go from top left to bottom right, so > you'll have to record where the text was found and then arrange it in some > way that tries to make sense (but may not, depending on what is going on in > the renderers). Yes, doing this right will be a lot of work. > 5) Random surprises from the renderer developers. If the renderer developer > makes a reference to its parent, owner, or something else like that and you > instantiate it in a way that doesn't involve a List of some sort, you may > wind up with Null Pointer Exceptions. They may come up with other stuff that > won't come up in your testing with reasonable renderers that you wrote, but > it will be your fault when they do something stupid and YOUR logic errors out. Yep, that is true. > In short, you have to work together with your other team members one way or > another to make this work. There are no other team members. This is a library routine. I want this to be as general as possible, and am prepared to do what it takes to make it work properly. > Why not just shortcut to the most performant method? Performance is not important, general utility is important. The library feature should just work, no excuses. -- Alex Harui Flex SDK Team Adobe System, Inc. http://blogs.adobe.com/aharui
