Additional information:

This only happens on the form I've spent a week designing. I created a new
dummy form and passed the exact same instance of the DataSet through to it,
and both DataBinding methods work perfectly. So probably all I need to do is
throw away a week's work, start again, and hope that whatever gremlin got in
last time doesn't get in this time.

I really, really /HATE/ databinding.

Dear Mark

I understand that you are frustrated - so you have my sympathy. I hope
that the following isn't patronising or irritating. I apologise in
advance if this message adds to your frustration.

I'm not quite sure what you mean when you say that one set of
"DataBindings.Add" parameters work and another set don't.

I suspect that you might have a list control (DataGrid / ListBox etc)
or a CurrencyManager that deals with the navigation from one row to
another and that you wish to synchronise the Text property of a
TextBox with a specific column in the row in the list that the user or
program has navigated to.

As you probably know, one of the splendid things about databinding is
that you can have more than one control or currency manager displaying
a different "row" (or item) from the same "table" (or collection).

e.g. Configuring data binding for two DataGrids and two TextBoxes as
follows,,,

dataGrid1.DataSource = myCustomersDataset.Customers
dataGrid1.DataMember = ""
textBox1.DataBindings.Add(new System.Windows.Forms.Binding("Text",
myCustomersDataset.Customers, "CompanyName"))

dataGrid2.DataSource = myCustomersDataset
dataGrid2.DataMember = "Customers"
textBox2.DataBindings.Add(new System.Windows.Forms.Binding("Text",
this.myCustomersDataset, "Customers.CompanyName"))

... means that both DataGrids display the same Customer rows but they
navigate independently and textBox1 will keep in synch with dataGrid1
and textBox2 will keep in synch with dataGrid2.

On the other hand, such behaviour could be confusing if you expect
textBox2 to stay in synch with dataGrid1. And that's what I think
might have happened in your case. At least, that's what your example
DataBindings.Add parameters imply.

It is critical that the Binding.Add parameters for simple property /
property binding (such as TextBox.Text) match the complex binding
properties of list controls if you want to keep the list and simple
binding synchronised.

My simple minded, rule of thumb is that the DataSource property of the
DataGrid and the second parameter of the textbox's DataBindings.Add
method must refer to the same object. And, the string in the
datamember property of the DataGrid and the string (less any
characters to the right of the last full stop) of the third parameter
in  textbox's DataBindings.Add method must match. That sounds long
winded when I spell it out - but the rule is simple. (Although I
understand a bit more about what's going on underneath really).

As you've probably discovered - If you want to use the visual designer
to declare your data binding to a strongly typed DataSet component
then the DataGrid is the best suited list control to synchronise with
simple bound controls. That's mainly because the UI Type Editor thingy
that adds to the property binding to the TextBox in the visual
designer will generate the code in the format that matches the
DataGrid's DataSource / DataMember format in the DataGrid2 / TextBox2
example above.

Unfortunately, if you have no choice but to set a list control's
DataSource property using the "DataSetName.DataTablePropertyName"
format (as in the DataGrid1 / TextBox1 example above) then, I as far
as I know, you'll have to  write the code to add the simple binding
for TextBoxes (and the like).

This isn't a fault of databinding I think it's a limitation of the
visual designer / UI Type Editor.

Other possible reasons for "losing" the synchronisation of complex and
simple binding might include...

* The application programmer or a control (either by design or fault)
creates a new BindingContext.

* The original DataSet is replaced by a new instance *after* creating
the DataBindings. This results in the DataBinding infrastructure and
the DataSet variable referring to different objects.

* An exception is thrown in a bound property's property accessors. In
which case you can't catch the exception and the control's property
isn't updated but it keeps the focus.

I'm sorry this has been such a long winded and ill expressed message
but I hope it helps. Feel free to ask questions or to send me a sample
of the code that is causing you trouble.

Regards

Neil Allen