views:

22

answers:

2

I have a situation with our silverlight 3 application where the initial load of the main application page shows the browsers horizontal scroll bar.

The width and height of the silverlight control are such that I should get a vertical scroll bar (which I do) and no horizontal scroll bar.

We have a BrowserScrollHelper class that is being used to transfer the silverlight controls size to the containing HTML element on PageLoad and PageResize, as per discussions raised in this post http://forums.silverlight.net/forums/p/26996/442817.aspx.

If I then maximise/restore the browser window, the horizontal scroll bar disappears. It's only the initial page load that doesn't seem to be able to determine the initial requirement state of the horizontal scroll bar.

I know I can use the CSS property overflow-x: hidden to remove the scroll bar but this is just masking the problem. Besides, at the moment the application doesn't need to scroll horizontally but I can't guarantee that this will always be the case.

Constraints to be noted. IE8 is browser of choice, screen resolution is locked in at 1024x768.

A: 

I have seen random extra pieces of display being generated by the browser (IE 8) and have not been able to track it down.

Specifically a strip 8 pixels high at the screen bottom was causing the vertical scrollbar to appear (although the SL object was at 100% and not other elements were present).

In the end I changed the overflow property to hidden. It is perfectly valid to use that hidden option in any CSS browser (i.e. anything that runs SL), so do not worry too much about it being "bad".

I would however also be interested in any other answers that help track the actual cause of these glitches.

Enough already
A: 

Managed to work out what was happening with the scroll bars.

The code in our BrowserScrollHelper that we were using to communicate the silverlight control's size back to the browser was using this code:

     double clientWidth = BrowserScreenInformation.ClientWidth;
     double clientHeight = BrowserScreenInformation.ClientHeight;

     double width = Math.Max( clientWidth, this.MinWidth );
     double height = Math.Max( clientHeight, this.MinHeight );

     htmlElement.SetStyleAttribute( "height", height.ToString( ) );
     htmlElement.SetStyleAttribute( "width", width.ToString( ) );

While this code snippet looks OK on the surface it was only doing part of the job. The key was in realising that setting the height may affect the width and vice-versa, and we were only running through this code once on application startup.

The resolution was to follow the pattern of either:

Set Height, Set Width, Set Height

OR

Set Width, Set Height, Set Width

This ensured that a single pass through the code would correctly communicate the silverlight control's size back to the browser giving it a chance to get the vertical and horizontal scroll bars correct.

The working code looks like this:

     double clientHeight = BrowserScreenInformation.ClientHeight;
     double height = Math.Max( clientHeight, this.MinHeight );
     htmlElement.SetStyleAttribute( "height", height.ToString( ) );

     double clientWidth = BrowserScreenInformation.ClientWidth;
     double width = Math.Max( clientWidth, this.MinWidth );
     htmlElement.SetStyleAttribute( "width", width.ToString( ) );

     clientHeight = BrowserScreenInformation.ClientHeight;
     height = Math.Max( clientHeight, this.MinHeight );
     htmlElement.SetStyleAttribute( "height", height.ToString( ) );

In our case the end user is mostly likely to launch the browser maximised and leave it in that configuration for the entire session and not perform any resizing of the browser window.

Lou