Hello,
I've attached a sample solution in which i have a ultragrid linked to a dataset.
Dataset has 3 tables, "One", "Two" and "Three". "Two" and "Three" being child of "One" and sibling of each other.
On the click of the button "Replace Band Three", I remove table "Three" from the dataset and add another table "Three" with a different structure.
How can this change be reflected into the grid, can I reload the display layout of a band ?
TIA,
Guillaume.
If you consider the object model the grid is sitting there and hasn't realized that its underlying data source has been modified. I looked around and didn't see any methods that suggested something that would refresh a specific band or anything of that nature. I would bet that if you were to set the grid's data source equal to your data source object again in your button click event that the grid would reorganize itself to match the new table structure.
If re-setting the DataSource is the only way, i will have to use that way.
However, I have problem making it work.
Setting again the DataSource to the dataset does not work.
Setting the DataSource to null, then to the dataset, show new band but it has no columns (I see only row markers).
Setting the DataSource to a copy of the dataset works ok. However, I don't want the overhead of creating a copy of the dataset.
Mike Saltzman said:But What I don't get is... how does this data structure help you achieve that? I can't see how this would make any difference. What do you gain by it?
Please have a look at the second project sample i've sent.
This data structure allows to display each (Mark + its Detail rows) on the right of each other (the Mark name is displayed in the column header).
In the sample, if you try to click on a column header in the second grid, second band, this will select all Detail cells of the Mark.
The Mark and its Detail rows must be seen as a whole, a group. And these groups must be displayed horizontally, under the root band.
canam said:I use this approach (I know it's horrible) only because the grid doesn't allow me to display Mark rows horizontally(on the right of each other) and then display the Detail under it.What could work I think is to make Mark band as a CardView, but then I would need each cardview to be able to display child rows inside/under it, which the grid doesn't allow.
You kinda lost me here. I think I understand what you want to do. You have a root band, and then you want the children to display under it in a row, like cards, but you need a child band underneath that, which you can't do, since card bands can't display child rows.
But What I don't get is... how does this data structure help you achieve that? I can't see how this would make any difference. What do you gain by it?
Okay I just looked at your sample project. I assumed the mark detail was one a one to many relationship with product line marks. It sounds like you have quite a conundrum there. I think I'd have to look for an alternative solution for what you are trying to do.
Thanks for the clarification Steve.
But I don't see how this could help, my main problem is to display Mark records in an horizontal fashion.
Moreover, a Mark can have multiple child Detail records, and I cannot really aggregate those values into the Mark, they must be displayed as different rows under the Mark.
For example if you had an orders table and a customer table where Order.CustomerID points to a Customer.CustomerID field. The order table itself does not contain the customer name field which is in the Customers table and you would like to be able to include that information in your grid display without having to create some elaborate mechanism to show that information. Using a data table relation between the two tables you can create an expression field in the Orders table that points to the customer name field in the customers table and it is automatically evaluated and updated if the Orders.CustomerID field is changed. So if you had a data relation called FK_Customer_Orders the expression field for the customer name in the order table would be parent(FK_Customer_Orders).CustomerName. It's almost like having a view in a dataset.
In your case I was just wondering if that would help if you could pull your mark detail information into the product line marks table so you didn't have to worry about that third mark detail band.