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

Refreshing Linq query to update second DataGridView when position in first DataGridView changes

P: n/a
This seems to be something so simple that none of the hundred-odd tutorials
and forum threads that I have looked at (:-)) apparently thinks it's a
problem.

In a nutshell, I have two DataGridViews. Each has a BindingSource (and a
BindingNavigator). The first view populates successfully based upon a Linq
to SQL query in the Form Load (that is, the query is assigned to the
DataSource of that view's BindingSource, and the BindingSource is assigned
to the DataSource of the view). Or:

var personsQuery = from p in pim.persons
select p;

personBindingSource.DataSource = personsQuery;
personDataGridView.DataSource = personBindingSource;

The second view (which is actually address data accessed through a
person_address join table) is set up like:

addressBindingSource.DataSource = personsQuery;
addressDataGridView.DataSource = addressBindingSource;
addressDataGridView.DataMember = "addresses";

The method "addresses" in class "person" handles the join table. In any
case, when I run the app, the second DataGridView successfully populates
with the rows of the address table that correspond to the first row (first
"person") in the first DataGridView. So far so good.

Problem being, if I select another row in the first DataGridView (in this
example, a different "person"), I'd like to see the address or addresses
corresponding to that selected person. I have a SelectionChanged event
handler set up on the personDataGridView, and it is successfully reporting
the Position changes in the personBindingSource. I'll be damned if I can
figure out how to get the addressBindingSource to update, that is, to
effectively re-run the person.addresses method for a different person.

Any suggestions?

AHS
Jun 27 '08 #1
Share this Question
Share on Google+
1 Reply


P: n/a
"Arved Sandstrom" <as********@accesswave.cawrote in message
news:n%MZj.4613$KB3.3590@edtnps91...
This seems to be something so simple that none of the hundred-odd
tutorials and forum threads that I have looked at (:-)) apparently thinks
it's a problem.

In a nutshell, I have two DataGridViews. Each has a BindingSource (and a
BindingNavigator). The first view populates successfully based upon a Linq
to SQL query in the Form Load (that is, the query is assigned to the
DataSource of that view's BindingSource, and the BindingSource is assigned
to the DataSource of the view). Or:

var personsQuery = from p in pim.persons
select p;

personBindingSource.DataSource = personsQuery;
personDataGridView.DataSource = personBindingSource;

The second view (which is actually address data accessed through a
person_address join table) is set up like:

addressBindingSource.DataSource = personsQuery;
addressDataGridView.DataSource = addressBindingSource;
addressDataGridView.DataMember = "addresses";

The method "addresses" in class "person" handles the join table. In any
case, when I run the app, the second DataGridView successfully populates
with the rows of the address table that correspond to the first row (first
"person") in the first DataGridView. So far so good.

Problem being, if I select another row in the first DataGridView (in this
example, a different "person"), I'd like to see the address or addresses
corresponding to that selected person. I have a SelectionChanged event
handler set up on the personDataGridView, and it is successfully reporting
the Position changes in the personBindingSource. I'll be damned if I can
figure out how to get the addressBindingSource to update, that is, to
effectively re-run the person.addresses method for a different person.

Any suggestions?

AHS
Main problem sort of solved - I just took the BindingSources and
BindingNavigators out for now. Didn't really need them at this point
anyhow...

AHS
Jun 27 '08 #2

This discussion thread is closed

Replies have been disabled for this discussion.