HOW TO: Add /manipulate columns for a GridControl

Question

HOW TO: Add /manipulate columns for a GridControl when the columns (attributes) are from different entity objects.
This HOWTO describes the basic steps of using attributes from different entity objects for a GridControl.
One way you can create a GridControl which contain attributes from different entity objects is to create a view object and base it on the entity objects which contain
the desired attributes.
Here are the basic steps:
1.Create a new view object (or use an existing view object) by selecting File>New from the menu, clicking the Business Components tab and double-clicking
on the View Object icon.
2.In the View Object wizard change the name to something meaningful.
3.Select the entity objects you will base your view object on.
4.Nivigate to the attribute screen and select the attributes you would like to include in your view object from each entity object. At this point you can also create
a new attribute by clicking the "New" button. The new attribute can be a concatenation of other attributes, derived from a calculation etc.
5.In the query panel of the View Object wizard, click "Expert mode" and enter a query statement. You write complex queries such as decoding a set of attribute
values.
6.Add your newly to your newly created view object to the application module by double-clicking on the application module in the navigation pane and selecting
your view object from the list.
7.Create a new row set.
8.Bind row set to a query by editing their queryinfo property and selecting your view object and its attributes from the queryInfo pane.
9.Create a GridControl and bind it to the row set by editing the dataItemName property of the GridControl. Since the GridControl is bound at the row set level
all of the related attributes are automatically added.
null

Answer 1

Michael,
Are you intending this as a commercial solution or a work around?
To take an existing equivalent, one would build a view in the database tailored for each grid in an Oracle Forms application. Or a separate query layered over tables for each form/grid in a Delphi or Access application? Even if it is ninety nine percent the same over half a dozen forms/grids?
And now you've added a whole slew of "slightly different" rowSetInfos to maintain.
So if you wanted to add a column that needs to appear everywhere... you've just increased the workload multi-fold?
That would be a management nightmare, wouldn't it? Not to mention yet more performance cost and a slower system?
Hmmmm..... I'm not sure I like where this is headed... someone needs to do some convincing...
null