Any updates on this issue?

Is this Bug fixed by the next service release?

Hello Andreas,

I was testing this behavior. Finally i decided to change the WDG  with microsoft's GridView:

In code  behind:

protected

void Page_Load(object sender, EventArgs e)

{

//this.LoadData();

GV.DataSource =

Class1

.GenerateData();

In mark up:

<

form id="form1" runat="server">

<asp:ScriptManager ID="SM" runat

="server">

</asp:ScriptManager

>

<asp:Panel runat="server" ID="panelControl111" Width="400px" Height

="50%">

<asp:GridView runat="server" ID

="GV">

</asp:GridView

>

</asp:Panel

>

</form>


And the Microsoft's control renders exactly the same way. I assume this is the default and expected behavior.

Ok, then your first provided solution does not help me.

So,  when will the javascript version work like expected?

Hello Andreas,

Could you please be more specific. What do you mean by "javascript version"? You are pointing setting the width abd height by js functions attached like:

window.onresize = ResizeFullWindowPanel;

window.onload = ResizeFullWindowPanel;

or you are pointing jQuerry controls by javascript version?

Hello Andreas,

Please let me know if you need further assistance with this issue.

The problem still exists.

Please check the sample' WebSplitter_SampleProject' provided within the thread start. The problem is still exact the same as then. And i dont want to write anything again. Just read the start.

I cannot use the solution to set all containers to 100% (or 99.9%) because then the WebDataGrid (and as the other supporter says also the .Net grid) is getting to big, if there to many records. They grow instead of using scrollbars. So i have to use fixed sizes for the grid, and there the javascript version (window.onresize/onload=smth;) comes in.

Hello Andreas,

Please let me know if you have any further questions regarding this issue.

Hi Andreas,

I read through that thread and could not figure out which bug you refer to. If it is about sizing of WebSplitter, then it should support % width/height and the suggestion about setting height:100% to all containers of splitter is the best one and it is the simplest solution. Containers should include absolutely all html elements such as html, possible div, possible Panel, etc.
I would recommend to use not 100%, but something like 99-99.8%, because of borders, padding, etc.
If you need 50%, then splitter should support that as well.

If there is a specific bug in a specific control, then it would be helpful, if you describe exactly which function/property fails in exactly which conditions. If you have a simple sample, then please submit a bug-report and provide exact steps to reproduce misbehavior.

If you refer to problems coming from window.onresize/onload=smth;
then it is not clear to which Infragistics control you refer too and what exactly fails.

If you prefer to manually calculate size of visible window and adjust controls/htmlElements explicitly in javascript, then it is possible as well and for some layouts it can be the only solution. In this case I suggest you to clean your codes and use NetAdvantage utility function getWinRect. It returns scrolls (x/y) visible size (width/height) and full size (maxWidth/Height) of window. Below is example to test that method.

<script type="text/javascript">
function bounds()
{
  var i, rect = $util.getWinRect(), s = '';
  for (i in rect)
    s += i + '=' + rect[i] + '\n';
  alert(s);
}
</script>
<input type="button" value="bounds" onclick="bounds()" />

For sure we need further assistance. The bug was not fixed till today. I've tested the behavior with the new Service Release (ASP.NET Build 2025), and exact the same bug!

And we need to have the javascript version. And of course im talking about the version with the attached functions:

window.onresize = ResizeFullWindowPanel;

window.onload = ResizeFullWindowPanel;

Regards