Skip to Content

Introduction

Some time ago I had posted an entry that describes how to mimic FormattedTextView control (WD ABAP) in WebDynpro for Java using IFrame. This post explains how to adjust size of IFrame control to fit size of content.

When I were writing my entry Display formatted text using WebDynpro for Java I planned myself to include some script that will automatically adjust outer frame container to fit size of inner IFrame content. However, I’d stuck with this. I could not manage to write unobtrusive code, that does not hijack internals of WebDynpro HTML client rendering. It either was necessary to use WD-generated IDs of HTML elements or accept not reliable or not generic solution.

Later I came across the following Re: Resize IFrame by Cindy Herman. After short forum/e-mail conversation she shares her magic script with me. And this script contains really insightful thing that I’d overlooked previously: there is frameElement reference on window object, if window object is an IFrame. And this reference point to HTML element that holds frame object itself. Bingo!

Full resize

So here is first variant of script for inner IFrame. This script adjusts both width and height of IFrame container, so content is fully visible:

 

 

There are 3 important points:

  1. When adjusting width, we have to check both scrollWidth and offsetWidth for Internet Explorer. Also there is no explicit branching for IE, Math.max expression has effect only Redmond’s child, while in “right browsers” offsetWidth <= scrollWidth always.
  2. Again, our good old (very old, btw 😉 MS beast fails to render correctly from the first call. Heck knows why, probably IE performs some size calculations only when actually rendering content. Nevertheless, we just use Timeout to repeat our operation once again and everything looks ok. Hint: all events handler and rendering code are executed on same thread in every browser, so we need to use timeout to let some internal IE “draw” method execute.
  3. Sometimes in Mozilla/Firefox scrollbar is still drawn even if we adjust heigth to exact content height. Hence I’ve added one pixel as workaround to this silly bug.

Well, while this variant is usable, it is more common to just remove vertical scroll bar and let content flow with main window resize.

Flexible width, no vertical scrolling

 

 

Here we need to track “resize” event in browser. Also here we do not alter width in any way, so by default our content will occupy all available width of outer HTML element. What is important here?

  1. We need to track horizontal scroller anyway, if it is present we need to adjust total hiegth of outer container by this delta
  2. Now Firefox plays “interesting game” here – we need first to decrease height to some small value, and then apply “real” height. This trick is used to get correct scrollHeight when we are resizing main window from smaller size to bigger. Resizing in opposite direction works without this trick.

Download JAR archive file to get working examples of both techniques

Btw, two words to those who are visiting SDN World:

  • Thank you! To all of 600 users registered as at time of writing this post.
  • Use Firefox! When I were optimizing performance I noticed that Firefox on this page works 5-7 times faster then Internet Explorer due to inherent performance problems with DOM node manipulations in Internet Explorer. Even “plain” JavaScript (simple loops, array operations etc) works 1.5 – 3 times faster.
To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply