I have a form with 1 bindingsource control.
A grid and several standalone controls (texts and labels) are sharing the binding with this source.
Every time a user changes the grid row i want to enable/disable some controls.
Should i write this code in BindingSource.CurrentChanged event or in DataGridView1.RowValidating event?
I tend to use the bindingsource event as i think it gives me globally what i want, but i "feel" its wrong to do UI code in there.
Opinions?
It is not wrong to use BindingSource.CurrentChanged evnt to handle UI code. BindingSource is a WinForms component.
The dataGridView.RowValidating event fires before BindingSource event.
Depending an what you need, I'd say it ok to use anyone of them :)
Related
Assume we have a Combobox in a winforms application which its items bound to a Bindingsource.
I need to fire an event when the user changes the selected item in the combobox.
Should I handle the combobox.selectedindexchanged event or bindingsource.currentchanged event. Which is better in case of performance or anything else?
I've searched a lot to find an article or something about it, but can't find something straight and clear. I appreciate any suggestion or workaround.
UPDATE
I need to call a function base on the selected object ID after user select an Item from combobox. (ID is accessible from both Combobox1.SelectedValue and bindingSource1.Current.ID). In this case which event shouldI choose?
If you wish to handle event when end user selects any item in UI then you should go with combobox.selectedindexchanged because bindingsource.currentchanged can be triggered for number reasons such as mentioned here on MSDN blog, BindingSource.CurrentChanged Event so in case, you need to handle an event for any of the reason mentioned in MSDN then it will unnecessarily go through logic you might have coded for selection change event. Your code should be specific, while handling events.
If a ComboBox is bound to a BindingSource you usually leave it at that. If you do need to tap into events you're better off creating more properties in the Business Object. For example say you want to disable a button if the combobox is Index Value == 0, simply create a property in the Business Object that the Enabled property of the Button is bound to, eg:
public virtual bool IsFunctionEnabled
{
get { return (An_Items_SelectedIndex > 0); }
}
If you really need to do stuff in the ComboBox's selected index change event I would lean towards doing it in the Presentation Tier as I don't recommend mucking with binding source controls or their events.
The best solution is handling everything in your Business Objects and binding your controls via BindingSources. Doing any logic in the Presentation Tier makes it hard to test and changing anything in the BindingSources add a lot of testing.
After all, I am getting to know it should be better to use Combobox.SelectedIndexChanded event, because I am interacting with a user and looking for a response from UI. Although here the events do the same for me, but Bindingsource.CurrentChanged event can be used in case I wanted to track the current object changes from anywhere like a list change or something, not exactly the UI. Its better to use combobox events here I believe.
DataGrid has 2 events:
ASP.NET DataGrid:
ItemCreated
ItemDataBound
When you bind to a data source ItemCreated gets fired followed by ItemDataBound.
I need to know if anyone can think of any good reason of using ItemCreated.
I can't find anything versus putting the whole code in ItemDataBound event(other than keep the event handler's code smaller).
Please let me know if you think otherwise.
ItemCreated is fired on the postbacks, but ItemDataBound only during databinding.
ItemCreated is fired before the data bind actually happens. You would normally put code dealing with the appearance and non bound content of the grid in this event.
ItemDataBound is fired after the data bind. You would normally put code dealing with the data here.
ItemCreated is basically there for you to interact with UI things, and yes, you can do the exact same thing on the ItemDataBound event as well/create your UI changes there too... i prefer DataBound because then the data is already there, but i understand the purpose of ItemCreated
I have a WPF app with lots of textboxes and comboboxes that make up the UI. I have a 'Save' button that I want to turn red whenever any of those textboxes or comboboxes content changes. Is there a single event that I can handle so that I don't have to write
btnSave.Foreground = Brushes.Red
for the _TextChanged event for every textbox?
You could loop through all textboxes on the form by looping through the form's child Controls, and bind the event in one swoop accordingly.
//-- This is a hair on the pseudo side, ChangeSavebuttonToRedHandler is an event
//-- handler for your foreground change.. You can also use a lambda or whatever
//-- you'd like.
foreach(var loChild in this.Controls)
{
if(loChild is TextBox)
{
loChild.TextChanged += ChangeSaveButtonToRedHandler;
}
}
There are plenty ways to do such a thing. The best thing is to understand "Bubbling and Tunneling in WPF" and the usage of "Attached events". Here are some references:
This link has all you need.
http://msdn.microsoft.com/en-us/library/ms742806.aspx
http://www.wpfmentor.com/2008/11/understand-bubbling-and-tunnelling-in-5.html
Cheers
Use Blend to create a behavior. See: Adding Visibility Behaviors Using Blend to A DataGrid for WPF or Silverlight
I have a Silverlight datagrid that will change its data source dynamically at runtime, and the datagrid has a SelectionChanged event handler. But I don't want the SelectionChanged event handler to be fired every time the data source is changed. Is there a easy way to prevent this happening?
Thanks,
Wei
You can certainly unload (-=) the event handler and then load it back (+=) after you change the datasource. That should work fine. I would like to offer a suggestion, however. Instead of wiring up the SelectionChanged, does the Silverlight DataGrid have a SelectedItem property that you can bind to instead? If so, then you can bind that to a property in a class and listen for PropertyChanged on that property. Then you can lose the event handler entirely. That sets you up better for unit testing and is more in line with an MVVM philosophy.
I am having a DataGrid in one usercontrol which is getting filled with some data when I press some button(ouside it). This Datagrid is filled by one linkbutton also. When I click this LinkButton then OnItemCommand or SelectedIndexChanged should fire, but both the events are not firng. While the control's PageLoad event is firing.
Please let me know where I am doing the mistake.
Thanks
Is your control added dynamically, using something like Page.LoadControl()? If so, events won't fire unless the control is dynamically added for each request. That's the only way the control tree can be properly built again. I usually do this in Init().
https://web.archive.org/web/20211029043701/https://www.4guysfromrolla.com/articles/042402-1.aspx
For those that see this post, looking for an answer. Most likely, you're rebinding the data to the datagrid on every call. Use a conditional and check !this.IsPostBack.