Centre for Software Practice

Australia Medicare digital signatures using java and C#

David.Glance — Sat, 07 Mar 2009 13:47:00 GMT

So, the problem is how to sign a message using a personal certificate on Australia's Medicare iKey in a browser and being able to verify the signature in a web app. Well, it is more complicated than that but this was the basic problem to start with.

The signing part was relatively simple PKCS#11 using an applet example from Svetlin Nakov (http://www.nakov.com) - the iKey is a SafeNet one (Medicare use a smart card, the 2032, 3000 and 1000 (?) iKey) and comes with a PKCS#11 driver (dkck20.dll).

Note: I did find that the SHA1withRSA didn't work and I used MD5withRSA instead.

The issue was how to verify the signature in C#. I had the X509 public key from the iKey (or you can get it from the Healthcare Public Directory). Searching for how to initialise the RSA Cryptographic Provider from the X509 certificate took me forever until I hit the magic sequence of terms and it turned out to be surprisingly simple. In .Net 35 there is a class X509Certificate2 which can be initialised from the path name for the public key.

A property of the class, PublicKey.Key gives you an initialised RSACryptoServiceProvider which can then be used to verify the data (specifying MD5 as the hashing algorithm).

Disabling backspace in forms with Javascript

David.Glance — Thu, 01 Jan 2009 08:02:00 GMT

A constant usability issue has been users losing their data entry on forms by inadvertantly pressing the backspace button when the focus is not in a text box or other appropriate control. As very few users realise that backspace has another function in IE to go back a page, this then gets blamed on the web application as a bug. Of the solutions that are out there, the best I found was one posted here which is reproduced below. We use master pages and so it is just put in the master page.

I have seen some posts from over-zealous accessibility people claiming this is a bad thing - changing default browser behaviour. Since most people believe this default behaviour to be fundamentally broken in the case of web applications, I don't think this is a valid critiscism.

Here is the BLOCKED SCRIPT

Failed to Enable Constraints error in DataTables

David.Glance — Mon, 19 Nov 2007 04:13:00 GMT

This is an error I run into frequently and is frustrating because of course their is no indication of what constraint is being violated. So now I run through the three most frequent problems that will cause this:

Having a primary key specified on the DataTable where a query can potentially return duplicates. Sometimes duplicates are unavoidable and so removing the not helpful primary key will sort this one out.
Finding the columns that have been set to not allow nulls - again, this is sometimes unavoidable and so going through all of the columns and allowing nulls will fix this.
Exceeding the size of a column. This happens if you have created the DataTable and then for some reason alter the column size in the actual database table. The DataTable will not automatically update even if you alter the main query.

Occassionally I have found that nothing you do will get rid of the problem other than creating the DataTable and queries in a new DataSet (a tedious exercise).

Using multiple MasterPageFiles in an application

David.Glance — Mon, 19 Nov 2007 04:07:00 GMT

We have an application that we have 2 skins for reflecting the 2 customers of the application. When I went to using skins, I defeined the MasterPageFile in the web.config file rather than switching it programmatically in each page. Unfortunately, this meant that every time I wanted to view a page in Visual Studio 2005, I had to put the MasterPageFile statement back in the page - an extremely tedious problem. Since then, I have discovered that it is relatively easy to set the MasterPageFile in the Page_PreInit method which retains the statement in the aspx file making viewing in the designer still possible. I think this problem is sort of fixed in VS 2008 but switching it programmatically means one less thing that needs to be changed in the config file.

Security decisions – why are they so hard?

David.Glance — Sat, 28 Jul 2007 11:06:32 GMT

We are currently writing an internet-based application for use by doctors and health providers to exchange information. Because of this, security and privacy is obviously a concern (although if the laws around this in Australia were the only guide you may be forgiven for not thinking that!). This has lead to me looking at a number of different possible approaches to keeping the data sent between the users secure and private. The trade of course is quite a few of the other 'ilities like usability, flexibility, mobility, performability (I've always liked that one). Here were the choices with the pros and cons:

VPN vs SSL: the option of running everything over a VPN was ruled out because we wanted to include a large range of people in a large range of locations – VPNs just don't work in this setting.
Client certificates: remember the NBT (next big thing) – PKI? Good because we could have another level of identification – bad because of the overhead of managing certificates, people forgetting their passwords, management of installation or use of the certificates.
Encryption of data: Generally a good thing because even though the systems administrators could theoretically get access to the keys to un-encrypt, that is a step further than just casually seeing in–the-clear text of messages or data.
1. Public key via client certificates: good because the information is encrypted with the recipient's key – would be even better if this was done on the client – the difficulty is that the only real way of doing this is to use Active X which only works on IE (bad since we support Firefox as well). Bad because of (2) and browser dependencies. If it is done on the server, there is no advantage over symmetric encryption and the overheads are greater.
2. Symmetric encryption using a private key: good mostly – another level of protection – the main issue being where to store the key but that can be put on a smartcard or other off-box device.

In reality, the decision tree for using a particular variant for security is complicated and the path depends on context. This is probably why it is so difficult to come up with specific recommendations on what is necessary when it comes to security of medical records. The bottom line is that reasonable steps should be made to protect privacy and security of patient information but the advantages to patients of systems that facilitate accurate and timely sharing of information far outweigh the risks of breaches providing a base level of security including SSL, usernames and passwords and content encryption, is applied.

Good Error Reporting for ASP.Net Websites with MS-AJAX

TimHenstridge — Fri, 20 Jul 2007 09:37:00 GMT

A requirement in many ASP.Net web applications out there is that you the developer know when your website breaks, the usual way was to use the Application_Error event and then send your self an email or write to a log file. With the event of AJAX itergration into ASP.Net v2.0 the Application_Error event does not run when the request was an Asyncronous PostBack, fear not this is a fixable problem. This article is will cover my personal opinion on a good practice method of error sending. Firstly i will breifly go over the method to run the Application_Error event.

First Step go to the root of the website and add a new item, add the Global Application Class File leave the file name alone then click Add. you should now have a file Called Global.asax in the root of your website. you can make the Global.asax use a code behind file, which i would recomend. The code for error handling looks something like this:

Global.asax:

<%@ Application Inherits="CSP.Global" Language="C#" %>

App_Code/Global.asax.cs

using System; using System.Data; using System.Configuration; using System.Web; using System.Web.Security; using System.Web.UI; using System.Web.UI.WebControls; using System.Web.UI.WebControls.WebParts; using System.Web.UI.HtmlControls; using System.Net.Mail; namespace CSP { /// <summary> /// Summary description for Global /// </summary> public class Global : System.Web.HttpApplication { void Application_Error(object sender, EventArgs e) { // Code that runs when an unhandled error occurs ExceptionHandling.SendException(Server.GetLastError(), HttpContext.Current); }

} }

This Code runs a function that sends an error message email to the developers in charge of the application, where the first argument is of type Exception and the second of type HttpContext. The HttpContext.Current object can give us information about the request that caused the error, the session state when it happened, the user who caused the error (via Session state, cookie or IP address, etc) and more.

On to AJAX exception handling. To my surprise the when an error occured during an AJAX postback the above code never got run so i had to track down what the AJAX alternative was. It was quite simple to find it turned out, the error event seems to be handled by the ScriptManger Control which oddly enough has a OnAsyncPostBackError Event. The point of this post was not my "grand" discovery but rather the best practice method, so back to that. The best way to handle this event was to make sure it was centrally handled once a site was setup and didn't need to be worried about on any subsequent new pages therefore it was perfect to put this into the Master Page.

In the master page put a scriptmanager in the document body inside the server side form tags like so:

        <ajax:ScriptManager ID="ScriptManagerMain" runat="server" EnablePartialRendering="true"
            OnAsyncPostBackError="ScriptManagerMain_AsyncPostBackError">
        </ajax:ScriptManager>

The code to run the error should look something like this:

    protected void ScriptManagerMain_AsyncPostBackError(object sender, AsyncPostBackErrorEventArgs e)
    {
        CSP.ExceptionHandling.SendException(e.Exception, HttpContext.Current);
    }

Note the event arguments for this event are custom and you can get the Exception Error from them.

If your website has a combination of these 2 error catching methods you can rest assured that your application is working smoothly whilst running AJAX and that all errors are being reported.

10 reasons why programming takes so long

David.Glance — Sun, 08 Jul 2007 15:30:00 GMT

[1] The context switch: you are constantly switching between tasks (especially if programming is only one of the jobs you do). Each time you come back to your programming task, you have to remember what you were doing, how you were doing it and what you actually intended to do at the end of it.

[2] The library/control/feature you are trying to use doesn't work as advertised: You then have to spend time trawling blogs, forums, and yes, even documentation, to try and find out what magic word you forgot to incant!

[3] You have forgotten how you did it before: the thing design patterns were supposed to fix (ha!) but each time you implement that particular trick feature, you have forgotten how you did and worse still, where you did it last so that you can copy it.

[4] You are coding with someone else on the same project: so why did they set up that table in that way???

[5] Procrastination: each time you do [1],[2], [3] (and possibly each of the others) you get side-tracked on the web reading the news or finding out how to do some unrelated feature.

[6] To do the feature you want to add, you have to change the way everything else works: yes, I know, this was what design (and yes, don't make me laugh, UML) was supposed to fix - but as they say, you don't know until you find out.

[7] Ajax: everything has to work like gmail.

[8] Visual Studio/Windows: when it decides it has had enough and simply stops working or forces your computer to arrive at the same conclusion.

[9] Boredom: you have had enough of this particular project and wished you were back doing open source where there were no deadlines and no users complaining.

[10] The rest of life: meetings, writing reports, and yes, a little r & r.

Delivering on IT - the abstraction of simplicity

David.Glance — Wed, 06 Jun 2007 15:17:00 GMT

I was wondering why IT was so hard to do well. Or at least, why so many organisations run into so many problems when dealing with their computing needs. The main thing that seems to paralyze everyone is making a decision. And the reason this is so hard? Like many things, it is because people can't abstract a problem and model it based on the fundamental properties of that problem. Instead, they over-complicate the task by looking only at the individual interconnected parts and then add unrealistic pre-conditions for good measure. This is why the principle of "deliver early and often" works so well. You can start off with a simplified version of the software and through early use and feedback, people get a much better idea of what it is they want, concentrating on the important elements - usually the abstracted core of the system. It also helps if this is also driven by the pragmatism of either small budgets or tight deadlines.

KISS (keep it simple, stupid), it seems, is a hard lesson to learn, one that has to be reinforced on a regular basis. Achieving simplicity is, as I have said, a product of being able to abstract effectively and then being able to implement a solution which is internally and externally consistent.

the startup lifecycle

David.Glance — Wed, 30 May 2007 14:30:00 GMT

You decide to start a company. You may even have a business plan, or you have taken the off-the-shelf approach of starting off as a service company with the hope of providing a product which is eventually going to sell in sufficient quantities that it will pay for further development, expansion etc. In the meantime, you are answering the phone, doing the sales, doing the hiring/firing, consultancy and even development. How long does this last? Usually as long as you are prepared to forgo having much of a life outside of it all. The chances of it working out? Not very high. But at least you tried, developed some software and kept some people employed for a while. That can't be a bad thing? And you never know...

AJAX in ASP.NET 2.0 - Introduction To The Basics

adam.n — Tue, 17 Apr 2007 02:59:00 GMT

This is a copy of the post on my blog Noiz Waves.

AJAX has become quite the buzzword lately when it comes to Web 2.0. Luckily, AJAX is really easy to integrate into new and existing ASP.NET application; it's just a matter of adding some simple controls here and there. The best thing about AJAX in ASP.NET is that no complex coding is required; all the postbacks and Javascript is abstracted away.

In this article I want to provide a quick introduction to AJAX in ASP.NET, highlighting core ideas and useful hints, aimed for existing developers who want to dabble with AJAX. I'm going to start with installing ASP.NET AJAX and configuring Visual Studio 2005 (which takes no time at all). Then its onto a description of 3 of the main controls that utilise AJAX; the ScriptManager, UpdatePanel and Timer. Finally, I will create a small project that combines these controls to perform a simple task.

Installing ASP.NET AJAX

Firstly, you need to have Visual Studio 2005 and .NET 2.0 installed on your machine. Once you have done this, you need to download the ASP.NET AJAX Extensions 1.0 (version correct at time of writing). The download is only a couple of megabytes and provides the essentials for AJAX'ing your websites. Whilst here, you can also download the ASP.NET AJAX Control Toolkit. It provides a large number of AJAX'ed controls which are ready to use.

Once the extensions have been installed, all that needs doing is adding the AJAX extensions to the Visual Studio toolbox. I added the controls to a new tab called 'AJAX Extensions' by right-clicking on the tab selecting Choose Items and browsing to "C:\Program Files\Microsoft ASP.NET\ASP.NET 2.0 AJAX Extensions\v1.0.61025\System.Web.Extensions.dll" then clicking OK. If all goes well, your toolbox will look like this:

That's it! AJAX has been installed, and its ready to be used. If you want the AJAX Control Toolkit controls in your toolbox, the procedure is similar, but you browse to "C:\Program Files\Microsoft ASP.NET\Ajax Control Toolkit\AjaxControlToolkit.dll". Now, onto the controls...

The ScriptManager

In a nutshell, the ScriptManager is the control that handles most of the behind the scenes Javascript side of AJAX. There must be a ScriptManager on any page that uses AJAX. The easiest way to achieve this is to put one at the top of the master page. As far as properties go, EnablePartialRendering is the single most important one to be familiar with. In a nutshell, it enables or disables asynchronous postbacks. Disabling partial rendering forces all postbacks to be full postbacks. This is extremely handy when debugging some errors, as the error provided with partial rendering is a small javascript popup.

The UpdatePanel

The UpdatePanel is the easiest way to use AJAX to improve the responsiveness of a web application using AJAX. When an event occurs that is deemed to be a trigger for the panel, the server processes the request and responds with the updated contents of the UpdatePanel INSTEAD of the contents of the entire page. What this means is that user interactions affecting a small area of the page will only cause that small area to refresh. This results in a sizable saving of bandwidth, and a noticeable increase in response time.

UpdatePanels have a few important parameters that can require tweaking. ChildrenAsTriggers causes the panel to be refreshed when ever a child control fires an event. In some situations that is undesirable, as unnecessary asynchronous postbacks will occur. Triggers is a collection of control + events pairs on the page that will cause the update panel to refresh. This is my preferred way to specify when the contents of the panel are refreshed. UpdateMode specifies whether the update panel will refresh its contents on any postback or only those that trigger the panel. Again, I set this to 'Conditional' as it gives me finer control over when the panel is refreshed.

The Timer

This control is one that i had no use for during the first few months of developing, but after tinkering with the Timer it is extremely useful in some situations. A Timer fires a Tick event at regular intervals, and these ticks can be used as triggers for UpdatePanels. In other words, asynchronous postbacks can occur without any interaction from the user at all. This would come in handy for regularly saving the contents of a textbox or loading live stock prices for example. Timer has a couple of simple but useful properties, and these are Interval (the delay in milliseconds between tick events being fired) and Enabled (should the timer fire tick events or not).

It is possible to get tricky and put a Timer inside an UpdatePanel, and change the Timer's properties at run time. By setting the Interval to a very small number, and then immediately disabling the timer in the tick event handler, only one tick event will occur. This is an effective way of running a section of code only when the page has finished loading in the client's browser.

Sample ASP.NET AJAX Website Project

The sample project I've included with this article uses all three of the described AJAX controls. It contains a ScriptManager at the top, an UpdatePanel which contains some labels whose contents will be changed and refreshed asynchonously, and a Timer to trigger the change in label text and cause the actual asynchronous postback.

There is only 2 line of actual C# code in this simple project, and they set the label text to a random integer. Other than that, no additional coding was required to implement an AJAX'ed website. Pretty good eh'?

From the use of 3 basic controls, anyone can AJAX up their projects, making them both better to use and more efficient to serve. There are a couple of other controls included in the ASP.NET AJAX Extensions that I haven't touched on here; they are the ScriptManagerProxy and UpdatProgress. I would strongly suggest that everyone muck around with the UpdateProgress control. From a usability point of view, it is essential to know when the page is performing behind the scenes, not just for the users of the site, but also the developers and debuggers.

Attachments: SampleAJAXWebsite.zip

Research-based Practice

David.Glance — Wed, 14 Mar 2007 03:16:00 GMT

Cross posted from myResearchSpace

I have recently been looking at issues around best practice in web design. Best practice is often encapsulated as the perceived wisdom of professionals which has become enshrined in the collective mythology of the profession. An example of this in web design is that "users will give up on a website if they have to click more than 3 times"; a hypothesis with no experimental basis and with at least anecdotal research evidence (http://www.uie.com/articles/three_click_rule/) suggesting that it is false (there is little correlation between the number of times a user clicks and a user's successful accomplishment of a task).

With a growing sense of frustration at not being able to establish the relative credibility of any of the advice that was been given on best practice in web design, I came across a book published by the US Department of Health and Human Services called Research-Based Web Design & Usabilty Guidelines which uses research findings as the basis for web design guidelines. Apart from being beautifully presented and freely accessible online, it is the methodology used to present the guidelines which is truly impressive. Each guideline within the book is given 2 scores. The first is one for 'Relative Importance' rated by a panel of 16 reviewers, half of which were usability specialists and half web designers. The second score is for 'Strength of Evidence' for each guideline, again rated by a panel of researchers, authors and designers on the basis of a 5 point metric.

I wonder if there are lessons to be learned from this in the application of presenting research in a thesis?

Anatomy of a Good Website

David.Glance — Wed, 28 Feb 2007 04:26:00 GMT

The University of Western Australia's website http://www.uwa.edu.au is constantly complained about. In the last user survey, 43% of staff expressed some dissatisfaction with the site. But the site does have lots of good parts to it and has been improving over the past few years as more people become aware of the importance of their web presence. And when compared to other university websites, is it really that different?

So what is it about the site that doesn't work for its users? Were the issues simply a reflection of a problem at a given point in time that has now been addressed as there are improvements of parts of the website occurring constantly? Probably not. The problems with the UWA website are systemic even though there are numbers of exemplars of good design, content, architecture and usefulness.

University websites exemplify a type of website that supports multiple "personas" or "role types" in its users. 15 year old school kids will rub shoulders with undergraduates and professors (both UWA and non-UWA) all utilising the website for different purposes. The most common way that websites have dealt with this is either to offer different navigation paths through the same content with or without superficial text around the links giving "user-appropriate" guidance. But it ends up being the same content that they end up with and that may, or may not, be appropriate.

Looking at the problems of the UWA website and abstracting those to guiding principles for good website design, some general characteristics of good website design has emerged. Although these have resulted in a review of a University website, the principles are general. Applied to a great site like the BBC, all of the principles apply.

A good website is one that is...

[1] COHERENT

Different areas of a website serving the same function to look function in the same way i.e. if you visit the School of Plant Biology's website, it should be structurally similar to the School of Humanities' website. Staff lists should be in the same place with the same details.

[2] CURRENT

There is no point in putting information on the web if it is out-of-date or inaccurate. Maintaining the web is a daily activity.

[3] USEFUL

The content serves some purpose. It is useful, consistent, discoverable, well written, customised to the reader's persona and meet some need even if this is simply entertainment.

[4] PERSONALISED

The experience of the website is tailored to the individual visiting it. The BBC website for example configures the news based on whether you want an International, UK or other perspective. External visitors to the site shouldn't have to navigate or see pages or links that they have no interest or access to.

[5] DATA-DRIVEN

Wherever possible, content on the web should be driven out of structured data stored in databases rather than "hard-coded" into web pages. Examples of data-driven web content would be staff lists, research profiles (publications, grants, and research interests), unit, and course information.

[6] INTERACTIVE

People interact with a website – the model should be push as well as pull. The website should allow comments, blogs, feeds.

[7] ATTRACTIVE

The design should be coherent, attractive, customised, accessible, and follow best-practice design guidelines. Current design stresses simplicity with a content focus.

[8] RESPONSIVE

The website should be responsive and make allowance for users with different data access speeds (this can be built into the personalised aspects of the site).

IE only Stylesheets in ASP websites

TimHenstridge — Mon, 19 Feb 2007 02:22:00 GMT

a very simple feature i implemented today was to make an IE only style sheet for my application i'm writing it only took 2 lines to make it work. Firstly put the following line in your asp page (best place would be a master page):

this should go after any other style sheets so that it's content takes precedence over the other style sheets.

Secondly put the following line of code (it is in C#) in your page load:

lnkIEStyle.Visible = Request.UserAgent.Contains("MSIE");

this works very well and you can easily make your website look the same across numerous browsers and the method could be used for different browser detection such as if the user agent string contains "gecko" you could single out mozilla based browsers.

Writing Woes

Teresa — Tue, 13 Feb 2007 02:03:00 GMT

So you've had a beautiful new site created for you by your designer, and all it needs is the content from you to go live. Only problem is it's hard finding time to write it, and soon you realise weeks, even months have gone by and your site is still not live due to lack of content.

Sound familiar? Don't worry, you're not alone - as designers we've seen (and gently prompted, repeatedly) plenty of clients who have this exact problem. Writing about yourself or your group can be a daunting task and one that is easy to keep putting off until later. Here's a few tips for biting the bullet and getting it done.

Put some time aside

The first thing you need to do is make some time. This can be hard to do on top of everything else, but is essential - you've obviously already decided that your website is worth some money, time and effort, and putting some time aside to write to bring your new website to completion will be worth it in the long run.

Take a look again at your beautiful new design

... that your designer has finished, ready to go live as soon as everything else is ready. Doesn't it deserve to be seen? Don't you want to show it to the world? Let it inspire you to do it justice with some quality content! The sooner your part in the process is finished, the sooner people will be able to see it, and you can be sure that a newly design site will have a better impact than an old one, a 'coming soon' page or nothing at all.

Look through the suggested structure

If your designer has given you some suggestions about the structure of your site based on information you've given them, give it another look through and see if inspiration strikes.

Decide on the essentials

It helps to start by making a list of what really needs to go up there, especially if your website is a large one. Once you have a rough outline of what you're planning to write it's much easier to begin to flesh it out while keeping in mind the big picture.

Look at what other people have done

While it's never okay to plagarise someone else's work, taking a look at what your competitors have done can give you some idea of what other people in your industry are doing. Make sure not to copy, but take note of the style, the tone, the kind of things that they mention. Decide what works and what doesn't, and apply those ideas to your own content in your own way.

Write for the peoples

Some sources might tell you to overload your page's content with commonly searched keywords to ensure a higher search engine ranking. While making sure that you include important things like your name, purpose and location where appropriate can be a good idea, make sure to not lose sight of who you really want to engage with your information - human readers. If your content doesn't make sense or seems repetitive and stilted to a human reader, it doesn't matter how well it does on Google - it won't fulfil it's purpose.

So get writing and get your site out there!

Enhanced Calendar with Next/Previous Year Buttons

adam.n — Sun, 11 Feb 2007 00:14:00 GMT

By default, Visual Studio 2005 includes a useful range of components for building ASP.NET web applications. Unfortunately these components are usually very basic and have restricted usability, but with a small amount of customisation become highly usable.

Enter the world of User Controls. A User Control uses regular ASP.NET components as building blocks to construct a more complex control that can be used in the same way as a regular component. User Controls can be assigned their own methods, properties, events, and be drag-and-dropped into ASP pages.

In this post we will create a User Control that enhances the functionality of the basic Calendar control. We are going to adding buttons that go back and forward 1 year. Clearly when for browsing to dates many years ago or in the future, a simple next/previous month button is not sufficient. To select a date 5 years ago, 5 * 12 = 60 clicks would be required. With the successful implimentation of next and previous year buttons, this could be reduced to 5 clicks. A big win for usability. However, the challange here is where to locate our extra buttons within the user control to achieve a seamless layout. Overriding the Render(HtmlTextWriter) method will allow us to get the best result.

Also, we will add a nullable SelectedDate property. The SelectedDate property of the standard Calendar must be assigned a value, which means it is difficult to have no selected date. As our SelectedDate can take on a null value (representing no selected date), a simple null check can be used to determine if a date has been selected by the user. As a result of this, form validation just became a whole lot simplier.

Both the .ascx and .ascx.cs sample code files have been included with this post. Feel free to use these as a basis for adding other enhancements to the standard calendar, or even to start development of your own User Controls.

First we need to create a new User Control for our enhanced calendar (I suggest creating a new folder called CustomControls and putting it in here). So right click on the destination of the control, select 'Add New Item', choose a Web User Control, and name it EnhancedCalendar.

Now we are presented with a blank canvas that is our User Control. From the toolbox, drag over one Calendar control and two link button controls, and give these controls useful names (I have used calDate for the Calendar, btnPrevYear and btnNextYear for the buttons). Change the text for btnPrevYear to "<<" and btnNextYear to ">>" and set both buttons to invisible (as we don't want them to render here). To match the existing interface of the calendar, I gave the buttons a tooltip which describes their function. To handle the selection of a date on calDate, give calDate a SelectionChanged event handler. Finally, give each of the buttons a Click event handler.

That is all we need to do from a design point of view, now we move on to the code behind the scenes. Firstly create a property called SelectedDate, which will allow us to set and get the date represented by our enhanced calendar. I have chosen SelectedDate to be of type DateTime? (? makes it nullable) as the standard DateTime type is stored internally as a primative and thus is not nullable. For the button click event handlers, add or subtract one year from calDate.VisibleDate. Inside the calDate_SelectionChanged handler, we want to update our SelectedDate property with the latest value of calDate.SelectedDate. To be thorough, we should add a method to reset the date on our enhanced calendar, which I have called ResetDate().

Next we need to alter how our user control is rendered. The procedure we are going to use will follow this basic flow:

Render calDate to html and store in a string.
Find the previous month link in the html string, and render btnPrevYear before it.
Find the next month link in the html string, and render btnNextYear after it.
Write this string as the html for our user control.

Simple.

The very first thing we need is a way of getting the rendered html code for a control. In our situation we want the html code for calDate. For this we will write a method called RenderToString(Control), which will render a control to html (regardless of its visibility). In theory this method should belong in a utility class, but for this example I have included it in our enhanced calendar's code.

The next things we need are two Regular Expressions that we can use to identify the next and previous month buttons in the stanrdard calendar's html code. By examining the html code of the standard calendar, the previous month button can be isolated by looking for a hyperlink with enclosed text of <, and similarly the next month button by a hyperlink with enclosed text of >. Once the regular expressions have been written, some static Regex objects are constructed to handle the matching.

Now that we can identify the previous/next month links and render a control to html, we have all the tools required to insert our next/previous year buttons inside calDate. To perform the inserting we use a MatchEvaluator, which works by calling a target method when ever the Regex object finds a match. We will need to make the target method replace the next/previous month html with the next/previous month html concatenated with the rendered next/previous year button. Of course, two different methods are required; one for the next year and one for the previous year, as the order of the buttons is different. I have called these methods AppendPrevYear and AppendNextYear.

Finally, all that is left to do is perform these steps in the overrided Render(HtmlTextWriter) method. First render calDate to a string, then insert the previous year year button, then insert the next year button, and then write the final html to the writer. And there you have it, that is all the code required to make our enhanced calendar.

With these minor modifications, we now have a more usable (for both developer and end user) calendar control that can be used in the same way as the original. Additionally, it conforms to the same clean and uncluttered layout as the original calendar, which is a bonus. The addition of the next/previous year buttons make this control suitable (when combined with an ajax popup control extender for example) for use as a date selector input for a form. Also, the nullable SelectedDate means that validation of empty required date inputs can occur easily.

For those readers who want to take this example further, some possible avenues for future development include:

expanded the regular expressions to collect the style attribute of the next/previous month hyperlink, and this could also be applied to the next/previous year buttons. This removes the need to synchronise style at compile time, with it instead occuring at run time.
add a method to the control specifically designed for use with a custom required field validator.
add more properties that set style attributes of calDate, so style information is not stored in the custom control, and this allow the same control to be used across multiple application.