Thanks, Scott.

Yes, the second (lookup) form will not update any data. So, you're right, there's no terribly compelling reason to make it an MM.NET form.

I did find that if you override the constructor for a form that inherits from another form, then the MM.NET BindingSource property lookup doesn't work, so having the different constructor signature is tripping something up.

At the same time, exposing a Set accessor method for the DataSet and setting it in from calling form, after instantiating the lookup form, didn't work either. For example, in the calling form:

VendorLookup lookup = new VendorLookup();
lookup.VendorDataSet = this.oVendor.GetCurrentDataSet()
DialogResult dr = lookup.ShowDialog(this);
if(dr == DialogResult.OK)
{
	...
}

Perhaps MM.NET wants to have the DataSet defined at the time the constructor runs.

So, based on my knowledge at this point, I have two choices:

1) Use a non-MM.NET form for the lookup. (I have that working fine in another project, passing the DataSet via a form constructor parameter.)

or

2) Use an MM.NET form for the lookup and have it hit the database to populate its DataSet, rather than accepting a DataSet passed to it.