I am displaying 3 tabs within a webTab with each being populated via a user control. The default tab(0) contains a webgrid and renders correctly. Tab(2) also contains a webgrid, but it's render is all wrong. The first column displays only with a;ll others not present or all of the columns are stacked behind one another. This only occurs within a FireFox browser. How can I correct this or is there a way to load on demand the tab value utilizing a user control.
Are you using stationary margins, fixed headers, or both, on the grid on the second tab? I recall something similar, and since it'll take some digging to find the details, I'd like to confirm what's happening first.
Here's the Grid aspx Definition:
<igtbl:UltraWebGrid ID="grdPrevention" runat="server" EnableViewState="false" OnInitializeLayout="grdPrevention_InitializeLayout" OnInitializeRow="grdPrevention_InitializeRow" >
<Bands>
<igtbl:UltraGridBand>
<AddNewRow View="NotSet" Visible="NotSet">
</AddNewRow>
<Columns>
<igtbl:UltraGridColumn BaseColumnName="PreventionID" Hidden="True" Key="PreventionID">
</igtbl:UltraGridColumn>
<igtbl:UltraGridColumn BaseColumnName="Source" Hidden="True" Key="Source">
<igtbl:UltraGridColumn Key="test" BaseColumnName="test" Width=30%>
<Header Caption="Screening Test">
<RowLayoutColumnInfo OriginX="1" />
</Header>
<Footer>
</Footer>
<igtbl:UltraGridColumn BaseColumnName="risk" Key="risk" Width=25%>
<Header Caption="Health Risk" Title="">
<RowLayoutColumnInfo OriginX="2" />
<igtbl:UltraGridColumn BaseColumnName="testurl" Hidden=true Key="testurl">
<igtbl:UltraGridColumn BaseColumnName="riskurl" Hidden=true Key="riskurl">
<igtbl:UltraGridColumn BaseColumnName="freq" Hidden=true Key="freq">
<Header Caption="Frequency" Title="">
<igtbl:UltraGridColumn BaseColumnName="LastChk" Format="MM/dd/yyyy" Key="LastChk" Width=10%>
<Header Caption="Last Checked" >
<RowLayoutColumnInfo OriginX="3" />
<HeaderStyle HorizontalAlign=center />
<CellStyle HorizontalAlign=Center></CellStyle>
<igtbl:UltraGridColumn BaseColumnName="NextChk" Format="MM/dd/yyyy" Key="NextChk" Width=10%>
<Header Caption="Next Check" >
<igtbl:UltraGridColumn BaseColumnName="ToDo" Key="ToDo" Width=25%>
<Header Caption="What I should do" >
</Columns>
</igtbl:UltraGridBand>
</Bands>
<DisplayLayout AllowColSizingDefault="Free" Name="ctl00xgrdPrevention" RowSelectorsDefault="No" CellClickActionDefault=RowSelect
SelectTypeRowDefault="Single" TableLayout="Fixed" NoDataMessage="Your Checkup list is empty."
Version="4.00" AutoGenerateColumns="False" StationaryMargins="Header" RowHeightDefault="30px" RowsRange="4">
<GroupByBox Hidden="True">
</GroupByBox>
<ActivationObject BorderColor="Black" BorderStyle="solid" BorderWidth="">
</ActivationObject>
<RowStyleDefault BackColor="White" BorderColor="Gray" BorderStyle="Solid" BorderWidth="1px"
ForeColor="Black">
<BorderDetails ColorLeft="White" ColorTop="White" />
<Padding Left="3px" />
</RowStyleDefault>
<SelectedRowStyleDefault BackColor="#ffcc66" ForeColor="Black">
</SelectedRowStyleDefault>
<HeaderStyleDefault BackColor="#0063A1" BorderColor="Black" BorderStyle="Solid" Font-Bold="True"
Font-Names="Arial" Font-Size="12px" ForeColor="White">
<BorderDetails ColorLeft="White" ColorTop="White" WidthLeft="1px" WidthTop="1px" />
</HeaderStyleDefault>
<RowAlternateStyleDefault BackColor="#DDDDDD">
<BorderDetails ColorLeft="197, 202, 219" ColorTop="197, 202, 219" />
</RowAlternateStyleDefault>
<FrameStyle BorderColor="Black" BorderStyle="Solid" BorderWidth="1px" Cursor="Default"
Width="100%">
</FrameStyle>
</DisplayLayout>
</igtbl:UltraWebGrid>
According to the markup you've posted, your grid is indeed using stationary margins.
I've found the similar issue I was thinking about. The symptoms are slightly different in that issue - in this case, the rows weren't appearing at all. This other issue was reproduced in Internet Explorer, rather than Firefox. That issue was determined to be a bug and will be fixed in an upcoming hot fix. (By the way, if anyone reading this is interested in this fix, I suggest submitting a support request and referring to development issue 11815.)
This will likely take some additional research to determine if the issue you're encountering is the same one I was thinking, a different issue that can be fixed by making some changes to your code, or is possibly a new issue that may require a fix in our controls. I suggest you submit a new support request so that a Developer Support Engineer can assist you further. Since we're not entirely certain what's causing this behavior, I suggest you attach to this new support request a concise sample application that we can run and debug and which reproduces the issue.
Vince,
I have a similar issue. Is this the same?
I have a WebGrid that has problems displaying any rows in Internet Explorer 7. When that happens, and the mouse is moved over it, there is a JavaScript error on the "onmousemove" event of the grid. "Object expected." (onmousemove="igtbl_tableMouseMove(event,'dnnxctr881xViewCAxUserManagementxuwgPocList')") Also, IF the grid loads with its initial data, I am updating it by selections made in dropdownlists, using AJAX. It is necessary to make 3 or 4 selections on the dropdownlists before the grid will load with new data. Once it does, then it works fine from that point on. I am using FixedMargins="Header." I turned this off. No change. None of these issues appear in Firefox. Everything works great in FF.
As you suggested in your post above, I entered a support request for this. Case number CAS-21938-NARMQH.
If this is related to Development Issue 11815, what is the progress on this?
Since your issue involves a JavaScript exception, I'm pretty sure that it's not the same issue reported above. My advice would be to submit support requests for the issue you've described, which you've already done.
For those interested in the progress of development issue 11815, it was fixed in our February 2009 hot fix release.
Thanks again for the follow-up. I'm sure there are others here (in addition to myself) who are curious about what you turn up.
It's happening with or without IG controls being present. So I think you guys are off the hook on this one.
I'll research it further and let the ASP.NET community know about it if I find something.
Thanks for your follow-up. What you've described is definitely strange and unexpected.
Does this issue occur on a page that doesn't use our controls? For instance, use an UpdatePanel from the ASP.NET Extensions tooslet. This may help determine if this will affect all AJAX functionality, or just the AJAX functionality that we've built into WebTab and/or WebGrid.
You might also want to consider testing with IE 8 32-bit on Vista 64-bit, against an application deployed to "localhost", with and without our controls. If you have access to virtual machines, I strongly suggest you use one for this test, so that you don't adversely affect your development.
If the issue is fixed in IE 8, then it's likely something Microsoft already fixed. If not, then it's possible that we may still need to pursue the issue with Microsoft.
Thanks for the response. I found the problem. It's goofy enough that it needs to be reported. Yet another piece of Internet Explorer strangeness. The following is text of an e-mail I sent to the rest of my team.
I have been struggling with my User Administration module and how it is requesting updates. Basically, everything was working perfectly in Firefox. But in Internet Explorer 7, when I first hit the page it would load everything properly, but the AJAX calls to update the screen would fail 3 or 4 times. Finally, it would start to work. If I just refreshed the page, the main Infragistics grid would not load at all, even over multiple refreshes. I would have to let it sit for some time, then it would reload and repeat the process.
This, obviously, would be unacceptable.
Getting into the background of the application, I found that calls from IE were NOT hitting the server code at all. The "Page_Load" event would not fire, meaning nothing dynamic would load (like the grid). With Firefox, the event would fire without fail.
So this is an issue with IE's caching, IE proxy caching, or something related to it.
The "simple" approach would simply be to turn off browser caching. Or so I thought. That's one line of code. But it didn't work.
Finally, something came to mind about IE and 64-bit Vista. (I'm using 64-bit Vista.) Simply put, it's flakey. The main problem is that IE on a 64-bit Vist***em will just stop responding and lock up. No known reason. And apparently Microsoft doesn't care too much about it, because they know about it but they're not fixing it. IE 8 is about to be released, and they're probably thinking everybody will go to that and the problem will just go away on its own. But I digress....
Like most everybody using 64-bit systems, XP or Vista, I am using the 32-bit version of IE7. Why? Because Adobe doesn't have a Flash player that will work in 64-bit IE7. What the holdup is, I don't know. But almost nobody is using a 64-bit browser because of it.
I decided to try the module using 64-bit IE7. It worked! Perfectly! Never failed. Every page refresh and every AJAX call working as expected. Next question-- Is this a 32-bit IE issue altogether.
I went over to my wife's machine, which is running 32-bit Vista. Connected her browser to my server, and it worked perfectly. So, is it a universal 64-bit Vista / 32-bit IE7 issue?
I fired up my laptop, which is also 64-bit Vista. I opened the 32-bit browser, and hit my server. It worked perfectly.
So, I think the issue only happens with 64-bit Vista, 32-bit IE7, running against the "localhost" web server. There is another test I can run to be sure, but it's not an issue right now. When IE7 is being used remotely, the problem doesn't happen. It probably has more to do with the web server and local calls from IE7, than being a real issue. What I think now is that even though the browser is not set to detect or use a web proxy, it may be using Proxy Caching when calling localhost, something that Firefox does not do.
There may be an issue with the AJAX calls using 64-bit IE7 remotely. But I seriously doubt that any of OUR users will be using 64-bit IE7.