I want to understand event cycles. I have a form with a grid and textboxes. It has a grid, bound to DataTable, and textboxes bound to same table too. I'm trying to debug something and need to know how to identify ALL events fired in the form to see what may solve an issue for me.
Anyhow, unless I explicitly subclass every class on my form, and override / attach to every event to my own event handlers, how can I get / listen to all events being fired during a certain action... Such as changing a "Selected" road in a DataGridView. It obviously updates its own "CurrentRow"... I need to know what / how to maybe FORCE a re-loading of SAME CurrentRow.
Reason: during a form level "Edit Mode", and I change the content in another "Textbox" control, and reject changes, I need it to simulate the current "Record" is reloaded to go back to its original values.
You could fire up a profiler and look at the method call tree.
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.
I have a customized Grid control that is inherited from Gridview that has search and pagination. Everything works great except this one little thing. Whenever I use the pager to go to the next page, then I use the search, the event that handles the search does not fire on the first click, it takes a second click to get it to fire. Any ideas?
The code for the control is here:
Grid.cs
Important Note
I am aware that it is frowned upon to post large blocks of code... But, the entire control's code is posted to give the whole picture of how it is built. The control itself is a bit on the complex side as it performs searching, sorting, and pagination all server-side; and this code is a completely custom control that just INHERITS the GridView.
I AM NOT looking for someone to write a fix for me, just an idea of why this one situation may be happening!
With that said, to break things down a little more with the code... The search form (text box and buttons) are created dynamically and added in the CreateChildControls method. The search form works perfectly when the Grid is initially loaded, but after using the pagination, the first click of the Search button does not fire the method assigned to the Search button's command event, but the second click does. It seems as though something in the postback is not recognizing the button's command event has been triggered...
A trace of the calls to the methods show:
1st Click - Everything from ViewState is loaded, no postback events are called.
2nd Click - Everything from ViewState is loaded, postback events called.
I'm looking for ideas on where to go from here, as I've been trying everything I can think of page life-cycle wise to see if I can get this functioning properly. The only thing that has worked is setting EnableEventValidation to false on the page that implements the Grid control, and performing the "initial" data bind on every "Page_Load" (not just "if !IsPostback"). But, for obvious reasons, that is not an acceptable solution.
Found the issue... Posting here for anyone who might make a similar mistake.
In CreateChildControls(), I was executing the base before adding the search form to the control. A simple switch around to calling the base after adding the search form, and getting rid of the condition "if (this.HasControls())" resolved it. From what I can see, calling the base after adding any child controls allows those child controls to have their events/handlers properly registered.
I've got a TreeList that's basically like a Photoshop layers palette. It's a hierarchical list with checkboxes to toggle visibility of a document's individual layers. This is done via the BeforeChecked event, which is raised right before the .Checked value toggles.
It works fine, except if you double-click it, at which point it all seems to go haywire.
If you double-click a checkbox once, it toggles the checked value twice (which is the intended behavior), but it doesn't toggle the visibility of the layer twice because it doesn't raise the BeforeChecked twice.
I figured I'd get around this by putting this in the MouseDoubleClick event:
TreeViewHitTestInfo hit = treeLayerPalette.HitTest(e.X, e.Y);
hit.Node.Checked = !(hit.Node.Checked);
This works for all double-clicks except for the first one. So it only raises the BeforeChecked event once (and not the MouseDoubleClick) at first, getting the checkbox out of sync with the visibility of the layer, and then all following double-clicks raise both the BeforeChecked and MouseDoubleClick events (which in turn raises the BeforeChecked event), maintaining that incorrect relationship.
Also, at one point, I put a MessageBox.Show() in the DoubleClick event. Awkwardly enough, it does not actually get shown on a double-click, but instead gets shown on a third click, no matter how much time has elapsed between the actual double-click and the third click. A third click performed 20 seconds after a double-click will raise the MouseDoubleClick event, but the actual double-click won't.
What's actually going on here, and how can I fix it?
this is a problem with Checkbox Enabled treeviews, however there are a few acceptable workrounds..
Firstly: MS know about the problem but refuse to fix it... : http://connect.microsoft.com/VisualStudio/feedback/details/775922/treeview-double-click-bug#details <-- The Bug report....
So there is no way but to workaround it.. simplest been to subclass the Treeview and forcibly disable the dblclick on the checkbox...
answer (on SOF) : c# treeview ignore double click only at checkbox
Hope this helps....
I have a lot of textboxes with the TextChanged event. There is also a master textbox at the top, which if I change it and press a "Change All" button, it changes the entire page of textboxes.
Now, the button exists almost entirely on the client side (just uses jquery to change the textboxes), but I want to know if it has been pressed BEFORE my program runs through the 100+ TextChanged events.
I tried adding a server function for it to set a boolean to true, hoping it would fire first, however, the TextChanged events fire first.
TL;DR I need to tell my program in which order to go through the events after a postback.
You really can't change the order of events in the ASP.NET page lifecycle...but you might still be able to accomplish what you're needing. Here's a suggestion...take it FWIW...
On the client side, you could add a Javascript event handler (or amend one that already exists) to populate a server-side form field with a magic value (doesn't really matter what). On the postback, inside the Page_Load (and/or in the TextChanged event handlers), check for the presence of the value when IsPostback = true. You might have to wire up (a bunch) of different handlers to make the same check, so this may be too cumbersome, but its at least the seed of an idea, perhaps.
Won't promise its very elegant, but it should at least get you closer to what you need.
Even if I associate the button with a class derived from ICommand, I am still left with figuring out how the button should trigger the CanExecute method and refresh its enabled state. I do know about the CanExecuteChanged event for which a button with an associated command registers, but see the following paragraph for why this is troublesome.
On a plain old dialog consisting of some 10-15 controls, it seems haphazard to have to process every change notification for every single one of those controls, triggering the CanExecuteChanged event on the button's command, causing the button's enabled state to be affected by the CanExecute method's return value. Even stating what needs to be done in the last sentence was quite cumbersome.
There must be a better way of coding a WPF dialog, so that the confirmation button (e.g., OK) is grayed out until all controls have valid information and is enabled at that point in time (i.e., when all controls are properly filled in). Sample code, ideas and pointers to articles would be immensely appreciated.
Thanks
I don't see anything haphazard here. Since your condition is "all controls have valid information", this can occur after any control is edited, and therefore you need to listen to change notifications from all controls.
On a plain old dialog consisting of some 10-15 controls, it seems
haphazard to have to process every change notification for every
single one of those controls,
I don't think so. Every Textbox, checkbox changed event is handled by the same handler, say SetState(), which calculates the overall state of the dialog. Every time a control is edited, the entire state is recalculated.
until all controls have valid information
Then that object would have a boolean property EnableOKButton, let's say, which is set according to the updated state. Then that property is bound to the button's Enabled property so it automagically changes - without dealing with extraneous events.