I have a hierachical data source (object data source..not dataset) that I have bound a win grid to. Unfortunately when I expand a band I intermittently get the link lines displaying the number of rows in the band (indicating that the data is in the datasource and grid seems to know about it) but the actual band and data is not displayed. Other bands expand fine.
e.g.
[band 0]
band0row0
band0row1
|_[band 1]
band1row0
band1row1
|_[band2]row0 (not displayed but link lines on left are displayed)
|_[band2]row1(not displayed but link lines on left are displayed)
The band has not been set to be hidden. I have even tried to rebind the grid after the row expanded event but this doesn't help.
Version 7.2 of wingrid.
Any ideas?
If I understand you correctly, it sounds like you are getting rows with no columns. If that's the case, it's most likely because your data structure is no homogenous.
It's hard to say without knowing how your data object is being implemented, but the grid can only be bound to a homogenous data source. In other words, all the rows at a particular level must have the same structure. To put it another way, you can't have rows of different types under different parents in the same level of the hierarchy.
Also, it may be that the grid is unable to get the data structure of the columns at a particular level. The BindingManager in DotNet can't get the structure of a child level if the first row of data does not return a typed object for that list. For example, if you are binding your grid to a List or BindingList of objects and those objects return a property that is of type List or BindingList, you must make sure that the first root-level object returns a child list, even if that list is empty. It can't return null, because then the BindingManager can't get the structure of the children because it won't know what type the objects are. The same applies to each level down. So if your first parent row happens to return an empty list, then the BindingManager will be unable to get the structure of the grandchild rows, since there are no child rows for which to get a grandchild row.
Mike,
Thanks for the pointers. Gave me something to think about.
Essentially what I was trying to do was the following:
The user would select a few items that would be nested together in a batch. I would take the selected items and 'wire' up a bare bones selection of more complex objects (basically items that had lists within lists that represent data/rules at different levels within the object model) and bind this to said grid. The user would then work through the grid adding data, working out calculations that would force the bare bone objects to be replaced over time with the fully populated objects.
It would seem that my problem stemmed from the NULL issue that you eluded to above. During InitializeLayout on the grid I was getting some exceptions that were being suppressed (catch...do nothing) in which the grids TotalBoundcolumns property (and a few other properties) was throwing exceptions (missing index, keys for collections).
In my wire up of the 'bare bones' object some of the generic List objects were left as null as we didn't need them at that time (they would be populated at a later time with database data). When the object was replaced with another object of the same type some of these Lists would be populated with data but would not show on the grid - the missing column issue - but the number of rows in the list would be be eluded to via the link lines.
In order to ensure that the data is shown I forced all the Lists (and properties) in the bare bones object model to be at least initialized i.e. not null. before binding to the grid. Once this was done when the bare bone objects were replaced with populated data objects the grid would render the columns as well as the row indicators.
Thanks for the help...
Rich
I was wondering if you had come up with a solution to using non homogenous datatypes. I am having the same problem and was looking for a better solution than having to initialize all the data that is not being used.
Thanks
not really...it did seem wierd to me than the grid designer could pick up the full object design from the bindingsource but when it came to run time I had to force at least collections/lists etc to be not null.
In the end, I didn't have to populate the collections just make sure the collections (in my hierachical object model) had a count of 0 (essentially a 'new' List<Type>()) - then the band wouldn't be shown (has no rows) but when the underlying collection was populated the binding was correct and the band would render.
Otherwise I would get exceptions thrown on binding...totalnumberofboundcolumns would throw errors, index out of bound, null reference exceptions etc...in the inner exceptions (which the application was silently swallowing).
Not perfect but worked for me....
The data source was set to a defined object data source generated via VS. Manually defining the source schema wasn't tried.
By the way... The UltraWinTree control can display non-homogenous data structures. You will lose other features like filtering and summaries, but it may suit your needs better than the grid.
Did you happen to try to manually set the data schema before binding? I was thinking of trying this but wanted to ask before I went to all the effort.