[JLivermore]

OK, understood. Thanks for the help. I may be back with more questions (with more context).

[JLivermore]

Taking a step back, here is what I did:

1. Created an array of ListGridFields with name, title, and width configured size of 405.

2. TreeGrid.setDefaultFields(array405)

3. TreeGrid.fetchData(criteria)

4. Only the first field in the TreeGrid rendered, there were 7 missing fields from the TreeGrid. Only the folder column appears.

5. After the TreeGird.fetchData() I did a TreeGrid.getFiields() and checked them against what was set as default, they were identical.

[Isomorphic]

We're not sure of the math between 405 and 1 but only having 7 missing, but again, you don't seem to have a reason to use setDefaultFields() and we would recommend setFields().

[JLivermore]

But I do have a reason, I am working with up to 4 different Grids with 1 very large set of fields (405 fields to be exact).

So in trying a simply example based on what you have walked me through, it does not do what I was expecting.

I was expecting a total of 8 fields to appear in the grid, as those were part of my criteria in the fetchData().

Why is only the folder field (the first field I was expecting) and not the others showing up?

[Isomorphic]

What you say that some fields were part of your criteria to fetchData(), what does this mean? Criteria do not include fields.

[JLivermore]

Not fields, i meant to say data which represents which fields will be in the return records for display.

[JLivermore]

this example has 405 fields, there are thousands to choose from.

[Isomorphic]

OK, this thread has become reminiscent of a game of "20 questions" - we have far too little detail to try to replicate the behavior you're claiming, and only now at post #22 are we informed that your fields are dynamic based on the server response.

We have to wrap up this thread with:

1. you still have no apparent reason to be using setDefaultFields(). The fact that the fields are dynamic based on server data makes it a virtual certainty that you should not be using this API

2. if, despite this, you really really think you should be using setDefaultFields(), we need a minimal, ready-to-run test case that demonstrates that something is wrong with the API. We can't continue to try to pin down your usage via a question-and-answer process.

[JLivermore]

OK, let's get back to concepts for usage, maybe I don't have the correct idea of setDefaultFields().

In this scenario:

1. Create a grid.

2. grid.setDefaultFields() with a list of fields with only name, title and width set. The hidden attribute is not set explicitly during the construction of the ListGridField(s).

3. grid.fetchData() can return any number of fields in the original list that has been set on grid.setDefaultFields().

4. In the test I did last night, only the nested folder field for a TreeGrid was shown from the results of my TreeGrid.fetchData(). And that was my puzzlement. I was under the impression that the Grid would automatically pull from the list of defaultFields the correct fields to display if both name attributes on the ListGridField and the DataSource return records matched.

My questions are:

1. Does the Grid determine which fields to display based on matching the name attribute of the ListGridField to the name attribute of each record coming back from the grid.fetchData()?

2. Or should I set the hidden attribute on the ListGridFields first when I do a grid.setDefaultFields() for the first grid.fetchData(). And then when every subsequent grid.fetchData(), first do a grid.getFields() and set the hidden attributes for each ListGridField before I do the grid.fetchData()?

3. And then for every subsequent grid.fetchData() do I need to do a grid.getFields() to toggle the hidden attribute to true for every field I am expecting back from the grid.fetchData()?

4. No need to do a grid.setFields() because the fields are already cloned from the grid.setDefaultFields() correct?

Thank you.

[JLivermore]

More testing shows that I have to explicitly set the hidden attribute on the ListGridField if I want it to show up in the Grid after a fetchData().

This was the root of my confusion, I was under the impression that using setDefaultFields() the Grid would manage the hidden state of the ListGridFields based on the result set coming back from the fetchData().

In other words why not have the Grid automatically manage which fields are show based on records coming back from the server.

I do need to manage the state of the ListGridFields explicitly to control what's displayed on the grid. Correct?

[Isomorphic]

I was under the impression that the Grid would automatically pull from the list of defaultFields the correct fields to display if both name attributes on the ListGridField and the DataSource return records matched.

We have no idea where you got this notion. The documentation for setDefaultFields() says nothing about functionality of this kind.

Best guess at what has been going on in this weird thread: you inherited code you didn't write. You are seeing that the grid is showing fields based on the data; the actual reason for this is some code in your application, probably in the callback for fetchData() or a in a DataArrived handler, which is doing a setFields() or showFields() call. However, inexplicably, you ascribed this behavior to setDefaultFields().

You really just need to look at your own application code to understand how specific fields are being shown. It has nothing to do with setDefaultFields().

And, once again - it does not appear that you have any reason to be using setDefaultFields(). If you refer to the documentation for this property, you will see that it has no resemblance to your use case.