Bizarre Databinding Issue

[Peter]

Hi!

I am having some very strange behavior with my databound controls. It's
taken a long time to isolate exactly what is provoking the problem, but I'm
still leagues away from solving it.

I have a DataView which filters a DataSet. Bound to this dataview is a
ListBox, via its DataSource property. The DisplayMember is the name property
of the row. Simple enough so far?

There is a button which adds a new row to the DataSet (directly, not via the
DataView). This seems to work fine in isolation and the change appears in
the DataView. There is also a button which rejects the changes made to the
DataSet. No problem.

Now, I add a TextBox to the form, bound to the same DataView (via the
TextBox's DataBindings collection). I want it to show a property of the
selected row in the ListBox, so it must use the same BindingContext.
Unfortunately, here is where things get bizarre. Suddenly, when I click the
button to add a new row, I not only get a new row with my parameters, but I
get a second "virtual" row which shows up merely as
"System.Data.DataRowView". And when I click the RejectChanges button, that
row doesn't go away. Clicking on it will sometimes crash the program as the
CurrencyManager tries to update all the bound controls, since the
System.Data.DataRowView seems not to be a real object... it just *looks*
like one.

Why is it doing that? Does this situation sound familiar to anyone? I can't
seem to duplicate the behavior in a test solution, either. I thought I read
somewhere that one shouldn't combine simple and complex databinding to the
same source, but how then can I use a TextBox to show a property of the
currently selected row?

 

[Cor Ligthert [MVP]]

Peter,

The datasource is the dataview
The display member has to be a columnname "myName"
While there is as well a value member

Cor

 

[Peter]

Yes, I know... the DisplayMember is set to the "Name" column of a table, and
the ValueMember is set to the "ID" column. That wasn't part of the problem,
so I didn't mention it.

 

[Peter]

Wow!

Well, it's taken me over a week to figure this out, and I thought I'd share
what I found in case anyone else ever has this kind of thing happen.

I wasn't exactly accurate in my previous post when I described the problem.
The TextBox I mentioned is not really a TextBox, but a custom control which
_contains_ a TextBox. The purpose of this was so that it could store an
internal value separate from what was displayed, and also so it could
perform a bunch of its own validation and limit keystrokes, etc. I added a
DataBinding to the control's internal value (a custom property)... NOT the
TextBox's Text property. The Set method on the internal value property
performs lots of checks and balances before plugging the value into the
TextBox. In addition, there is code in the TextBox's OnValidating and
OnValidated events, which can further modify the internal value if
necessary. This mish-mash of internal value changes caused scads of
CurrencyManager events to fire, and somewhere along the way phantom rows
were created, kind of like a feedback loop. I have yet to disentangle the
web of events that led to this exact behavior in the control itself, but at
least I know what manner of coding caused it.

Replacing my custom controls with real, down-home TextBoxes solved the
problem. I lost the constraints that I'd programmed into the custom control,
but for now, at least the proggie is functional.

Moral: If you're going to write a custom control that requires databinding,
you'd better be EXACTLY sure of the sequence of events that occur when its
value is updated.