ComboBox in Visual C# 2008 Express

To All:

I am new to the C# arena. Although I do have programming experience in Visual Foxpro.
I am trying to setup a basic Windows application where a lot of the user’s input will be based on selections from metadata tables.

I am using Visual C# 2008 Express Edition

I am trying to use comboboxes for displaying the majority of this metadata. My two main tables are “persons” and “docs.” In my first scenario, my persons table has four int fields for degrees - degree1, degree2, degree3, and degree4. The metadata table that I want to use for these fields in call “degree” and contains three fields - id, name, and description. (example data: id=1 name=“M.D.”, id=2 name=“Ph.D”, etc)

What I am trying to accomplish on my form with comboboxes is to display the “degree.name” field from the degree metadata table but store the “degree.id” value in the persons table for each respective degree box, hence the int data type.

In my “docs” table I have several similar fields. For example, I have an int field called “position” and a metadata table called “position” with the same three fields - id, name, and description. (example data: id=1 name=“Faculty”, id=2 name=“VIP Doctor”, etc.). I want to do the same thing here, display the position.name field to the user, but store the int choice in the docs.position int field.

Do I do this in code? Or is there a way to do it with these fancy “bindingsources” and “tableadapters” and such?

My reasoning for using “metadata” is to allow the user to make a change to the “name” in any metadata and have that change reflected throughout the application.

Am I asking for trouble? How common is the usage of metadata?

Thanks a million for your assistance.

Elgin Rogers

You can bind them quite easily, assuming your data sources implement the correct interfaces (I believe IBindable/IBindableList).

You would use the metadata table to fill the list for the combobox and then bind the list to the ‘degree’ fields on your persons table

There are numerous ways to actually accomplish this, I’ll run through a straight forward method using the datasource wizard

  1. Drop a combobox onto the page
  2. Go to the ‘Data Sources’ window which is usually docked on the left and add a new data source
  3. Pick your data provider (I’ve picked database)
  4. Set up your connection to connect to the database. I’ve just included the connection data in the application for the sake of simplicity
  5. Choose the table you wish to bind to - this will be the ‘metadata’ table with your degrees
  6. Finish the wizard, now in the datasources window you should have your table visible.
  7. Drag the whole table onto the combobox
  8. The program will assign the DisplayMember and ValueMember of the combobox automatically, you can modify it in the combobox properties - the ValueMember is the underlying identifier (the ID column) whereas the DisplayMember is the value you will actually see in the box
  9. Repeat steps 1-6 to add your ‘persons’ table to the datasources window (you can use the same connection as you used before, you won’t need to add another)
  10. Once you have added the persons table, in the datasources window expand the persons table so you can see all of the actual columns of the table.
  11. Find the column you will be binding to (the degree1 column for instance) and drag that onto the combobox.
  12. Finished!

Of course you will need to make sure that a certain record from your persons table is selected as the datasource contains a record pointer - you can always drop a BindingNavigator control on there and associate it with the datasource but it does look a bit ‘Microsoft Accesss’ so I don’t use them. Of course you will probably be getting to your persons form via a persons list in the first place so naturally you will be passing in the persons ‘ID’ and finding that person in the table using the ID

Either way your combobox is bound - your metadata is bound to the item list of the combobox and the persons tables ‘degree1’ field is bound to the selected value of the box. Visual Studio tends to be quite intelligent in this respect - if you drag a data column onto a bindable control it knows that it should bind the ‘value’ of that control to the data source. If you drag an entire data table or data container onto the control it knows to bind any ‘list’ objects to it.

VS 2008 will have already added the necessary code to ‘bind’ the objects at runtime - check your ‘onload’ function in the VB code

Of course you’ve only really got one thing to bind to on a textbox so you get different functionality (with respect though you can actually bind to any property of a control but most of the time why would you want to?)

This is just an example of how to bind to a control - the data exists in memory, so any changes you make won’t affect the database immediately. In fact I’m not 100% on how the data gets written back with tableadapters. You may want to read up on them, I usually use custom objects which implement the bindable interfaces.

Edit:
Looks like you can just use the ‘Update’ method on the tableadapter and pass in the dataset thats automatically defined for you (the dataset will be holding the actual data you are editing). So if you stick a ‘save’ button on the page and then in the save method call YourTableAdapter.Update(YourDataSource) that should do it - I’ll give it a try!

Charleh,

Thank you for the clear, concise reply. That is exactly what I needed and it works fine. You’re right, I will have to read up on the tableadapters. After getting your suggestion working, I immediately wanted go to designing a small form to manage my metadata tables.

I will start another thread regarding that, however. I want to ask about enforcing referential integrity and self-incrementing unique id’s.

Thanks again.

Slider16

Most of the time you will hanlde referential integrity checks via SQL constraints or a double layer via your business objects and constraints together. If you wrap your update statements in a try/catch you can always catch any SQLExceptions first.

Self incrementing IDs shouldn’t be a problem - the data objects should be smart enough to know not to try to insert a key, and they will let SQL pick it. You shouldn’t need to worry about these at all.

As long as SQL has the constraints you shouldn’t have any problems introduced by the application - the worst case is that the application throws an unhandled exception after trying to do an illegal insert. Of course if this causes any problems within the application and the data display it should be handled, but the actual underlying data shouldn’t be affected.