Skip to main content
tpf70
Inspiring
Feb 24, 2009 9:23 PM UTC
Answered

contentHeight calculation issue

I have a large flow (about 90k) with a good mixture of text, images and links.

I have a scrollbar that I am using in conjunction with a single controller/container sprite attached to a text area to view the text.

After the flow is loaded, and I compose/updateallcontianers, I set the max of the scrollbar to:
bar.maxScrollPosition = cont.contentHeight-textArea.height;
(I also tried bar.maxScrollPosition = cont.contentHeight as well)

Almost always, the scrollbar ends up having a much larger number than the actual contentHeight.

When the text area resizes, it recalculates all of this, and after a couple of restores and maximizes to the browser, the max scroll position and the contentHeight are in sync.

I tried using composePosition instead of compose, and that had no effect. I tried using composePosition after compose and that had no effect.

I am using Gumbo 5032.

Is this a bug?
I can post code if necessary.
Thanks,
Tim
This topic is closed to new replies. Start a new post to keep the conversation going.
robin_briggsCorrect answer
Adobe Employee
Feb 25, 2009 7:20 AM UTC
The contentHeight is estimated. To get the fully accurate version, you have to call composePosition() prior to getting the contentHeight. If that is not working for you, please let us know -- that's a bug. If you have a code sample, that would be helpful.

Thanks!

- robin
View reply

4 replies

Adobe Employee
robin_briggs
Adobe Employee
Feb 25, 2009 9:14 PM UTC
Glad it worked for you! The composePosition() call is quick if there's nothing to compose, so this should be fine for you. It does a quick check to see if there've been any changes since last compose, and only does the compose in that case.
Translate
Anonymous
Mar 2, 2009 10:09 PM UTC
This worked perfectly for me also. I am currently handling this in a compose complete event handler, where I check if the composed position is less than the textflow's textLength, and call composePosition() if it is. Sounds like I might be better off to move this, though, if that check is already being done for me.

We do notice a considerable decrease in performance, especially in longer textflows, when doing this. This is to be expected, but would be nice if there was a better way to deal with the measuring aspect of things. For now, we're happy to have accurate contentHeight!
Translate
tpf70Author
Inspiring
Feb 25, 2009 9:09 PM UTC
Very interesting development.....

I was doing things to modify the TextFlow,
called compose, updateAllContainers,composePosition in a variety of combinations,

Then performing some other non-related operations
Then accessing the contentHeight.

This code was in a resize handler for my container.

If I resized enough times, eventually the contentHeight would be calculated properly.

This was very confusing.

So after re-reading your posts, I took your advice absolutely literally and called composePosition directly/immediately before I accessed the contentHeight property, and it worked.

So thank you for answering the question and solving the problem.
Translate
Adobe Employee
robin_briggsCorrect answer
Adobe Employee
Feb 25, 2009 7:20 AM UTC
The contentHeight is estimated. To get the fully accurate version, you have to call composePosition() prior to getting the contentHeight. If that is not working for you, please let us know -- that's a bug. If you have a code sample, that would be helpful.

Thanks!

- robin
Translate
Terms & ConditionsAccessibility statement
Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices