Windows form data binding tutorial

Select Products from under the Category data source and drag it on the form. Edit the columns on the productDataGridView. The value for the ProductId property is generated by the database after we save the data. In the next section we will add code to the code behind to set categoryBindingSource. DataSource to the collection of entities that are currently tracked by DbContext. When we dragged-and-dropped Products from under the Category, the WinForms took care of setting up the productsBindingSource.

DataMember property to Products. Because of this binding, only the products that belong to the currently selected Category will be displayed in the productDataGridView. Enable the Save button on the Navigation toolbar by clicking the right mouse button and selecting Enabled. Add the event handler for the save button by double-clicking on the button.

This will add the event handler and bring you to the code behind for the form. We'll now add the code to use the ProductContext to perform data access.

Update the code for the main form window as shown below. The code declares a long-running instance of ProductContext. The ProductContext object is used to query and save data to the database. The Dispose method on the ProductContext instance is then called from the overridden OnClosing method. The code comments provide details about what the code does. ProductContext database is created for you.

Skip to main content. This browser is no longer supported. Download Microsoft Edge More info. Contents Exit focus mode. Is this page helpful? BindingSource Describes the class that encapsulates a data source for binding to controls. BindingSource Component Contains a list of topics that demonstrate how to use the BindingSource component. DataGridView Control Provides a list of topics that demonstrate how to use a bindable datagrid control. Also see Accessing Data in Visual Studio.

Skip to main content. Common reports include lists, invoices, and summaries. Items are usually formatted into columns of lists, with sub-items organized under each list item, but you should choose the layout that best suits the data.

A common way to enter large amounts of related data or to prompt users for information is through a data entry form. Users can enter information or select choices using text boxes, option buttons, drop-down lists, and check boxes.

Information is then submitted and stored in a database, whose structure is based on the information entered. Specifically, there are two tables of data with a relation connecting them—in the classic business example, a "Customers" table and an "Orders" table with a relationship between them linking customers and their respective orders.

Often, as part of a larger data display, a ComboBox control is used to display and manipulate data. The key is that the data displayed in the ComboBox control is different than the data written to the database. For example, if you have a ComboBox control displaying the items available from a grocery store, you would probably like to see the names of the products bread, milk, eggs. However, to ease information retrieval within the database and for database normalization, you would probably store the information for the specific items of a given order as item numbers , , and so on.

Thus, there is an implicit connection between the "friendly name" of the grocery item in the ComboBox control on your form and the related item number that is present in an order. Currency management? Rather, it's Microsoft's way of saying "currentness". In other words, BindingSource keeps track of which object is the current one in its List. Internally, BindingSource uses a CurrencyManager , which holds a reference to the list and keeps track of the current item.

When the user edits the model name, the control modifies the BindingSource. But, how does the control notify the BindingSource about the change to its Text property? Remember, from a control's perspective, the DataSource is just an Object.

Also, I wonder: do controls have some kind of special support for BindingSource specifically, or would they accept other classes as long as they implement a certain interface? In other words, is data binding based on duck typing , or is it special-cased for certain classes or interfaces?

And, what is expected from data sources, in general? Well, by using Visual Studio and following these instructions , you can trace through the. NET Framework source code. And, there is a special tool with which you can do the same thing in other versions of Visual Studio, plus, it downloads the complete source code rather than only the part you need. It is also possible to examine the code by disassembling it with Reflector and the FileDisassembler add-in, but this approach does not let you trace through the code.

Unfortunately, it's a really enormous and complicated code. After several hours, I figured out how exactly a control notifies the BindingSource that its Text property changed, and how the DataGrid is notified. I will now explain how, but the explanation is so convoluted you probably won't want to hear it. Feel free to skip a few paragraphs. This is complicated.

Personally, I find this architecture highly unintuitive. And, the above was especially difficult to discover because the BCL Base Class Library is JIT-optimized, which means some functions are inlined missing from the call stack , and most variables cannot be seen in the debugger.

Plus, Intellisense doesn't work in it. Plus, most of the code lacks comments. But, I was at least able to determine that BindingContext remember, there is a BindingContext for each control has special-case code for data sources that implement ICurrencyManagerProvider which BindingSource implements , IList , and IListSource , so you can expect that your data source must implement one of these interfaces in order to act like a list. It does not seem to be special-cased for DataSet , although some code is special-cased for some interfaces, e.

Unfortunately, the whole binding architecture seems tightly coupled to itself i. Therefore, I recommend trying to figure it out from experimentation and documentation. It would be nice to see all this laid out on a few UML diagrams, though. For one thing, you can bind to a list within a DataSource. Unlike last time, this time we set the DataMember property. Now, you get a list of passengers for a single Airplane , instead of a list of Airplane s:.

Tip : If you want to show an ADO. Notice that we can either add items to the BindingSource bs or to a. Passengers directly. But, changing a. There will still only be four items in the list.

At first, you see Oops 1 at the top; Oops 2 will suddenly appear when you move your mouse over the grid. It doesn't work correctly because the BindingSource was not notified of the changes.

If you must modify the underlying list, you can refresh the on-screen list by calling BindingSource. ResetBindings false. You can bind to an object directly without a BindingSource. For this example and only this example , add a Button button1 to the form. At run-time, it will look like this:. This example seems to work perfectly fine, so why bother to use a BindingSource at all? You can show a list within a record in a ListBox or ComboBox.