Skip to main content
T
tpf70
Inspiring
February 24, 2009
Answered

contentHeight calculation issue

  • February 24, 2009
  • 3 replies
  • 931 views
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 has been closed for replies.
Correct answer robin_briggs
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

3 replies

R
Adobe Employee
robin_briggs
Adobe Employee
February 25, 2009
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.
A
Anonymous
March 2, 2009
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!
T
tpf70Author
Inspiring
February 25, 2009
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.
R
Adobe Employee
robin_briggsCorrect answer
Adobe Employee
February 25, 2009
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
Terms & ConditionsAccessibility statement
Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices