Printable View
Hi all.
In excel I can refer to a cell by giving the cell address something like A7 or W3
I can do something like this:
If Range ("A1").Value = 22 Then Range("B1").Value ='hello'
Is it possible to access cells in DatagridView in a similar manner.
Or put another way how do I programmatically access the DataGridView
cells to place data into them.
Kind Regards
Al
It's not quite like Excel in that regard, but a bit similar. There are two ways you can access the DGV. One option is by row an column:
However, it is much more common to have a datatable and set the datatable as the datasource for the DGV. Then, any interaction you have as far as adding/editing data is done against the datatable, with the DGV just being a display of the table. Which option you choose is entirely up to you. The datatable is so common because it offers up a couple advantages. The first is that you can build datatables as a query from a database. The other is that datatables can be stored/read from XML files very easily, which means that they can be used to persist the data from one run of the program to the next.Code:myDGV.Rows(y).Columns(x).Value = YourValueHere
Hi Shaggy Hiker
Many thanks for your reply.When you talk of datatables is that the virtual table between form and database?
many thanks
al
I've heard of people talk about it that way, but there is nothing virtual about it. A datatable is a .NET object. It's an in-memory table that can display data from a database, but it's really just an object with a collection of rows. You don't have to have a database behind it, or anything else. You can create a datatable just like any other object (with New), then add columns to the columns collection, and rows to the Rows collection. Usually, this is done automatically by a database query, but it doesn't HAVE to be that way. So, I wouldn't call a datatable virtual. It's just a thing.
Hi SH,
Many thanks for your reply.It's quite an interesting 'thing' this datatable object,but In my own amatuer way it seems a bit surplas to requirements.It seems that every thing that is done to a datatable can be done to a database,and placed in a datagridview.Am I missing something here.I have read the explanation in the HomeNLearn online course(great little course and free),but still cant see why we need another layer betwixt database and datagrid.In some ways it reminds me of web page technology,with virtual servers and the like
I suppose it's just the way the .net framweork operates. :)
In the past, you had a more direct tie between the DB and the display (not a DGV, but something close). That meant that you had to be connected to the DB ALWAYS! That really sucks for multiple users. Connections aren't unlimited, and can have some implications for some databases. You had to take that into account. For example, if you are viewing row R and somebody else wants to edit row R....what happens? It might work, or you might have locked the record, or the change might happen behind you, or whatever. Furthermore, every time you change records, you have to make a round trip to the database to get whatever new information is needed. You might think that's not so bad, because you load ALL the data into the display, but that is likely not how the grid works. It may or may not have all the records in memory. It may have only those that need to be drawn to the screen. The other data is not there, yet. So, you might be going back and forth to the DB frequently. This will pretty much HAVE to be true if you want to be able to edit any of the records, because the only place the edit can happen is against the DB. Not only does this require the data to flow back and forth to the DB, it has to be able to identify the row, which will mean more data is flowing than JUST the edit. If the connection is across a slow wire, you can imagine what this would do to performance.
The way it works with a datatable is that you open a connection, fill the datatable, then close the connection. All the work is now done against that copy of the data in the datatable. Any round trips (the same issues still apply) are now round trips to local RAM, which takes nanoseconds, rather than round trips to a database wherever it might be located, which can take many milliseconds, or worse. Also, you aren't locking any records, except for the tiny amount of time needed to fill the datatable (less than that, really). If somebody changes the records you have brought in to the datatable, it doesn't affect you any, until you push your updates back to the database, at which time the DB applies rules to decide what to do with the updates (lookup optimistic concurrency for more on this). So, you have faster performance, you aren't tying up a DB connection for long times, and you aren't locking database records. I may have overlooked some benefits, but those are good enough to justify using a datatable rather than a direct connection.