Hi,
We have a problem when setting the datasource of the wingrid to a bindlinglist of hierarchical business objects. It seems that unless there is data in this binding list for ALL levels of the hierarchy then the grid seems to reset itself and shows ALL columns for that band irrespective of the setting s for the grid in regard to which columns to display. Is there any way around this issue ? Also, it causes us problems even if we want to do something simple like:-
clear grid
do some form input
refresh grid i.e. set datasource to bindinglist of business objects (hierarchical, 2 levels)
If we clear the grid by setting the datasource to null or new bindinglist<business objects> then when we later refesh the grid we are presented with all columns being shown in the grid for the second level data. Is there a workaround for this?
It seems to be if at any point you set the datasource of the grid to a bindinglist that is empty or for which the first entry in the list doesn't contain data for all of the 'child' bands then you are stuffed ie. all columns are shown and you lose all formatting, value lists etc. Is this the case?
Thanks
Jim
Hi Jim,
You are correct, this will not work. The grid get's the data structure of all levels of the the data when you bind the grid. It does this by asking the BindingManager for it. The BindingManager does this by using the current row in the data - this is usually the first row. So it will start with the first row, get it's child rows, then walk down to their child rows, etc. If any of the child collections have no rows, then the BindingManager will be unable to aquire the data structure, and there's no way the grid can get it.
If the BindingManager is unable to get a row at any particular level, it will try to add a row, and then cancel it once it's done. In order to do this, the objects must implement IEditableObject. So one way to get this to work would be to implement this interface.
Another alternative might be to use UltraWinTree instead of UltraWinGrid. The tree lacks certain grid features like summaries and filtering. But if those are not important for your application, then the tree might be a good alternative, because the tree aquires the data structure on-demand as it needs to, rather than getting it all up front.
Mike,
Thanks for the quick reply on this. Unfortunately there is no way we can use a treeview as we've invested a large amout of time using the wingrid with hierarchical data. I do find it quite amazing that even though the structure of the data is freely available and doesn't change the grid itself 'overrides' the data structure with the data structure it thinks it 'might' be. Also, why don't we see the correct data wehn we show the data, clear the grid (empty bindinglist), then attach the same binding list with data. Is there any work being done at Infragistics to resolve this? We've experienced it for a long time, reported it on here (although at the time didn't knwo what th reason was). Everytime we get a new release we hope that the 'bug' has been fixed.
Regards
murray7 said:the grid itself 'overrides' the data structure with the data structure it thinks it 'might' be
Just to be clear, here, it's not the grid that does this. The grid gets the data structure from the DotNet BindingManager. All the grid knows is what the BindingManager gives it, so it's the BindingManager that is not getting the correct structure.
murray7 said:Also, why don't we see the correct data wehn we show the data, clear the grid (empty bindinglist), then attach the same binding list with data.
I'm not sure what you mean by this. If you unbind the grid and re-bind it to the same data source, why would you expect that make any difference? If the BindingManager could not return the structure the first time, why would it be able to do so the second time?
murray7 said:Is there any work being done at Infragistics to resolve this? We've experienced it for a long time, reported it on here (although at the time didn't knwo what th reason was). Everytime we get a new release we hope that the 'bug' has been fixed.
There's not much we can do about this, really. The BindingManager is part of the DotNet Framework. The only way we could "fix" this would be to essentially re-write the data binding model of the grid to get the data for each level lazily instead of all at once up front. Unfortunately, the grid relies pretty heavily on getting the structure up front and of having a homogenous structure. So it would be a huge restructuring of the grid. This is one of the reasons why we took a different approach when we implemented data binding for the tree.
I can understand that it's pretty frustrating, though. It seems like the BindingManager really should be able to get the data structure without creating dummy rows via some other interface like ITypedList, for example. ITypedList, in fact, seems like it's almost designed for this purpose. But personally, I have not had much success with getting the BindingManager to recognize it. The only thing that seems to work is IEditableObject.
Hi Mike,
>>I'm not sure what you mean by this. If you unbind the grid and re-bind it to the same data source, why would you expect that make any
>> difference? If the BindingManager could not return the structure the first time, why would it be able to do so the second time?
If we have a bindlist called objects containing hierarchical data the follwoign happens
1. Initially bind the data grid.datasource = objects (Data is hown in grid correctly)
2. Clear the grid grid.datasource = new bindingist<objects>
3. Show some data again grid.datasourcee = objects then we get ALL columns in band 1 being shown i.e. doing 2. above to clear the grid seems to reset it and when we susbsequently bind date we get all the columns shown rather than those setup in design view
As you say we are finding it pretty frustrating and actuall quite difficult to comprehend given the structure of the data is freely available, it never changes BUT the data is displayed without any real reference to the data structure which is set in stone.
Do you have any whitepapers with regard to using the grid with hierarchical data or of using your suggested method of implementing IEditableObject.
murray7 said:1. Initially bind the data grid.datasource = objects (Data is hown in grid correctly) 2. Clear the grid grid.datasource = new bindingist<objects> 3. Show some data again grid.datasourcee = objects then we get ALL columns in band 1 being shown i.e. doing 2. above to clear the grid seems to reset it and when we susbsequently bind date we get all the columns shown rather than those setup in design view
Resetting the grid's data source will destroy the layout in favor of the new data source, yes. You could save the grid layout and then re-load it, but I don't think this is a good way to go anyway. Even if you keep the layout, you will lose all state information like the expansion/selection of rows and the active cell and there is no way around that.
murray7 said:Do you have any whitepapers with regard to using the grid with hierarchical data or of using your suggested method of implementing IEditableObject.
No, we don't. This interface is part of the DotNet framework, so it's not something we document. I don't think it's terribly complex, though. It basically allows you to create a sort've "addnew" row and then cancel that row. I'm sure Microsoft must have documentation on it.