More C# help... JTable equivalent this time

thesadguy

Active Member
Joined
Nov 29, 2008
Messages
70
Reaction score
0
Hi everyone...

Thanks for bearing with me through this learning curve, and especially to those who have provided replies!

I'm looking for something equivalent to Java's JTable.

In Java, I'd create a TableModel (or derivative) and use that to initialise a JTable.

It seems the way to do this in C# is to use DataGrid, but I'm a bit confused as to how to do this.

Does anyone have an idea how to do this?
 
Start by creating a new DataSet (right-click, Add, NewItem, DataSet), then in the dataset designer create a new DataTable. (If you drag the table over from the Server Explorer it will automatically create a Table Adaptor to populate the data from the database)

Now, on your form you add a DataGrid, then Bind the DataGrid to the DataTable by setting the DataSource property (I think)

As soon as you populate the DataTable and refresh it, the DataGrid will contain the rows from the DataTable.

Thee's a bit more work involved if your want to do updates and insert from the Grid back to the Dataset.

P.S. Seems like you're progressing at quite a pace, well done!
 
Last edited:
dataset is bit resource intense; depends what he wants to use it for. for most simple queries you can just use a forward reader and pass the datatable to the datagrid...

i would however suggest that you tryout a few good programming sites like
www.codeproject.com

...many more are listed in sticky here
http://mybroadband.co.za/vb/showthread.php?t=43066
 
Last edited:
dataset is bit resource intense; depends what he wants to use it for. for most simple queries you can just use a forward reader and pass the datatable to the datagrid...

Memory is cheap, programmers aren't ;)

Datasets are quick and easy.
 
quick and easy isn't always the proper way of optimal programming.

But it is when you're learning a new programming language and datasets are the recommended way to do what he's trying to do.

Think about the alternatives:

Option 1: You get a system that been 'optimised' so much that only the original developer knows whats going on and he's left so you have to spend a few million rewriting it.

Option 2: You get a system that's been written using all the recommended patterns and methodologies so any qualified developer can sit down and start maintaining it within a day. It's a bit slower than option 1 so you have to throw an extra server at it to get the same performance.

Which is better, Option 1 or Option 2?
 
Last edited:
But it is when you're learning a new programming language and datasets are the recommended way to do what he's trying to do.

Think about the alternatives:

Option 1: You get a system that been 'optimised' so much that only the original developer knows whats going on and he's left so you have to spend a few million rewriting it.

Option 2: You get a system that's been written using all the recommended patterns and methodologies so any qualified developer can sit down and start maintaining it within a day. It's a bit slower than option 1 so you have to throw an extra server at it to get the same performance.

Which is better, Option 1 or Option 2?

I disagree. Any proper programmer will write properly which can be read without any issues and will be tested properly to work the first time period, as to any decent development center will enforce that with a "coding style" to be used by all who work there so that maintenance is not encumbersome.

Either you are programing pro optimized and correctly or you are coding a peace if bloatware crap which does not take into mind system performance.

An attitude of "there is always enough memory" stinks; lazy programmers are bad programmers and they are usually the copy-paste babies who don't know just wtf they just pasted as long as it works it works who cares....
 
Last edited:
Sorry, but that's not the way people are thinking any more.

The days of optimising your code to run in 640K of memory are over.

Customers are demanding maintainabilty as their first priority for large systems. With distributed hardware and services performance is no longer a priority for them.

The days of the cowboy programmer who could come in and shave a millisecond off each transaction are over. Customers have realised it's much cheaper to rely on standard commodity programmers who can walk in and start coding straight away because the all the code is based on reccomened methodolgies.

It's all about money now. Business peole have realised that highly optimsed code costs many times more than standardised code that performs the same with a bit of extra hardware.
 
Sorry, but that's not the way people are thinking any more.

The days of optimising your code to run in 640K of memory are over.

Customers are demanding maintainabilty as their first priority for large systems. With distributed hardware and services performance is no longer a priority for them.

The days of the cowboy programmer who could come in and shave a millisecond off each transaction are over. Customers have realized it's much cheaper to rely on standard commodity programmers who can walk in and start coding straight away because the all the code is based on recommended methodologies.

It's all about money now. Business people have realized that highly optimized code costs many times more than standardized code that performs the same with a bit of extra hardware.

Well then; i suppose we will have to agree to disagree-
you go on and enjoy bloatware programming with common-walk-in-coders and i will go on and write proper code that's performance pro.
 
Thanks for the replies guys!

I ended up writing my own custom classes using an arrangement of panels. Worked quite nicely and I achieved the exact look I was looking for.

Thanks again!
 
Bickering this early in the year? ;)

There is a way to use recommended practices AND optimise for performance. In this (admittedly, simple) example, using a plain DataTable as opposed to a dataset would be a good start in terms of performance, without losing much (if any) functionality.
 
Bickering this early in the year? ;)

There is a way to use recommended practices AND optimise for performance. In this (admittedly, simple) example, using a plain DataTable as opposed to a dataset would be a good start in terms of performance, without losing much (if any) functionality.

I wanted to recommend that, but was afraid of the stoning I'd receive. I never use DataSets if the result-set is contained in only one table. It just doesn't make any sense.
 
I wanted to recommend that, but was afraid of the stoning I'd receive. I never use DataSets if the result-set is contained in only one table. It just doesn't make any sense.

Agreed, but how often do you get a real-world system with one table?

Even tiny little systems have dozens of tables in the database and you'd need a well designed data model before you even stated to write code.

If he's learning, then rather learn the right way from the start.
 
Agreed, but how often do you get a real-world system with one table?

Even tiny little systems have dozens of tables in the database and you'd need a well designed data model before you even stated to write code.

If he's learning, then rather learn the right way from the start.

Agreed, conceptually. However, I'd rather have a single table (did I say table? I meant result :)) returned from the database than pull 5 tables and setup relationships in a DataSet. Actually, I'd rather use objects, rather than datasets, but that's another discussion entirely. ;)

It all depends on how you want to code it.
 
Last edited:
Agreed, conceptually. However, I'd rather have a single table returned from the database than pull 5 tables and setup relationships in a DataSet. Actually, I'd rather use objects, rather than datasets, but that's another discussion entirely. ;)

It all depends on how you want to code it.

+1 gazillion. I prefer using objects entirely. Object[] FTW! :D

BUT whenever I have to work with result-sets from the database, I return only the data that is necessary on the specific page. I never store huge sets of data in a DataSet and manipulate it in that way. 99% of the time it is only data from a single table. Our database design is very complicated and advanced. We never select data directly from a table - always views. So I already have all the fields I need from the different tables.
 
whenever I have to work with result-sets from the database, I return only the data that is necessary on the specific page..

That sounds like a maintenance nightmare. You've created a direct dependency between your database and your user interface, change one and you have to go change the other as well.

When I design systems, I start by designing the data model to suit the business domain (not the user interface). If you design the data model to match the UI, then you've created a dependency between the two.

Step 1 for me is to design the data model. Once I've got the data model to accurately represent the business domain, then I give it to the programmer and let him go wild with it. He can design the UI with as many bells and whistles as he wants, but he has to work to the data model that he has been given.

Of course there's going to be redundancy in any given UI representation of the data, but data model will always be an accurate representation of the business domain even though the UI may choose not to display all the data it's been given.

That gives you the flexibility to design various UI's using different delivery platforms without having to redesign the data model for each platform. So there is never a dependency between the UI and the data.
 
Last edited:
Deenem, you have a good point there. I've recently started focusing on decoupled layers - thanks largely to the MVC model - and while it means more work, it certainly helps with the changes later on.
 
Top
Sign up to the MyBroadband newsletter
X