If I generate a startup script which opens a modal dialog, then issues a form submit() when the modal dialog is closed, my grid's FilterConditions are lost. If I delay the form submit (using setTimeout) the problem seems to go away.
What is the grid doing that needs to complete before I can submit the form without losing the FilterConditions, and is there some better way to give it time to complete? Relying on a setTimeout to prevent issues seems iffy at best.
What I really need to accomplish is to allow the user to interact with a modal dialog, then refresh the grid when that dialog is closed, to display new data - info about an uploaded file - that may have been added via the dialog window.
Hello,
Thanks for writing. It is an interesting scenario (this would certainly make a good example), but I really am at a loss as to why this might be happening. The setTimeout() workaround really puzzles me, and I am trying to go through the source code now and see what can be related to that.
In any case, I do have a few ideas out of the box that may help you go further:
1. If you are calling form.submit() explicitly, this may in some way interfere with the normal postback cycle in some way. You may try the following approach (still hacky and surely not recommended, but may at least narrow the possible reasons for this down)
<asp:button runat="server" ID="Button1" Text="Fake PostBack" style="position:absolute; top: -1000px; left: -1000px>
<script type="text/javascript">
var button = document.getElementById("<%= Button1.ClientID %>");
button.click();
</script>
2. How are you doing your filtering? Could you please paste some code from your setup - this will surely provide additional clues
3. Are the following DevCenter articles on Filtering providing any clues? For example this one:
http://devcenter.infragistics.com/Support/KnowledgeBaseArticle.aspx?ArticleID=10106
4. Are the CSOM functions documented here you can use helpful? (e.g. applyFilter prior to submitting the form?)
http://help.infragistics.com/Help/NetAdvantage/NET/2008.2/CLR2.0/html/WebGrid_ColumnFilter_Object.html
Finally, and I do recommend this if this is urgent for you, you can ZIP a small subset of your project reproducing the problem and send it to our dedicated Developer Support departament via this link - you will receive a prompt response asap
http://www.infragistics.com/gethelp/
Hope this helps!
Rumen,
We're using sortedlists to populate the FilterCollectionValues. Allowing the grid to collect FilterCollectionValues was unusable - MUCH too slow and it didn't collect values from the full set of data.
For my grid, uwgMain, my filtering setup is essentially as follows:
uwgMain_InitializeLayout event:
uwgMain_RowFilterApplied event:
uwgMain.DisplayLayout.Pager.CurrentPageIndex = 1 uwgMain.DataBind()
Note - manually invoking a form submit does not cause an issue - I can do it by clicking a button and everything works fine. But if the form submit happens from a script that fires immediately when the page loads (generated via RegisterStartupScript, which is what I need), the specified filter selections are lost. (Interesting tidbit - the CurrentPageIndex stays set, even if I'm on page 5 or 10.) Throw in a little delay on the form submit, and everything behaves. I can only conclude that the grid doesn't get to complete loading in some way, causing what gets posted back to lose the specified filter criteria somehow.
Thanks for the follow-up. It is a little bit more clear now.
So, RegisterStartupScript is typically placed at the very bottom of the page (just before the closing </form> tag). The way the HTML page is processed, javascript blocks are executed in the order of their appearance, so I would guess that at the moment the startup script executes, the Grid still has not finished initializing, even though its HTML is processed from the browser, some client-side init logic (like sorting our Filtering) may still be incomplete.
This by the way, explains why PageIndex is not affected - because it is stored in a hidden input in HTML and everything is fine there, whereas I think for filtering some client-side processing needs to be done.
So, here is the weird thing - for these types of scenarios, most of our controls (like Menu, TreeView, etc) have a client-side InitializeMenu/Tree event where you can hook custom code, but I do not see a similar one for grid.
Here is the list of client-side events for grid:
http://help.infragistics.com/Help/NetAdvantage/NET/2008.2/CLR2.0/html/WebGrid_Client_Side_Events_CSOM.html
I guess you can try the InitializeLayout client-side events - seems closest to that from what I can tell.
Hope that helps!
Looking at the generated page, it appears the grid's igtbl_initGrid() method is the very last thing on the page. My script (generated via RegisterStartupScript), as well as the Microsoft script generated from having MainScrollPositionOnPostback=true, are rendered ahead of the grid initialization call. If only I had a way to flip the order of the scripts, I suspect this problem would go away.
With the setTimeout method, I'm afraid users with slow machines could still see their filter criteria disappear (if igtbl_initGrid does not complete in time). Annoying if it happens, and it sure wouldn't make me look good, but it's not a showstopper.
I am looking at the source code of the igtbl_initGrid event and see that it does call the grid client-side InitializeLayout event at the last line, so I guess you can use that instead. You can use the event in the following way:
// C#UltraWebGrid1.DisplayLayout.ClientSideEvents.InitializeLayoutHandler = "UltraWebGrid1_InitializeLayoutHandler";// javascriptfunction UltraWebGrid1_InitializeLayoutHandler(gridName) { // your custom submit code here, or you can register the javascript from server using RegisterClientScriptBlock }
More info on the InitliazeLayoutHandler CSOM client-side event can be found here:
http://devcenter.infragistics.com/Support/KnowledgeBaseArticle.Aspx?ArticleID=6143
Please, let me know if this helps.
Thanks for the info Rumen. I'll try hooking my postback into that event, since that way timing should not be an issue.