bindingNavigator broken

[LabProARW]

This must be a common occurrence. I have a datagridview on a tabcontrol. A datagridview is on each tab. All but one of the bindingNavigators are bound/connected/linked with the datagridview on which they appear. Somehow one is broken and does not manipulate the datagridview that is appears with. Is there a place to go looking to correct this problem?
Thanks.

 

[Skydiver]

Without seeing your code, as well as the WinForms designer generated code, it's kind of hard to tell what could be broken. Are you absolutely sure that each one is bound to the right control?

Personally, since I hand write my WinForms forms, I've never had an issues with an incorrectly bound data grid view.

 

[NoUserHere]

This must be a common occurrence.

Why must it be a common occurrence?

Is there a place to go looking to correct this problem?

Yes, there is; In your code. I suggest looking where it's not bound.

 

[NoUserHere]

If you bound more than one, it seems evident to start looking at where the binding is missing for the one that is not working, and replicate the steps taken with your currently bound objects/controls.

 

[jmcilhinney]

A BindingNavigator is basically just a UI for a BindingSource. For a BindingNavigator to do anything at all, its BindingSource property must be set. If it's not, the buttons won't even be enable (if memory serves). If that property is set but using the BindingNavigator doesn't affect the DataGridView as expected then the same BindingSource has not been assigned to both the BindingSource property of the BindingNavigator and the DataSource property of the DataGridView. If you understand the tool you're using then the reason(s) for unexpected behaviour become fairly obvious.

 

[LabProARW]

A BindingNavigator is basically just a UI for a BindingSource. For a BindingNavigator to do anything at all, its BindingSource property must be set. If it's not, the buttons won't even be enable (if memory serves). If that property is set but using the BindingNavigator doesn't affect the DataGridView as expected then the same BindingSource has not been assigned to both the BindingSource property of the BindingNavigator and the DataSource property of the DataGridView. If you understand the tool you're using then the reason(s) for unexpected behaviour become fairly obvious.

Yes, if I understood the tool I was using I would not ask any questions - because the unexpected behaviour would be obvious.
I will take more time looking into form designer code. I have veered away from the "tool" a bit because coding was recommended for my application's specifics. I have come up upon too many times where the tool got broken somewhere deep in its guts and only starting from scratch fixed the problem after numerous suggestions were unsuccessful.

This particular problem is a bit odd in that the datagridview in question displays the correct records, and the BindingNavigator below it displays the correct number of records as shown on the datagridview, and finally the arrow buttons on the BindingNavigator change the record number it (the navigator) shows. What does not change, is the record navigation and row highlighting - which each of the other datagridviews on the other tabs do with their respective BindingNavigators.

 

[LabProARW]

This particular problem is a bit odd in that the datagridview in question displays the correct records, and the BindingNavigator below it displays the correct number of records as shown on the datagridview, and finally the arrow buttons on the BindingNavigator change the record number it (the navigator) shows. What does not change, is the record navigation and row highlighting - which each of the other datagridviews on the other tabs do with their respective BindingNavigators.

I have found the offending line of code for this problem. It was where jmcihinney directed. It was where the bindingNavigator was using the local data table source name used on the line above instead of the proper binding source.

 

[jmcilhinney]

Yes, if I understood the tool I was using I would not ask any questions - because the unexpected behaviour would be obvious.

Which then prompts the question, how much time did you spend reading the documentation for the types and members you were using and testing them? That is how you gain that understanding. While I don't want to discourage people from using sites like this one, they should be a last resort rather than a first option. If you are having trouble with a type or member and you haven't read the documentation for that type or member then any attempts you have made to solve your problem area incomplete.