By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
434,921 Members | 1,433 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 434,921 IT Pros & Developers. It's quick & easy.

Bizarre Databinding Issue

P: n/a
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?

May 19 '07 #1
Share this Question
Share on Google+
3 Replies


P: n/a
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" <st*****@hotmail.comschreef in bericht
news:01******************@newsread2.news.pas.earth link.net...
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?

May 19 '07 #2

P: n/a
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.

"Cor Ligthert [MVP]" <no************@planet.nlwrote in message
news:es**************@TK2MSFTNGP04.phx.gbl...
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" <st*****@hotmail.comschreef in bericht
news:01******************@newsread2.news.pas.earth link.net...
>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?

May 19 '07 #3

P: n/a
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.

"Peter" <st*****@hotmail.comwrote in message
news:01******************@newsread2.news.pas.earth link.net...
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?
May 19 '07 #4

This discussion thread is closed

Replies have been disabled for this discussion.