Hello Ivaylo,

I do not manually run an ajax call to get the data source for the grid. Instead I have provided the grid with an URL to my web method on the server so that the grid itself can trigger an ajax call to that web method whenever the user interacts with the grid through filter, sort or paging. Dues to this I have limited control over the ajax call in itself. The only thing I can do is control what the response from the web method is. Is there no way of passing a list of columns back and keep autogeneratecolumns to true?

Otherwise I suppose I have to fetch the databinding event on the grid and manually check the data source and if it's empty I need to modify the autogeneratecolumns property and set it to false? Could you please provide an example of this?

Hello Johan, 

This is a very specific scenario indeed. In order to change the dataSource in this particular scenario, I suggest it could be done by destroying the igGrid and creating a new one, using a new instance of $.ig.DataSource. 

The thing is that if you change the igGrid dataSource, the grid still persists its data Schema. So let’s say you have a 2 JSON looking like :

var namedData = new Array();
namedData[0] = { "ProductID": "1", "UnitsInStock": "100", "ProductDescription": "Laptop", "UnitPrice": "$ 1000" };
namedData[1] = { "ProductID": "2", "UnitsInStock": "15", "ProductDescription": "Hamburger", "UnitPrice": "$ 10" }; 

var namedData2 = new Array();
namedData2[0] = { "ProductID1": "1", "UnitsInStock2": "100", "ProductDescription": "Laptop", "UnitPrice": "$ 1000" };
namedData2[1] = { "ProductID1": "2", "UnitsInStock2": "15", "ProductDescription": "Hamburger", "UnitPrice": "$ 10" };

Note the difference is in the “Key” part of the Key: Value pairs for the first two elements ProductID and UnitsInStock. 

Initially set namedData as dataSource for the igGrid and render the grid... 

                        var ds= new $.ig.DataSource(
                        {
                                    dataSource: namedData2
                        } 
..then change the dataSource to namedData2..this will result in rendering only the last couple of columns. As the first two no longer match the igGrid schema, they will be rendered empty. This is when using autoGenerateColumns: true. 

Using option like
$('#table1').igGrid('option', 'dataSource', ds) is also not an alternative, as the result expected is the same as above.

This is why it could be required to destroy the igGrid in order to generate the correct schema, when re-instantiating it with the new dataSource. Please refer to the codeAttachment for details.

Hi,

Destroying the grid is exactly the kind of behavior we are trying to move away from since it introduces a lot of issues with persisting the state of filter, sort and paging along with introducing the need for us to programmatically add logic around all grid interactions. So it is not an option to go back to that. Given the help in this thread (http://es.infragistics.com/community/forums/t/90338.aspx) we are almost at the finish line with our new implementation, we only need to be able to return an 0-row data set (with column definitions) from our server side web method. As an example of a workaround (that's ugly though) you can return a fake data set with the real columns but with only one row consisting of only the empty string. It will mean the grid behaves as we want it to, but of course having that empty single row just to get the grid to display doesn't feel like an option.

Since your grid supports remote actions such as filtering it doesn't seem that impossible that it should be able to handle what happens when the filtering returns the empty set, and not just crash..

Why wouldn't I want to persist the state of filtering, sorting etc? If I didn't then every time a user filtered, sorted or switched page in the grid all other filters/sorts/page info would wipe, even though the user is viewing the same grid. He/she doesn't care if we bind the entire data set to the grid and do local sorting/filtering/paging or if we only bind small subsets and handle those events remotely. The user experience should be the same which means as long as the user stays on that grid the controls should be persisted, just as they would if we were using local sort/filter/paging. Since we are using remote filtering/sorting/paging we get a new subset of the entire data source from the server on each user interaction, which is the point with begin able to handle these events remote.

I guess I will have to find a workaround for this myself, though as stated it is strange that your grid supports remote filtering/sorting/paging but doesn't support the data set returned to contain 0 rows (that behavior is supported when those operations are handled locally afterall).

Hello,

Please let me know the progress of this work around and if I could be of further assistance.