I try to get the WebSplitter exactly as big as the browser window. To do so, i wrote a javascript which gets the dimension of the browser window an sets those values to a panel or directly to the WebSplitter. This client side resizing works well on resizing, but not on init.
In Internet Explorer 8.0 the WebSplitter contents are get resized well, when it is in a asp:Panel. But in Firefox 8.0, Safari 5.12 and Chrome 15 the contents of the WebSplitter are not shown, till the user resizes the browser window.
I've tested all browser with the same situation, except a asp:Label instead of the WebSplitter, then it worked fine.
I've attached a sample project. The WebForm 'WebSplitterPanel.aspx' works fine in IE but not in the other Browsers. The WebForm 'Label.aspx' uses exact the same javascript and works fine in all browsers. (To get the project attached, i had to delete the content of the folder "ig_res\images\", maybe you have to add those images to test it correctly, but it used the default layout.)
Also i tested some other Infragistics control with this scenario, and its only the WebSplitter that dont work fine?!
When this get fixed? Do i have to wait for a SR??
Hello Andreas, I have reseived your sample. I will test this behavior and see what could be causing it and what could be the resolution. I will update you with information when i finish my research
I investigated the code you send me. I found it unnecessary to use so much javascript. You can set splitter height only by setting css classes for form, html and body with 100%. Please take a look at attached from me modified WebSplitterPanel.aspx page and let me know if this modification matches with what you are trying to do. Please also take a look at the following forum thread which contains similar question: http://blogs.infragistics.com/forums/p/9319/36329.aspx
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?
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
Hello Andreas,Please let me know if you need further assistance with this issue.