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.