I have a Business object "Parent" that has a collection of another Business object called "Child". It also has some properties and methods as usual. Now this is how i try to bind this to an UltraWinGrid:
1. Populate "Parent" instance called "p" by assigning some values to its properties.
2. Declare a Bindingsource "bndSource" at runtime.
3. Set binding source DataSource as bndSource.DataSource = p;
4. Set binding source of ultrawingrid to be mygrid.Datasource = bndSource.
5. Run.
As control passed through step 4, the entire form goes white in color and does nothing until I abruptly end the process.
Note: The "Parent" class has some properties (some readonly, some are of datatype guid, some are inherited), some methods and a collection of objects of type "child".
Note: This class is generated using Nettiers templates.
Hi,
The grid needs to be bound to an IList or an IBindingList. So are you binding the grid to a list of Parent objects, or a single object? I don't think a single parent object will work, but you could create a BindingList<Parent>, add a single parent object to the list and bind the grid to that.
Having said that, I'm not sure why the whole form locks up. Binding the grid to a single object should not cause that. That's more likely to happen if you bind the grid to a recursive data source. Does your Child object also have a collection of Child objects? If so, then you probably need to limit the grid's depth. Try setting MaxBandDepth on the grid.DisplayLayout to something like 5 and see if that fixes the issue.
Mike,
Setting MaxBandDepth property to 3 now does not hang the form now and it also shows up the data on the grid. Thanks for your help.
For your question about the parent if its a collection or a single, the answer is, the parent is a single object to which the grid is bound. Now this Parent is assigned to a BindingSource Control's datasource which itself has the IBindingList implementation. Hence I assume there won't be any problem in using a single parent object.
Scott.
The issue has been resolved now which gave birth to a new scenario.
The grid is displaying data in parent /child relationship with the parent row having a '+' sign to expand and view the child row. Now this is obviously due to the parent object holding a collection of another child object inside it.
Can i make grid to display in a such a way that the child rows won't be placed as child instead they should show up in the same row as parent? In other words, there are no children for the grid, the children columns are also part of the parent row columns.
If you only want to display the child data, and not the parent, then it sounds like you should be binding the grid (or the BindingSource in this case), to the parent.Children collection, rather than to the parent itself.
If you want the parent row to display in the grid, but be on the same level with the children, then there's really no way to do this except to create a data source that has all of the data in a single list. You might be able to fake it, though. You could turn off the ExpansionIndicators on the grid and set the Indentation property on the Bands to 0, and also set InterBandSpacing to 0. That would give your grid a sort've flat look. Then you just have to make sure you expand the first row of the grid in code so that it starts out expanded and you can see the child rows.
Mike, isn't it possible to embed a grid within a grid to accomplish this? The child grid would be in a cell on the same row as the parent record and the data could be displayed horizontally instead of vertically.
If this is possible, I would love to see how it's done.
Yes, I'm pretty sure that this is possible with the new UltraControlContainerEditor that was introduced in NetAdvantage 2009 Volume 2. The new editor lets you embed any control you want into a cell, so you could, in theory, place a grid into a grid cell.
However, while this is theoretically possible, it's not really practical. I haven't tried it, but I'm pretty sure that this approach would have some big performance problems. Taking this approach would require 3 grid controls: One for the parent data, one for a cell in edit mode, and one for cells not in edit mode.
The main grid and the edit mode grid aren't really a big deal. And the data in the cell might not even need to b editable. But the cells not in edit mode will be a problem. Basically, every time a cell paints, the rendering grid would have to be bound to a new data source and made to paint into the cell. The grid is optimized to be pretty efficient, but binding the grid to a new data source and forcing it to paint for each cell in another grid every time that grid paints probably would not be practical.
Of course, I could be wrong. If you made the rendering grid as efficient as possiblem and it wasn't displaying a large number of columns or rows, and you are running a pretty fast machine, it might work okay. :)