Now this approach will work – actually, I mistyped the title. That should have been visited this year. What we have done here is we have hard coded a dependency on the actual text that happens to appear on the button in the user interface and that is always by practice. What could happen when this application goes through testing? Somebody might suggest that let us change the label on this button to be something a bit shorter or let us change it to be French or German. As soon as we change any of the text on this button controls, it is going to completely ruin the logic in our code.

So having a statement that explicitly depends on the text that happens to be on the button control is always a bad idea. So what do we do? Well luckily for us, there is a mechanism that can help us to track which button was clicked. That does not depend on its user interface. So for example, if I click the first button and have a look at these properties as well as having the text property which is the user interface text, there is also a property called command name. This is if you like the logical name for the command as suppose to the label that happens to appear on the user interface, this is more like a programmatic name that represents the button so I could choose a name such as this year command for that button. And then for the other button, I can choose a command name such as last year command. And then if I go back to my code behind, I can now modify the logic so that it checks not the text property but the command name property. That is much better.

There we are. So we are checking which button was clicked via the command name property rather than checking the text. So if I get this stage, we need to run the application and see that it works and that it compiles. One of those days, use of unsigned local variable year message, so this is ASP.net. To be more precise, it is the C# compiler. And what it is complaining about here is I have a local variable called year message and although I set the value for it in this branch and I have set the value right in this branch, it is possible that both of these tests fail. In which case, this variable will be unassigned so I need to just give it a simple initialized value at the beginning. So let us just assign a value string.empty. That is an empty string. Let us try to compile it again and see what happens. So let us type in a name. Colin is my father and Colin visited France actually this year on a skin trip. So let us say this year, Colin visited France and let us also put in my brothers name Nigel. And Nigel visited — I am not sure when Nigel visited Canada and Germany last year. There we are. So that is all working marvelous.

So let us close the window. We are pretty much finished with list example. I will just summarize what we have achieved in this example. Basically, we have had a good look at the page process. We have seen how asp.net initializes the controls that make up our webpage using a variety of mechanisms. First of all, it sets default values according to the mark up that we have in our webpage. And then also, it uses this state and the combination of initialization methods to enable us to perform subsequent initialization for our controls. Those have looked at how you can handle multiple events using the same event handler. And finally, we have seen how to handle some additional events on the page class. We have seen the importance of the pre render event for tighten up controls and we have seen the importance of the unload event for discarding objects, some data that we no longer need at the end of the webpage.

Okay, so that is the end of that example. So I am going to close Visual Studio.