Stop default currency manager behavior?

[Marina]

Hi,

Let's say I have one datatable, that I want to use as the datasource for 2
dropdowns. So both are bound to the same one.

But now, when I select a row in dropdown A, the selected row in dropdown B
changes to the same thing! Each dropdown represents a different column in
the main record - they just happen to have the same options for their valid
values.

This behavior of the currency manager is very undesirable. I want both
dropdowns to have the same source - so if the values in the dropdown are
modified behind the scenes, that both dropdown receive notifications of
new/deleted/updated rows.

However, I want the whole concept of a 'current' row that is provided with
all the currency manager stuff to go away.

Is this possible? Or do I need to have 2 copies of the data for the
dropdown option values?

[Mike Edenfield]

Marina wrote:

Hi,

Let's say I have one datatable, that I want to use as the datasource for 2
dropdowns. So both are bound to the same one.

But now, when I select a row in dropdown A, the selected row in dropdown B
changes to the same thing! Each dropdown represents a different column in
the main record - they just happen to have the same options for their valid
values.

This behavior of the currency manager is very undesirable. I want both
dropdowns to have the same source - so if the values in the dropdown are
modified behind the scenes, that both dropdown receive notifications of
new/deleted/updated rows.

However, I want the whole concept of a 'current' row that is provided with
all the currency manager stuff to go away.

Is this possible? Or do I need to have 2 copies of the data for the
dropdown option values?

You need to explicitly create multiple binding contexts, one for each
drop-down. Each data source used in data binding is assigned it's own
binding context. Unfortunately, the form itself only has one binding
context, so by default, all controls on a form that are bound to a given
source have the same context.

To get around this problem, each set of controls you want to have it's
own context needs to be in it's own container, like a group box. At
run-time you simply assign a new BindingContext() to the BindingContext
property of each container, and those containers will no longer be
synchronized.

--Mike

[Marina]

Found solution: Initialize the BindingContext of each dropdown to a new
BindingContext prior to setting the datasource.

"Marina" <so*****@nospam.com> wrote in message
news:OA**************@TK2MSFTNGP11.phx.gbl...

Hi,

Let's say I have one datatable, that I want to use as the datasource for 2
dropdowns. So both are bound to the same one.

But now, when I select a row in dropdown A, the selected row in dropdown B
changes to the same thing! Each dropdown represents a different column in
the main record - they just happen to have the same options for their valid values.

This behavior of the currency manager is very undesirable. I want both
dropdowns to have the same source - so if the values in the dropdown are
modified behind the scenes, that both dropdown receive notifications of
new/deleted/updated rows.

However, I want the whole concept of a 'current' row that is provided with
all the currency manager stuff to go away.

Is this possible? Or do I need to have 2 copies of the data for the
dropdown option values?

[Marina]

That's what I ended up doing.

However, the problem is that the Value property for the dropdown is bound to
a row in the current record being edited. If the dropdown has a new binding
context, now when a record is selected in the grid (listed of records to
edit), the dropdown no longer has its value property correctly bound to the
current record. Where as before when it was using 1 bindingcontext, this
worked correctly.

So it seems I can have one or the other... but not both at the samet ime.

"Mike Edenfield" <ku****@not.kutulu.not.org> wrote in message
news:ue**************@TK2MSFTNGP14.phx.gbl...

Marina wrote:

Hi,

Let's say I have one datatable, that I want to use as the datasource for 2 dropdowns. So both are bound to the same one.

But now, when I select a row in dropdown A, the selected row in dropdown B changes to the same thing! Each dropdown represents a different column in the main record - they just happen to have the same options for their valid values.

This behavior of the currency manager is very undesirable. I want both
dropdowns to have the same source - so if the values in the dropdown are
modified behind the scenes, that both dropdown receive notifications of
new/deleted/updated rows.

However, I want the whole concept of a 'current' row that is provided with all the currency manager stuff to go away.

Is this possible? Or do I need to have 2 copies of the data for the
dropdown option values?

You need to explicitly create multiple binding contexts, one for each
drop-down. Each data source used in data binding is assigned it's own
binding context. Unfortunately, the form itself only has one binding
context, so by default, all controls on a form that are bound to a given
source have the same context.

To get around this problem, each set of controls you want to have it's
own context needs to be in it's own container, like a group box. At
run-time you simply assign a new BindingContext() to the BindingContext
property of each container, and those containers will no longer be
synchronized.

--Mike

[Mike Edenfield]

Marina wrote:

That's what I ended up doing.

However, the problem is that the Value property for the dropdown is bound to
a row in the current record being edited. If the dropdown has a new binding
context, now when a record is selected in the grid (listed of records to
edit), the dropdown no longer has its value property correctly bound to the
current record. Where as before when it was using 1 bindingcontext, this
worked correctly.

I realized this as soon as my message came back to me :( Essentially
your problem is that you want identical binding contexts for the data
source behind the Value property, but different binding contexts for the
data source behind the items themselves.

One possibility I can think of is to wrap your drop-downs (and other
controls, even) into a user control. Define two properties and update
the .Value of each drop-down in the property's set method. These
properties could be bound to the form's data source, thus use a single
binding context, while internally you could have any number of other
binding contexts. Somehow this seems like overkill but I can't come up
with anything better off the top of my head.

--Mike

[Marina]

This is a very interesting solution. In fact, the dropdown are already
wrapped up in user controls for the purposes of being able to swap them in
and out if we go with a different vendor for the dropdown, so I'm half way
there.

Great suggestion, I'll give it a shot.

"Mike Edenfield" <ku****@not.kutulu.not.org> wrote in message
news:OR**************@TK2MSFTNGP12.phx.gbl...

Marina wrote:

That's what I ended up doing.

However, the problem is that the Value property for the dropdown is bound to a row in the current record being edited. If the dropdown has a new binding context, now when a record is selected in the grid (listed of records to
edit), the dropdown no longer has its value property correctly bound to the current record. Where as before when it was using 1 bindingcontext, this worked correctly.

I realized this as soon as my message came back to me :( Essentially
your problem is that you want identical binding contexts for the data
source behind the Value property, but different binding contexts for the
data source behind the items themselves.

One possibility I can think of is to wrap your drop-downs (and other
controls, even) into a user control. Define two properties and update
the .Value of each drop-down in the property's set method. These
properties could be bound to the form's data source, thus use a single
binding context, while internally you could have any number of other
binding contexts. Somehow this seems like overkill but I can't come up
with anything better off the top of my head.

--Mike

[Greg Robinson]

Use a seperate bindingcontext
"Marina" <so*****@nospam.com> wrote in message
news:OA**************@TK2MSFTNGP11.phx.gbl...

Hi,

Let's say I have one datatable, that I want to use as the datasource for 2
dropdowns. So both are bound to the same one.

But now, when I select a row in dropdown A, the selected row in dropdown B
changes to the same thing! Each dropdown represents a different column in
the main record - they just happen to have the same options for their valid values.

This behavior of the currency manager is very undesirable. I want both
dropdowns to have the same source - so if the values in the dropdown are
modified behind the scenes, that both dropdown receive notifications of
new/deleted/updated rows.

However, I want the whole concept of a 'current' row that is provided with
all the currency manager stuff to go away.

Is this possible? Or do I need to have 2 copies of the data for the
dropdown option values?