Ultrawingrid

I want to add an unbounded column to Ultrawingrid (Infragistics) . It only for display. I have other columns coming in datasource. Can this be done.
rishaanAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Alexandre SimõesManager / Technology SpecialistCommented:
I never worked with that specific grid, but all the other similar ones that I've used, I always found it easier and actually better to add the extra column in the datasource.
This way, either if it's something that depends on other data on the item or just some static info, it's much easier to manipulate.

If your datasource is a list of objects, just add an extra public property, if it's a DataSet/DataTable, just add an extra column.
sarabandeCommented:
if it's a DataSet/DataTable, just add an extra column.

you could define a view in the database which adds the extra column and bind the grid to the view instead of the table. if it is for display only you even may be able to derive the (default) contents of the extra column from other fields.

Sara
Alexandre SimõesManager / Technology SpecialistCommented:
@Sara, that's also an option but it would force UI logic into the DB which I think it's a wrong design principle.

If we need to "hack it", it should be in the consumer side.
Why Diversity in Tech Matters

Kesha Williams, certified professional and software developer, explores the imbalance of diversity in the world of technology -- especially when it comes to hiring women. She showcases ways she's making a difference through the Colors of STEM program.

sarabandeCommented:
but it would force UI logic into the DB
'views' in the db are supposed to serve for display purposes. depending on the circumstance whether the info to show in the column is related to the other data or not, it may be less a design fault than to add an empty column to a datasource.

Sara
Alexandre SimõesManager / Technology SpecialistCommented:
Views may serve the purpose of pre-compiling and optimize queries.
They can also be used to create/isolate a business oriented layer on top of a relational model. With a view, other queries can easily access a logic that would be hard to reproduce and duplicated.

They serve many other purposes but...
No sane SQL Admin will let you add empty columns to a view because 2 or 3 architectural layers up someone chose a UI component that makes it hard to add dummy columns.

Does this mean that if the choice of the grid changes, you need to change your DB?
If you have a Service Layer in the middle, should you change DB+Service to hack a UI component?

Not on my watch! :)

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
sarabandeCommented:
you are speculating since we don't know which info should be displayed in the additional column and whether it is related to the other data fields or not.

and you argue as a database designer. if you look at the design from the view of application development where the datasource only perhaps only is a means to make the data entered by the user persistent, then the database design is determined (only) from the available data and the design of the form and its controls. if the ui is driven by OOP design, it is a good chance that the db design is OOD as well even if you have to force the objects to relational entities (and most probably there is no mighty db admin who can prevent you from adding columns if you think they are worth to be added).

using a database view allows to use tools to generate the bindings without needing to manipulate the generated exchange modules. therefore, it is much more likely that you can repeat the modeling when new fields or tables were added. this is not possible if you made a customization at the application's side which wasn't preserved by the tools.

Sara
Alexandre SimõesManager / Technology SpecialistCommented:
We're deviating from the main issue here, but I can't agree with you on this.
By no means the DB should be ruled by the UI components flaws or limitations.

and most probably there is no mighty db admin who can prevent you from adding columns if you think they are worth to be added
... .which doesn't mean everybody should do whatever they well please.

using a database view allows to use tools to generate the bindings without needing to manipulate the generated exchange modules
Nornal queries, Linq (EF, Linq2Sql, NHibernate or whatever ORM), Stored procedures and in fact views can all serve the same purpose. There's no point here.

From the author question:
I want to add an unbounded column to Ultrawingrid
Unbounded means no persistence.
I keep my point, makes no sense to change the DB (at any level) to serve this purpose.
sarabandeCommented:
yes we go off-topic but i will remind you that you started the discussion by your suggestion ' I always found it easier and actually better to add the extra column in the datasource.' with 'datasource' you probably meant the client side but since we don't know whether the Author used a server db or a simple file-based db, it is pure speculation whether the db design was driven by the application or was made by a learned db designer.

By no means the DB should be ruled by the UI components flaws or limitations.
which flaws? which limitations? what are you talking about? do you know more from another thread? from this thread we only know that the User wants to add an additional column to display some info to a grid which was bound to a datasource. i don't know the UltrawinGrid but most likely the code to exchange data from and to the grid was generated by a wizard where it is sufficient to name a datasource and a db table or db view to create the full interface. if so, a new persistent column in the grid simply would need a new column in the table and you either can create the interface again or add the new column manually to the generated code. for a read-only column or column from a joint table, it is much more convenient to provide an appropriate view rather than to add columns to the grid and fill any additional info manually to those columns. the application would decide which data can be read by view and which data were read directly from tables. the db designer (if not identically with the developer) can't make the decision as they don't know what the data mean. their task is to create a relation db model which best fits to the requirements of the applications that were supposed to use the data. so, in case the additional columns should show related data from related entities or derived from other columns, this of course should be provided by an appropriate db view. if the data to display is not related to the other columns, it indeed would be a flaw. but, since it wouldn't make any sense at all, it is not very likely, that it is the case here.

I keep my point, makes no sense to change the DB (at any level) to serve this purpose.

i always found it a funny requirement that each of the 3 tiers database, application, and gui should have their own designer who in no way would let things happen that - as they know by their own judgement - was the job of any of the other tiers. since i have made all three tasks myself (in most projects), and even included an additional network tier, i never had those reservations and can't really understand why a tool like a database should not serve an additional text column if that is needed by the application or by the gui.

Sara
Alexandre SimõesManager / Technology SpecialistCommented:
I always found it easier and actually better to add the extra column in the datasource
The datasource is not the database, is the object that you use to bind the grid to (usually a list of objects or a DataTable).

Well, we're going no where with this :)
I don't agree with you and it's enough explanation why.
I have no clue about what you've been doing, and I certainly have no intention to start a "mine is bigger than yours" kind of discussion, but maybe a bit of pure SOA, with different teams managing each layer, will make you understand why the separation of concerns between architectural layers are so important to me (even when they are not explicit).

Nice talking to you, I like these philosophical discussions :)
Cheers!
Alexandre SimõesManager / Technology SpecialistCommented:

Now trying to answer the actual question

I've found that the grid supports adding unbound columns.
You can do that in the InitializeLayout event.
Here's the documentation from Infragistics (which is a bit poor)

A better link is actually THIS ONE that points to another question on EE.

So, just to sum up, to add an unbound column you can:
use the grid capabilities through the InitializeLayout event
bring it from the source (Above you have a cockfight about the possible ways to implement)

The best choice depends on what you actually want to do with that column.

Cheers mate!
rishaanAuthor Commented:
Thanks
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
.NET Programming

From novice to tech pro — start learning today.