Best practices question.
While I was writing some event handlers, I ran into an issue where I as looking at the incorrect event (GridViewRowEventArgs) when I should have been looking at something else.
Now to solve my problem, instead of referencing the very specific event I was looking at, I just used EventArgs, which seems to catch any possible event. So, finally to the question; is there an issue with using EventArgs instead of the specific event? is it better to use the specific one for debugging issues? What is everyone's opinion?
Thanks
If a control is compliant then their event arg classes will always inherit from the generic ASP-provided EventArgs, which is why your approach works. Ultimately, if you don't need the extra information provided by the control through their own custom event arguments class then obviously you can dispense with using it altogether.
However, from a best practice perspective, my feeling is that it would be better to use the correct handler signature provided by the control, since that makes it predictable to people who might be working on your code and can't read your mind, but do have access to the the particular control's documentation.
Related
What's the purpose of having behaviors in Xamarin.Forms? Isn't it possible to add new functionality to UI elements through event handlers? I am confused about when to use an event handler and when to use behaviors.
This is a very simple answer and is only intended to start your research. Undoubtedly a better answer will come along. I am still working through this and will keep an eye on it because I too would like an answer that is more thorough than mine.
With proper separation of your View and ViewModel, Events aren't really the way to go. Behaviors allow you to maintain a proper MVVM approach (for example, when calling a Command from an Entry's Completed event) by using an EventToCommandBehavior system.
Additionally, Behaviors allow you to create prepackaged, well, behaviors that can be applied to multiple controls' events without having to reuse code.
Sorry in advance for the long question.
Since I'm running into StackOverflow exceptions (ironically), which i know the cause of, i am really wondering whether i've got my concept, of how to implement FindControl right.
My idea was, that if you're implementing a custom child control collection, which should be accessible to FindControl, you'd have to implement FindControl and search through your list in addition to calling the base method.
So this is the situation now:
I wrote a Server Control, which has a templateproperty (which i'm adding on init). Let's call that "panel" for now (It's not the default asp one)
My structure is along the lines of this:
panel (1)
panel (2)
telerik:RadTabStrip
panel (3)
telerik:RadMultiPage
Now prior to my change finding controls worked ok, with the exception that if the radTabStrip would look for the multipage through its id it would start looking in 2, where it obviously can't find the other multipage, since it's not a direct child of 2.
My change was to go to the NamingContainer (leads to 3) and loop through the child controls and execute FindControl there. This initially worked to solve this issue.
However in a structure where there was 3 children and the desired control was the third this way of searching would result in dancing back and forth between the first and the second panel. So it's a sibling search which triggered the StackOverflowException, which makes sense.
Apparently however this raised the question for me if i'm not actually doing something terribly wrong there. Other controls seem to have no trouble looking through hierarchies of NamingContainers without any hassle.
Is there some ID name register (e.g. all controls within naming container register their contained id's and in findcontrol you'd just go to some look up class to find the control you want without any custom logic to navigate through controls and calling FindControl) I'm not aware of, or something alike?
I really hope you can help me with this one.
I have an idea how to solve my issue for this problem, but I'd love to know how to actually do this the way it's supposed to be done correctly.
Each Control has its own Controls collection, that is 'built in' - you do not need a 'naming register'.
You basically need a recursive function:
Write, for example, MyFindControl so that it accepts a Control-Collection as a parameter.
Have your function iterate through that collection, and if you find the control (by name?) you're looking for, return it.
And if the control you're currently checking is not the one you're looking for, let your function call itself again, giving that control's control collection as a parameter.
If the control that is being searched does not turn up, you can return Nothing or Null (depending on your language), or you can raise an error. The code using your custom FindControl implementation must handle that.
I'm looking for a way to intercept the ASP.NET processing pipeline in such a way to be able to register event handlers to all events on the Page class. The reason is, I need to maintain a session-bound instance of a component that needs to be notified of all important Page events, starting from OnPreInit.
There's an arbitrary number of Page descendants in the application, which are not under my control. Hence I cannot use an approach like using a single custom descendant, that would notify the session-bound component, as a base class for all pages in the web application.
I don't think creating a custom IHttpHandler or IHttpModule implementation would solve the problem. Also note I cannot create a custom HttpApplication descendant.
It isn't going to be an elegant process to do what you are looking at, especially if you need to handle multiple page events, but in theory it is fully possible from within the Global.asax to setup handlers that you need for each and every page.
The trick here is to add your code to the global.asax in the PreRequestHandlerExecute method, from here you can get access to the HttpApplication object, get access to the page from there, and then register your events. This process is necessary as a new page instance is created for every page that is processed.
Now, other options as you know are far more elegant, but this should get to where you need to be. One helpful tutorial I found although around Themeing shows you the whole process here.
EDIT:
After seeing your comment, yes, you can simply do what I'm stating above, in a custom HttpModule. The article I linked even shows you that process :)
Without knowing more about what you're trying to accomplish it really sounds like you do indeed want to create a http module or handler. You might want to take a look at this question
I've done some reading on SO, but didn't find the answer to my question.
As #Canavar points out in his answer there are 2 ways to subscribe to an event:
Declarative:
<asp:Button runat="server" ID="myButton" OnClick="myButton_Click" />
Code Behind:
myButton.Click += new EventHandler(myButton_Click);
I subscribe to events declaratively, but hardly ever use the "sender" and EventArgs in default event handlers. Most of the time I end up calling a method from the event handler.
Would it be better to subscribe to events using a delegate?
myButton.Click += delegate{DoStuff();};
Let me know if I'm over complicating things, and should stick to declarative event subscription, and calling my DoStuff() method from default event handler.
Your handler needs to match the event's specified params. If you use a delegate you will just be defining the same thing. Discarding the params seems like a waste since you might need them in the future for some reason. I can't think of any good reason to not want the parameters.
And an event handler is a delegate already :)
I personally use the declarative approach whenever possible. While neither the declarative nor imperative approach is really "better" than the other, both have their merits. For the most part, using the declarative approach means you have greater decoupling and more flexibility between page behavior and page content. If you, for whatever reason, need to change you're page content around, using the declarative approach gives you more leeway to do so without requiring a recompile.
That does not mean the imperative approach is useless. There are times when it is not possible to apply handlers declaratively. Namely dynamic scenarios. The imperative approach allows you to use code to create dynamic content and still wire up events. Use what fits the scenario best. There is no one proper approach, both have their niche.
My favorite:
myButton.Click += myButton_Click;
The EventHandler is not actually needed. Also, if you are C# 3.0, you can go lambda on it:
myButton.Click += (x,a)=>DoStuff(); // something like that.
But really, it isn't worth worrying about too much.
I am creating a completely custom (only inherits from WebControl) combobox/dropdownlist search control with autoComplete capabilities.
JQuery handles assigning the onhover and onclick events for list items (divs with strings in them) and handles the web service call for getting the list of items for the matching text.
The server handles the custom attributes and control rendering.
The issue is that I need to implement a property that is similar to SelectedValue so that when a user selects an item from the search results, the value can be used on the server for other processing. I have done days of research but have not found a clear, concise way of handling the post back data.
I did read a blog that mentioned implementing the IPostBackDataHandler interface, but the implementation of RaisePostDataChangeEvent() calls for calling a server method (like SelectedIndexChange) that I am not implementing at the moment.
public void RaisePostDataChangedEvent()
{
this.SelectedIndexChanged(EventArgs.Empty);
}
Now for the question: Does anyone have advice for handling this? Or am I better off simply inheriting from the dropdownlist control and overriding the existing functionality?
I feel like I'm missing a very small piece that will fit this all together.
Have you considered pulling down the source code from Microsoft's source server and taking a look at how they implemented DropDownList? This would allow you so see how they solved the binding and events part of the problem and give you a good idea what it does otherwise. This way you can decide if you want to inherit from it, or if you can just borrow some ideas for how they implemented IPostBackDataHandler.
Since I have no idea what specifically you are doing, I couldn't advise you if you should inherit from dropdown as it is, but based on my impressions of what you are doing I'd say you probably don't.
Also you might look at source from the AjaxControlToolkit as it has a similar component. Again, you can get ideas for how these specific things are handled and adapt them to your own needs.