RE: [flexcoders] Re: Tiny components when using callLater()

[Alex Harui]

The measuring renderer is invisible, but on the display list and is held
onto in case of the need for future measuring.

 

itemsNeedMeasurement is protected so you can't access it from the
outside.  You might be able to trick it to being set to true by setting
a style like fontSize

 



From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On
Behalf Of Amy
Sent: Thursday, April 24, 2008 11:46 AM
To: flexcoders@yahoogroups.com
Subject: [flexcoders] Re: Tiny components when using callLater()

 

--- In flexcoders@yahoogroups.com 
, "Alex Harui" <[EMAIL PROTECTED]> wrote:
>
> It would be be considerable work to get the measuring renderer to be 
the
> first renderer, because the first renderer changes as you scroll.

Interesting. Where does that measuring renderer go, then?

> I don't think it should be destroyed, I think you may be seeing two
> renderers (the measuring, and the first visible) that use the same 
data
> object. Like I said, if the number of items is the same in every
> renderer, I would not use repeater since you don't really want to tear
> down and recreate the repeater items.
> 
> 
> 
> Set itemsNeedMeasuremet on the HList.

I haven't subclassed HorizontalList. Can I do that from within my HBox 
itemRenderer? Or can I do that from the Application container?

Thanks;

Amy

 

RE: [flexcoders] Re: Tiny components when using callLater()

[Tracy Spratt]

Repeater has some level of recycling if you set recycleChildren="true"
(default is false).  This has a noticable effect on complex repeated
items.

Tracy

 



From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On
Behalf Of Alex Harui
Sent: Thursday, April 24, 2008 1:38 PM
To: flexcoders@yahoogroups.com
Subject: RE: [flexcoders] Re: Tiny components when using callLater()

 

It would be be considerable work to get the measuring renderer to be the
first renderer, because the first renderer changes as you scroll.

 

I don't think it should be destroyed, I think you may be seeing two
renderers (the measuring, and the first visible) that use the same data
object.  Like I said, if the number of items is the same in every
renderer, I would not use repeater since you don't really want to tear
down and recreate the repeater items.

 

Set itemsNeedMeasuremet on the HList.

 

 



From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On
Behalf Of Amy
Sent: Thursday, April 24, 2008 10:31 AM
To: flexcoders@yahoogroups.com
Subject: [flexcoders] Re: Tiny components when using callLater()

 

--- In flexcoders@yahoogroups.com <mailto:flexcoders%40yahoogroups.com>
, "Alex Harui" <[EMAIL PROTECTED]> wrote:
>
> HorizontalList requires that all items be the same width and 
height. At
> startup, it measures the first one, and uses the measurements for
> columnWidth and rowHeight.

Is there a way to get it to just use the first instance it creates, 
rather than creating it, destroying it, and creating it again? The 
double creation is very expensive, since the object is so deeply 
nested. Obviously, if the draw of the sub-objects doesn't happen, it 
can't figure out how big it needs to be, so even if I could tell the 
difference between a "measurement" draw and a "real" draw it would do 
me no good to defer the draw until the "real" draw.

> If you're subclassing, you can set itemsNeedMeasurement=true and 
call
> invalidateProperties to force a re-measure and new width/height.

Would that be on the itemRenderer or the HorizontalList?

> I haven't looked at your code yet. It's a busy week for me so I'll 
wait
> to hear if you still need me to dig through it.

Naturally, I wouldn't have spent all this time on this if I didn't 
want to do it right, so ultimately I would like to get to the bottom 
of it. But for now it is patched to work acceptably, so if you don't 
have time, you don't have time.

Thanks;

Amy

 

RE: [flexcoders] Re: Tiny components when using callLater()

[Alex Harui]

It would be be considerable work to get the measuring renderer to be the
first renderer, because the first renderer changes as you scroll.

 

I don't think it should be destroyed, I think you may be seeing two
renderers (the measuring, and the first visible) that use the same data
object.  Like I said, if the number of items is the same in every
renderer, I would not use repeater since you don't really want to tear
down and recreate the repeater items.

 

Set itemsNeedMeasuremet on the HList.

 

 



From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On
Behalf Of Amy
Sent: Thursday, April 24, 2008 10:31 AM
To: flexcoders@yahoogroups.com
Subject: [flexcoders] Re: Tiny components when using callLater()

 

--- In flexcoders@yahoogroups.com 
, "Alex Harui" <[EMAIL PROTECTED]> wrote:
>
> HorizontalList requires that all items be the same width and 
height. At
> startup, it measures the first one, and uses the measurements for
> columnWidth and rowHeight.

Is there a way to get it to just use the first instance it creates, 
rather than creating it, destroying it, and creating it again? The 
double creation is very expensive, since the object is so deeply 
nested. Obviously, if the draw of the sub-objects doesn't happen, it 
can't figure out how big it needs to be, so even if I could tell the 
difference between a "measurement" draw and a "real" draw it would do 
me no good to defer the draw until the "real" draw.

> If you're subclassing, you can set itemsNeedMeasurement=true and 
call
> invalidateProperties to force a re-measure and new width/height.

Would that be on the itemRenderer or the HorizontalList?

> I haven't looked at your code yet. It's a busy week for me so I'll 
wait
> to hear if you still need me to dig through it.

Naturally, I wouldn't have spent all this time on this if I didn't 
want to do it right, so ultimately I would like to get to the bottom 
of it. But for now it is patched to work acceptably, so if you don't 
have time, you don't have time.

Thanks;

Amy

 

RE: [flexcoders] Re: Tiny components when using callLater()

[Alex Harui]

HorizontalList requires that all items be the same width and height.  At
startup, it measures the first one, and uses the measurements for
columnWidth and rowHeight.

 

If you're subclassing, you can set itemsNeedMeasurement=true and call
invalidateProperties to force a re-measure and new width/height.

 

I haven't looked at your code yet.  It's a busy week for me so I'll wait
to hear if you still need me to dig through it.

 



From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On
Behalf Of Amy
Sent: Thursday, April 24, 2008 9:30 AM
To: flexcoders@yahoogroups.com
Subject: [flexcoders] Re: Tiny components when using callLater()

 

--- In flexcoders@yahoogroups.com 
, "Amy" <[EMAIL PROTECTED]> wrote:
>
> --- In flexcoders@yahoogroups.com
 , "Alex Harui"  wrote:
> >
> > I'm pretty sure you're not lazy, which is why I'm suggesting that 
> you
> > continue to spend time upgrading your skills at debugging. As 
your
> > applications reach a certain level of sophistication, good 
debugging
> > skills are essential. If someone had an example, they would 
> provide it,
> > but your combination of HList/HBox/Repeater probably isn't common 
> enough
> > for someone to have one handy.
> 
> I notice you didn't step up to "not stupid" LOL. Fair enough :-).
> 
> > I didn't reply to your other post as it seemed like this thread 
was
> > covering both issues. Recycling of renderers has bamboozled lots 
of
> > folks and is usually the cause of problems with the list 
classes. 
> The
> > HList probably isn't loading its first child several times, 
> although it
> > will use the first dataprovider item to do some measurements 
before 
> it
> > uses the item to tell a renderer to display it. But the loop that
> > generates the renderers for display has been quite thoroughly 
used 
> and
> > doesn't use the first item twice. I assume you've proven that the
> > dataProvider doesn't have the first item in there twice.
> 
> I've uploaded my source code as the most efficient way to show you 
> why I think that is happening 
> (ftp://ftp.magnoliamultimedia.com/src.zip
 ). If you get time to 
look 
> at it you may find some other explanation of why the trace on line 
27 
> of GridColumnSolution.mxml runs _twice_ for index zero, but only 
once 
> for the other itemrenderers.
> 
> > Anyway, you want to know if the renderer reports the right size. 
> Try
> > something like
> > 
> > 
> > 
> > override protected function measure():void
> > 
> > {
> > 
> > super.measure();
> > 
> > trace("measured", measuredWidth, measuredHeight);
> > 
> > }
> 
> This looks right.
> 
> > override protected function updateDisplayList(w:Number, 
> h:Number):void
> > 
> > {
> > 
> > trace("udl", w, h);
> > 
> > super.updateDisplayList(w, h)
> > 
> > }
> 
> This is completely wrong (10 and 4 vs. the measured 114 and 238), 
but 
> I don't know enough about why to be able to determine what that 
means.

OK, I did some more research, and it seems that this debugging step 
revealed that my feeling about what was happening is, in fact, 
correct. The itemRenderer knows exactly how big it is, but the 
parent container is not allocating it enough space.

The question I have been asking all along is "how do I convince the 
HorizontalList to rethink how much space it is giving my 
ItemRenderer?" Can anyone out there give me any hints on how to 
convince a parent container to "grow" to support the new size of its 
children?

It would also be really nice to get some hints on how to get the 
HorizontalList to load its first child only once, but I can live with 
the performance hit of having it load twice if there's no way to do 
this.

Thanks;

Amy

 

RE: [flexcoders] Re: Tiny components when using callLater()

[Alex Harui]

I'm pretty sure you're not lazy, which is why I'm suggesting that you
continue to spend time upgrading your skills at debugging.  As your
applications reach a certain level of sophistication, good debugging
skills are essential.  If someone had an example, they would provide it,
but your combination of HList/HBox/Repeater probably isn't common enough
for someone to have one handy.

 

I didn't reply to your other post as it seemed like this thread was
covering both issues.  Recycling of renderers has bamboozled lots of
folks and is usually the cause of problems with the list classes.   The
HList probably isn't loading its first child several times, although it
will use the first dataprovider item to do some measurements before it
uses the item to tell a renderer to display it.  But the loop that
generates the renderers for display has been quite thoroughly used and
doesn't use the first item twice.  I assume you've proven that the
dataProvider doesn't have the first item in there twice.

 

Anyway, you want to know if the renderer reports the right size.  Try
something like

 

override protected function measure():void

{

super.measure();

trace("measured", measuredWidth, measuredHeight);

}

 

override protected function updateDisplayList(w:Number, h:Number):void

{

trace("udl", w, h);

super.updateDisplayList(w, h)

}

 

and see if those numbers make sense to you.  I'm thinking that your
measured numbers are wrong, so you'll need to find out why by adding
other trace statements, maybe like the number of children, the data
object, stuff like that.

 

 

-Alex

 



From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On
Behalf Of Amy
Sent: Tuesday, April 22, 2008 12:35 PM
To: flexcoders@yahoogroups.com
Subject: [flexcoders] Re: Tiny components when using callLater()

 

--- 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 

RE: [flexcoders] Re: Tiny components when using callLater()

[Alex Harui]

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.
You've been one this list long enough that you are no longer a "newbie"
and should be learning these debugging techniques.

 

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.  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 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.

 

-Alex

 



From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On
Behalf Of Amy
Sent: Tuesday, April 22, 2008 7:52 AM
To: flexcoders@yahoogroups.com
Subject: [flexcoders] Re: Tiny components when using callLater()

 

Hi, Alex;

>
> The HBox has been pretty thoroughly debugged, but that doesn't mean 
it
> will work for you in all possible scenarios. A single call to
> validateClient is made then the HBox's measurements are used. 
Anything
> that causes a second validation pass can be missed.
> 
> 
> 
> Calling measure() directly can confuse things as the measurement may
> depend on proper validation of the children. validateClient is
> recommended, but it is being called for you.

Do you have any examples that show the proper way to do this? I've 
looked at the help till my eyes are crossing, and I am just stabbing 
around in the dark trying to figure this out.

> I would override measure() so you can see what numbers it is 
reporting
> and decide whether that is right nor not. If not, then see if the
> repeater is causing a second pass. If it is reporting the right 
number,
> then updateDisplayLIst should be called later with the right number.

I know _you_ would override measure :-), but my feeling is that if 
the code you guys wrote isn't working, what hope does a newbie like 
me have of doing something that works better? Besides, it does seem 
to be working just fine, but the measurements aren't getting 
passed "up the chain" to the containing HorizontalList, and I have no 
idea how to convince that component to "see" that its children are 
larger than it has allowed room for and expand to allow them to be 
seen.

> Also keep in mind that renderers are recycled so the renderer that
> generates some number of children for the first row can end up 
rendering
> some other row later.

The first step is to get everything visible. Then I'll worry about 
what happens when new items are added to the collection (which is the 
only reason the items that are being rendered would change).

Thanks;

Amy

 

RE: [flexcoders] Re: Tiny components when using callLater()

[Alex Harui]

The HBox has been pretty thoroughly debugged, but that doesn't mean it
will work for you in all possible scenarios.  A single call to
validateClient is made then the HBox's measurements are used. Anything
that causes a second validation pass can be missed.

 

Calling measure() directly can confuse things as the measurement may
depend on proper validation of the children.  validateClient is
recommended, but it is being called for you.

 

I would override measure() so you can see what numbers it is reporting
and decide whether that is right nor not.  If not, then see if the
repeater is causing a second pass.  If it is reporting the right number,
then updateDisplayLIst should be called later with the right number.

 

Also keep in mind that renderers are recycled so the renderer that
generates some number of children for the first row can end up rendering
some other row later.

 

-Alex

 



From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On
Behalf Of Amy
Sent: Monday, April 21, 2008 7:46 PM
To: flexcoders@yahoogroups.com
Subject: [flexcoders] Re: Tiny components when using callLater()

 

--- In flexcoders@yahoogroups.com 
, "Alex Harui" <[EMAIL PROTECTED]> wrote:
>
> The renderer's size is dictated by how its measurements come out. I'd
> debug the measure() method and see why it isn't computing correctly. 
In
> theory, setting the dp on dataChange shouldn't matter as it is after
> dataChange that the repeater items and then its containing component
> should get measured.

My renderer is based on HBox, so I would presume the code has been 
thoroughly debugged (or hope it has, anyway).

I added this function

private function finished():void{
invalidateSize();
invalidateProperties();
invalidateDisplayList();
measure();
width=measuredWidth;
height=measuredHeight;
}

that I call on repeatEnd.

When I step through the code, the width and height are being set 
properly, but it doesn't display properly. It seems like the 
HorizontalList that contains the component doesn't get the memo.

I've been experimenting with ways to try to get the information to 
update the HorizontalList, but I haven't had much success. The only 
event that looks vaguely useful is updateComplete. This gets called 
twice, apparently. The first is before the components are fully drawn, 
and the other traces out after the trace statements that happen when 
the components are drawing. However, when I trace the measuredHeight 
andmeasuredWidth of the children of the ListBaseContentHolder, the 
values don't seem to be the same as what they were set in the above 
code.

Thanks;

Amy