--- In flexcoders@yahoogroups.com, "Alex Harui" <[EMAIL PROTECTED]> wrote: > > Amy, > > > > Many folks have used HBox as a renderer successfully. Maybe there's > something about repeater that is exposing a problem, but all I can do at > this point is try to offer advice on how to get more information about > the problem. Overriding measure so you can see what it says is a > temporary measure for debugging purposes and a worthwhile pattern to use > in other scenarios. If you're comfortable with the debugger, debug > through the makeRowsAndColumns and see what the renderer is reporting.
The thing is, I don't know what I properly need to include in a measure() function to successfully create the appropriate functionality. I'm actually _not_ comfortable with the debugger, since the step over button sometimes seems to land you in very verbose code where the step out button will then gray out and you are forced to step through it line by line. The debugger is not at all well documented, and I haven't been able to find a way to address this problem which means it can take literally hours to debug the code...your eyes glaze over and you hit step over, step over, oops now that is grayed out, step into, step into, whoops, I was doing it by rote and I missed the bit I was looking for, must start over, etc. > You've been one this list long enough that you are no longer a "newbie" > and should be learning these debugging techniques. That's all very well and good, but when I ask for examples that would help me I get nothing. Sometimes I can "just figure things out" but often I do a lot better with an example in front of me. It's not like I'm lazy or an idiot. I spent about an extra ten hours trying to get this to work in what ought to be a "best practice" way before throwing up my hands and simply calling the method from both dataChange and creationComplete like was working before rather than trying to use callLater. > My last point about recycling was important. Because there is > recycling, it is possible that the repeater is regenerating its children > more than once, which might somehow be related to this problem, and is > likely to cause performance issues for you later. It has _already_ caused issues for me. http://tech.groups.yahoo.com/group/flexcoders/message/110798 But I figured either there was no solution or people on the list didn't find it terribly interesting, so I just accepted the problem. Hours trying to fix it on my own didn't help. > Avoiding the use of > repeater would probably be a good thing. Is the number of children the > repeater generates the same for every row? Does it only vary by a few? > If so, it might be worth skipping repeater and simply declaring the max > set of children and hiding a few. I don't think the problem is in the Repeater. I think the problem is that the HorizontalList is loading its first child several times and that the size information that is coming back out of the HBox isn't getting propogated upwards, like the HorizontalList decides how big it will be before its itemRenderers are finished deciding how big they will be, and I haven't found a way to convince it otherwise. To be honest, after trying to debug a HorizontalList vs. a Repeater, I much prefer the Repeater. At least you're able to directly see what is going on in it. If I had it to do over, I'd have just stuck a repeater in an HBox rather than trying to use a HorizontalList, but I don't have time to rewrite this now. > I can tell from your tone that you've run out of patience, and I wish I > had the quick answer for you, but I don't because use of repeaters in a > renderer isn't that common. I will continue to try to help if you > remain patient with me. I appreciate that :-). It's not so much being out of patience as the fact that I genunely don't know where to look to figure out how to solve this, and I've already spent way too much time trying to do it "right." Maybe I just need to accept that this is an edge case and in this case best practice won't work and just move on with what _will_work. -Amy
