I've been digging thru the Page, TemplateControl and Control classes in reflector trying to figure out where AutoEventWireUp property is actually getting used. I've failed miserably.
My understanding of AutoEventWireUp is sketchy but I think it casues event handler methods to be automatically wired up to events?
So I thought I'd see some code where this is happening, but this isn't the case.
Where is AutoEventWireUp actually used under the hood? Can I see the code in reflector?
Thanks in advance!
I was going to write up an explanation but K. Scott Allen has a much better one.
My advice is to avoid AutoEventWireup and either override base "OnEvent" methods or explicitly wire up your own events as this will be faster, less magical, and easier to debug.
Related
I'm debugging some weird behavior in a ASP.NET webforms app. I've narrowed it down to something I find peculiar: A control which implements IPostBackDataHandler has it's RaisePostDataChangedEvent called even if it's a callback from another control. I've reproduced this in a dummy test page.
Information on how it SHOULD be is scarce. I've found only one page which seems to imply that it's only called on postbacks, and not on callbacks.
Is this how it should be? Has it always been so?
After some more digging around in ASP.NET source code I think I can say with certainty - that's how it's always been.
Awesome. I shudder to think how many places in the application have subtle flaws because of this. It's a good thing we're on the path of replacing it all with MVC.
I do have a small doubt regarding ASP.NET Page Life Cycle events. When gone through the coding of an application I came to see both overriding of OnInit() method and also Page_Init event. I thought both the approaches serves the same purpose and i saw mostly the implementation of overridden OnInt() only but not both. Most of the articles in the web explains about the better approach in these two and I know that generally overriding the OnLoad/OnInit methods is faster and also if you override OnInit and fail to call base.OnInit then the Init event won't be fired but no one explained what happens if we implement both. What does this situation means. Can anyone please help me regarding this. Thanks in Advance.
Page_Init is just a shortcut for calling the OnInit override they both do the same thing. Page_Init requires the AutoEventWireup property to be set to true because it tells the compiler to look at your code for certain methods like Page_Init or Page_Load and fire them, this video from Fritz Onion on pluralsight does a really good job of explaining it: ASP.Net 3.5 Pluralsight Course
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.
I've found many posts where people try to work around the problem of SelectedIndexChanged not working when EnableViewState='false'.
Im a little confused why control state doesnt kick in and allow it to work, but thats bonus points if anyone can explain that too.
Some of the 'hacks' are pretty 'hacky'. Like setting a value on the viewstate of the page itself corresponding to the dropdown value and then comparing that value with the one that is received durin the postback.
I'm lookin for the best most elegant solution (if there is a good one).
I dont know if this would be a clever derived control or something cleverer, but I want to make sure the solution is generic enough to be 'trustable' and not just a hack that only works for the specific page in question (which is common for such hacks!).
If you really want to know why and how this works, I'd suggest the following article:
TRULY Understanding ViewState
It's not an easy read, but does cover all the problems that people commonly encounter with viewstate. And it covers why everything works if you populate in Page_Init as opposed to Page_Load.
Bind the list before adding it to the control collection (not after as above commenter says).
-author of said article :)
Try loading your data into the DropDownList at an earlier point. Ie. in InitComplete. I haven't tested it, but I think that should do the trick.
EDIT:
It didn't do the trick. I've tested it, and it doesn't work satisfactory. As Ken Browning noted in another answer on this question, the SelectedIndexChanged event is ALWAYS fired if the SelectedIndex is any other than its initial value.
Why isn't SelectedIndex stored in ControlState instead of in ViewState. Can we trick ViewState to only keep track of SelectedIndex, while not storing the Items collection?
I know it happens sometime before Load, but during what event exactly?
It's loaded into memory between init and load. See this article for a full break down of the page lifecycle.
I once got into this question too and got my answer from TRULY understanding Viewstate article, which I highly recommend.
After reading it I designed a graphic that helped me to understand better what was happening on between each stage and when and how ViewState was doing its job.
I'd like to share this graphic with other people that (like myself) need to see how stuff work in a more visual way. Hope it helps! :)
Click on the image to view at full width.
That is to say, viewstate is loaded between the OnInit() and OnLoad() events of the page.
My favorite article on dealing with viewstate, which answers every question I have every time: http://weblogs.asp.net/infinitiesloop/archive/2006/08/03/Truly-Understanding-Viewstate.aspx
You can see from the page life cycle as explained on MSDN
That the view state is loaded during the Load phase of the page lifecycle, i.e. the LoadViewState method of the "Page methods" and the LoadViewState method of the Control methods, above.
The Viewstate is actually loaded in the OnPreLoad event of the page,Just after the Page_InitComplete.
The viewstate is actually loaded between initComplete and Preload events.Check this for details http://msdn.microsoft.com/en-us/library/ms178472.aspx