Hello Dave,

I do not think that this issue is related with WebHierarchicalDataGrid.

It is more IE7 oriented. You can achieve the Firefox behavior by setting the style of the div.

<div style="height: 100%; width: 100%; overflow: hidden; position:relative;">

        <ig:WebHierarchicalDataSource ID="WebHierarchicalDataSource1" runat="server">

        </ig:WebHierarchicalDataSource>

        <ig:WebHierarchicalDataGrid ID="WebHierarchicalDataGrid1" runat="server" AutoGenerateColumns="False"

            AutoGenerateBands="False" Height="100%" Width="98%">

            <Behaviors>

                <ig:Activation>

                </ig:Activation>

                <ig:Selection CellClickAction="Row" RowSelectType="Single">

                </ig:Selection>

            </Behaviors>

        </ig:WebHierarchicalDataGrid>

    </div>

Please let me know if you need further assistance regarding this

Your response does not really address the 'problem'.  All that you have done is provide a way to hide the symptoms of the problem.  The grid still does not fit into the splitter pane.  Extra white space is still generated.  I can't use the full width of the splitter pane, apparently the space for the hidden scroll bar is reserved and not available for me.  Using your suggestion, I am prevented from having any additional content after the grid, because I will not be able to scroll the pane to see it.

While looking at your response, I found that the splitter is once again not required to show the original problem (I don't know what I'm doing differently today vs a couple of days ago...)  I've attached the same project as before, but this time the splitter is commented out.  You need to provide ig_res.

Using IE7: Run the project.  Reduce the size of the browser window vertically so that it is just larger than the grid.  At this point the vertical scroll bar is visible but should not be active -- all of the page content should be visible on the page.  Now expand the last row (A9) of the grid.  The grid size does not change, which is correct.  The grid gets a scroll bar, as it should.  The page vertical scroll bar also becomes active and there is new, additional, empty space below the grid that was not there previously.  That page scroll bar and the additional empty space is incorrect.  In Firefox, following the same steps, you DO NOT get the active scroll bar or additional space, which is the correct behavior.  How do I make IE7 behave like Firefox?

Thanks,

Dave

Hello Dave,

Thank you for the detailed description and the sample provided. They helped me reproduce the issue.

I was able to reproduce the issue with IE7, IE8 and Mozilla Firefox 3.6.15

The issue happened because there are both scrollbars: one of the WebSplitter and one of the WHDG

Please keep in mind that you should set EnableRelativeLayout="true"

property of the SplitterPane  if you do not want the white space to exist (for example when expanding the last row of the grid )

You can set ScrollBars="Hidden" of the SplitterPane where the WHDG is positioned in order to force the grid to be displayed initially without any scrollbars.

<ig:SplitterPane runat="server" Size="85%" Style="position: relative;" EnableRelativeLayout="true" ScrollBars="Hidden">

Please let me know if you need further assistance regarding this

In putting together the sample for you, I discovered that this problem depends on the WebSplitter.  I also discovered that there are additional issues.

I've attached the source code for a VS 2008 project that shows the problems.  You'll need to add the ig_res folder tree to get it to work.  Compile and run it in IE7.  You'll see a grid with 10 rows (there's a global variable controlling the number of rows) inside a splitter.  Each row can be expanded.  The last row has more expansion than the others.

Problem #1: Assuming that the IE window is larger than the splitter needs, note that there is one vertical scroll bar (see problem #2 about that).  Row "A9" should be at the bottom of the grid.  Expand row "A9".  You now get additional scroll bars, when you really should only get an adjustment to the single existing scroll bar.  The outer (right most) scroll shows a bunch of white space below the grid and within the splitter window.  The exact amount of space depends on the size of the islands that were just exposed.  Collapse row "A9" and expand other rows.  Any row expansion that causes a newly displayed island to be below the bottom of the grid causes the additional scroll bars.  Any row expansion that can be completed within the displayed grid (ie, expand row "A1") does NOT cause the additional scroll bars.  Once the additional scroll bars are present, they remain until the row(s) that caused them are collapsed.  Firefox 3.16 correctly expands all rows.  Don't know about other browsers/versions.

Problem #2:  My expectation is that when the heights of body, form, splitter and grid are all set to 100%, that the grid should be completely visible (no scroll bars) in the splitter window.  Unfortunately, this is not true.  It looks like the splitter window is 1 pixel too short for the grid.  In this case, the scroll bar is for the splitter window, so the entire grid moves with the scroll bar.  If the grid height is changed to 98%, you can now see the bottom border of the grid.  However, a scroll bar is still present, but now it is the grid scroll bar.  I can either see the entire grid (including the bottom border) or I can see the full height of each row, but I can't do both.   The splitter should be taller than what it is computing as 100%.  This happens on both IE7 and Firefox 3.16. 

Problem #3: With the grid height set to 98% (to address problem #2), when this application is first displayed in Firefox 3.16, there are NO scroll bars visible!  The grid vertical scroll bar should be present.  Reloading the page or moving the splitter bar causes the scroll bar to display, even though it is horizontal movement of the splitter and the vertical scroll bar is displayed (they should not affect each other).  If the grid height is set to 100%, a scroll bar does display on initial page load.

Thanks for looking into this!

Dave