Hi Scott:

I appreciate your help. In the example I showed previously, the dataset is being created on instantiation. I did this after doing it in 2 steps. If the wasn't created prior to going into the intitializeComponent code, I would get a null reference error. That is why I put it there. I am very sure that I have data in the dataset at this point, as the messagebox tells me that there are 64 rows. This is the step just prior to registering the biz object and the call to initialize component.

I even added a redundant call to GetDataset after inititializeComponent to no avail.

I hear what you are saying about doing the databinding after initialization. With a normal windows combo, I would create the dataset(or dataview) and bind it to the combobox in the Form_Load. In this case, I thought the code that is being added via the designer ( the BindingSource, et al.) took care of populating the mmCombo based on what you filled in.

I can go into the form_load event and use the following code with good results:
Me.MmComboBox1.DataSource = biz.GetCurrentDataSet.Tables(0)
Me.MmComboBox1.DisplayMember = "Description"
Me.MmComboBox1.ValueMember = "StateCode"

I just believe that this is duplicating some functionality built into the mmCombo and didn't want to either run into conflicts or query the database twice for the data. If I have to do this, then why would I register an object for the combo and set the BindingSource, BindingSourceDisplayMember, BindingSourceValueMember, and BindingValueSource? Besides, I can get the above snippet of code to work with or without specifying all the mmBinding stuff.

I have used the above approach on an mmDatagrid and didn't have to go into the form load and specify the binding stuff. I thought the same approach would work for the mmCombo. If anyone has any other ideas or a good working sample, I would very much appreciate it.

Joe Walling
Walling Info Systems