SelectedIndexChanged event in comboA causes same event to fire in comboB

I have a vb.net 1.1 winforms app and have several combo boxes on a form 2
combos have the same data and are populated from the same data table using
the bind method. One is the ShipToAddress and the other is the
BillToAddress. when the user selects an address in the shipto combo, after
its SelectedIndexChanged event fires, the SelectedIndexChanged event fires
in the BillTo combo which, of course, is causing big problems.

Why is this? is it because they are bound to the same data table? Is it a
bug in vs 1.1? Can anyone recommend a fix or work around for this?

Thanks.

--
moondaddy@nospam.com

Mark
Fri Sep 24 19:39:49 CDT 2004

My first guess would be that it has something to do with both controls
sharing a common DataSource reference.

Try cloning the DataTable, so each ComboBox has equivalent, but
physically different, bound DataTables:

For instance, if your DataTable is called dt:

ComboA.DataSource = dt.Clone()
ComboB.DataSource = dt.Clone()

All of this is based upon the assumption (which may be incorrect) that
bound data container events may play a role in the triggerring of
certain control events. In general, it's usually safer to avoid
letting multiple objects share common references, unless you have a
specific reason to do so.

I hope this is useful...


On Fri, 24 Sep 2004 17:55:37 -0500, "moondaddy" <moondaddy@nospam.com>
wrote:

>I have a vb.net 1.1 winforms app and have several combo boxes on a form 2
>combos have the same data and are populated from the same data table using
>the bind method. One is the ShipToAddress and the other is the
>BillToAddress. when the user selects an address in the shipto combo, after
>its SelectedIndexChanged event fires, the SelectedIndexChanged event fires
>in the BillTo combo which, of course, is causing big problems.
>
>Why is this? is it because they are bound to the same data table? Is it a
>bug in vs 1.1? Can anyone recommend a fix or work around for this?
>
>Thanks.

moondaddy
Sat Sep 25 00:11:16 CDT 2004

Yes, this fixed the problem. actually just before I got your msg I tried
something similar such as creating a new dataset and merging the table into
it. I think cloning may be better. anyway, this worked, but I hope this
can get fixed in the future because if I need to update the dataset client
side and a bunch of controls are using the dataset as a datasource, then
every time the dataset gets updated, all the controls would have to be
rebound again which defeats some of the benefit of ado dataset and binding
them to controls where the data in the control stays in sync with the
dataset.

Thanks for the reply.

--
moondaddy@nospam.com
"Mark Mischke" <markATmischkeDOTorg@nospam.com> wrote in message
news:a9d9l0t04qqnfdsqndt7i6a7qcmsnkpv42@4ax.com...
> My first guess would be that it has something to do with both controls
> sharing a common DataSource reference.
>
> Try cloning the DataTable, so each ComboBox has equivalent, but
> physically different, bound DataTables:
>
> For instance, if your DataTable is called dt:
>
> ComboA.DataSource = dt.Clone()
> ComboB.DataSource = dt.Clone()
>
> All of this is based upon the assumption (which may be incorrect) that
> bound data container events may play a role in the triggerring of
> certain control events. In general, it's usually safer to avoid
> letting multiple objects share common references, unless you have a
> specific reason to do so.
>
> I hope this is useful...
>
>
> On Fri, 24 Sep 2004 17:55:37 -0500, "moondaddy" <moondaddy@nospam.com>
> wrote:
>
> >I have a vb.net 1.1 winforms app and have several combo boxes on a form
2
> >combos have the same data and are populated from the same data table
using
> >the bind method. One is the ShipToAddress and the other is the
> >BillToAddress. when the user selects an address in the shipto combo,
after
> >its SelectedIndexChanged event fires, the SelectedIndexChanged event
fires
> >in the BillTo combo which, of course, is causing big problems.
> >
> >Why is this? is it because they are bound to the same data table? Is it
a
> >bug in vs 1.1? Can anyone recommend a fix or work around for this?
> >
> >Thanks.
>

Stephany
Sun Sep 26 03:23:16 CDT 2004

I think that cloning datatables or creating new datatables is overkill.

This is what dataviw objects are designed for.

If you bind multiple controls to a databale then then when the current
pointer in the table moves then all the bound controls will reflect that
movement.

If you have a dataview for each control then the current pointer moves in
the dataview and not the datatable, thus making each control independent but
still getting it's list from the same physical data but via a different
logical path.


"moondaddy" <moondaddy@nospam.com> wrote in message
news:%23hZY2yroEHA.3424@TK2MSFTNGP12.phx.gbl...
> Yes, this fixed the problem. actually just before I got your msg I tried
> something similar such as creating a new dataset and merging the table
into
> it. I think cloning may be better. anyway, this worked, but I hope this
> can get fixed in the future because if I need to update the dataset client
> side and a bunch of controls are using the dataset as a datasource, then
> every time the dataset gets updated, all the controls would have to be
> rebound again which defeats some of the benefit of ado dataset and binding
> them to controls where the data in the control stays in sync with the
> dataset.
>
> Thanks for the reply.
>
> --
> moondaddy@nospam.com
> "Mark Mischke" <markATmischkeDOTorg@nospam.com> wrote in message
> news:a9d9l0t04qqnfdsqndt7i6a7qcmsnkpv42@4ax.com...
> > My first guess would be that it has something to do with both controls
> > sharing a common DataSource reference.
> >
> > Try cloning the DataTable, so each ComboBox has equivalent, but
> > physically different, bound DataTables:
> >
> > For instance, if your DataTable is called dt:
> >
> > ComboA.DataSource = dt.Clone()
> > ComboB.DataSource = dt.Clone()
> >
> > All of this is based upon the assumption (which may be incorrect) that
> > bound data container events may play a role in the triggerring of
> > certain control events. In general, it's usually safer to avoid
> > letting multiple objects share common references, unless you have a
> > specific reason to do so.
> >
> > I hope this is useful...
> >
> >
> > On Fri, 24 Sep 2004 17:55:37 -0500, "moondaddy" <moondaddy@nospam.com>
> > wrote:
> >
> > >I have a vb.net 1.1 winforms app and have several combo boxes on a form
> 2
> > >combos have the same data and are populated from the same data table
> using
> > >the bind method. One is the ShipToAddress and the other is the
> > >BillToAddress. when the user selects an address in the shipto combo,
> after
> > >its SelectedIndexChanged event fires, the SelectedIndexChanged event
> fires
> > >in the BillTo combo which, of course, is causing big problems.
> > >
> > >Why is this? is it because they are bound to the same data table? Is
it
> a
> > >bug in vs 1.1? Can anyone recommend a fix or work around for this?
> > >
> > >Thanks.
> >
>
>

Mark
Mon Sep 27 10:04:23 CDT 2004

Ah, good point. DataViews are definitely a better approach...


On Sun, 26 Sep 2004 20:23:16 +1200, "Stephany Young" <noone@localhost>
wrote:

>I think that cloning datatables or creating new datatables is overkill.
>
>This is what dataviw objects are designed for.
>
>If you bind multiple controls to a databale then then when the current
>pointer in the table moves then all the bound controls will reflect that
>movement.
>
>If you have a dataview for each control then the current pointer moves in
>the dataview and not the datatable, thus making each control independent but
>still getting it's list from the same physical data but via a different
>logical path.
>
>
>"moondaddy" <moondaddy@nospam.com> wrote in message
>news:%23hZY2yroEHA.3424@TK2MSFTNGP12.phx.gbl...
>> Yes, this fixed the problem. actually just before I got your msg I tried
>> something similar such as creating a new dataset and merging the table
>into
>> it. I think cloning may be better. anyway, this worked, but I hope this
>> can get fixed in the future because if I need to update the dataset client
>> side and a bunch of controls are using the dataset as a datasource, then
>> every time the dataset gets updated, all the controls would have to be
>> rebound again which defeats some of the benefit of ado dataset and binding
>> them to controls where the data in the control stays in sync with the
>> dataset.
>>
>> Thanks for the reply.
>>
>> --
>> moondaddy@nospam.com
>> "Mark Mischke" <markATmischkeDOTorg@nospam.com> wrote in message
>> news:a9d9l0t04qqnfdsqndt7i6a7qcmsnkpv42@4ax.com...
>> > My first guess would be that it has something to do with both controls
>> > sharing a common DataSource reference.
>> >
>> > Try cloning the DataTable, so each ComboBox has equivalent, but
>> > physically different, bound DataTables:
>> >
>> > For instance, if your DataTable is called dt:
>> >
>> > ComboA.DataSource = dt.Clone()
>> > ComboB.DataSource = dt.Clone()
>> >
>> > All of this is based upon the assumption (which may be incorrect) that
>> > bound data container events may play a role in the triggerring of
>> > certain control events. In general, it's usually safer to avoid
>> > letting multiple objects share common references, unless you have a
>> > specific reason to do so.
>> >
>> > I hope this is useful...
>> >
>> >
>> > On Fri, 24 Sep 2004 17:55:37 -0500, "moondaddy" <moondaddy@nospam.com>
>> > wrote:
>> >
>> > >I have a vb.net 1.1 winforms app and have several combo boxes on a form
>> 2
>> > >combos have the same data and are populated from the same data table
>> using
>> > >the bind method. One is the ShipToAddress and the other is the
>> > >BillToAddress. when the user selects an address in the shipto combo,
>> after
>> > >its SelectedIndexChanged event fires, the SelectedIndexChanged event
>> fires
>> > >in the BillTo combo which, of course, is causing big problems.
>> > >
>> > >Why is this? is it because they are bound to the same data table? Is
>it
>> a
>> > >bug in vs 1.1? Can anyone recommend a fix or work around for this?
>> > >
>> > >Thanks.
>> >
>>
>>
>

moondaddy
Tue Sep 28 22:04:56 CDT 2004

Thanks! That's really good to know. I thought I was saving steps by just
binding straight to the table, but I know better now.

--
moondaddy@nospam.com
"Stephany Young" <noone@localhost> wrote in message
news:OLmHSI6oEHA.1308@TK2MSFTNGP14.phx.gbl...
> I think that cloning datatables or creating new datatables is overkill.
>
> This is what dataviw objects are designed for.
>
> If you bind multiple controls to a databale then then when the current
> pointer in the table moves then all the bound controls will reflect that
> movement.
>
> If you have a dataview for each control then the current pointer moves in
> the dataview and not the datatable, thus making each control independent
but
> still getting it's list from the same physical data but via a different
> logical path.
>
>
> "moondaddy" <moondaddy@nospam.com> wrote in message
> news:%23hZY2yroEHA.3424@TK2MSFTNGP12.phx.gbl...
> > Yes, this fixed the problem. actually just before I got your msg I
tried
> > something similar such as creating a new dataset and merging the table
> into
> > it. I think cloning may be better. anyway, this worked, but I hope
this
> > can get fixed in the future because if I need to update the dataset
client
> > side and a bunch of controls are using the dataset as a datasource, then
> > every time the dataset gets updated, all the controls would have to be
> > rebound again which defeats some of the benefit of ado dataset and
binding
> > them to controls where the data in the control stays in sync with the
> > dataset.
> >
> > Thanks for the reply.
> >
> > --
> > moondaddy@nospam.com
> > "Mark Mischke" <markATmischkeDOTorg@nospam.com> wrote in message
> > news:a9d9l0t04qqnfdsqndt7i6a7qcmsnkpv42@4ax.com...
> > > My first guess would be that it has something to do with both controls
> > > sharing a common DataSource reference.
> > >
> > > Try cloning the DataTable, so each ComboBox has equivalent, but
> > > physically different, bound DataTables:
> > >
> > > For instance, if your DataTable is called dt:
> > >
> > > ComboA.DataSource = dt.Clone()
> > > ComboB.DataSource = dt.Clone()
> > >
> > > All of this is based upon the assumption (which may be incorrect) that
> > > bound data container events may play a role in the triggerring of
> > > certain control events. In general, it's usually safer to avoid
> > > letting multiple objects share common references, unless you have a
> > > specific reason to do so.
> > >
> > > I hope this is useful...
> > >
> > >
> > > On Fri, 24 Sep 2004 17:55:37 -0500, "moondaddy" <moondaddy@nospam.com>
> > > wrote:
> > >
> > > >I have a vb.net 1.1 winforms app and have several combo boxes on a
form
> > 2
> > > >combos have the same data and are populated from the same data table
> > using
> > > >the bind method. One is the ShipToAddress and the other is the
> > > >BillToAddress. when the user selects an address in the shipto combo,
> > after
> > > >its SelectedIndexChanged event fires, the SelectedIndexChanged event
> > fires
> > > >in the BillTo combo which, of course, is causing big problems.
> > > >
> > > >Why is this? is it because they are bound to the same data table?
Is
> it
> > a
> > > >bug in vs 1.1? Can anyone recommend a fix or work around for this?
> > > >
> > > >Thanks.
> > >
> >
> >
>
>