I Am Not A Control Developer

I’ve created a number of user and server controls for my C# web applications.  Recently, however, I’ve found myself working in Silverlight and, if you are of the same opinion as me, you believe Silverlight was missing a few core controls.  Specifically, Silverlight was missing a TextBox with password masking and a CombBox until Monday’s Silverlight 2 Release Announcement. Prior to the release candidate becoming available a couple of weeks ago, you had 3 options if you needed one of these controls in your Silverlight application; you could purchase a commercial control, find an open source implementation or hack your own control together. 

I really didn’t know enough to put together my own solution so I downloaded a lot of code and clicked through numerous demos in an attempt to find something that already worked.  Luckily, I found sample code available for a PasswordTextbox which needed little fine tuning on Chris Pietshcmann’s blog.  Though I literally searched for hours and sampled many implementations, I didn’t find a satisfactory commercial or open source ComboBox control.  Ultimately, I settled on a AutoComplete TextBox / ComboBox hybrid which I pieced together with the help of a couple of posts made by Ary Borenszweig.  I was really encouraged but how much I learned through the process and even though my controls will have an exceptionally short life expectancy, I am pleased with how they turned out. 

I found it interesting to discover that only a few of the controls I researched/tested really, really worked.  Yes, primary functionality was in place the majority of the time, but shortcomings became obvious once I dropped the controls into a “real” application.  So, here are a few thoughts I collected for those (including myself) interested in pursuing control development: 

Code for both the mouse and the keyboard user.  Think big strokes like navigation, data entry and value selection.  Whatever action is available via the mouse should be available via the keyboard and vice versa.  For example, don’t make users click on the ComboBox in order to have the dropdown list appear.  Instead, get familiar with standard ComboBox operations by playing with ComboBoxes found in other frameworks.  Comboboxes have been around for a long time.  Unless you mimic de facto standard functionality, your control will be full of holes. 

Don’t forget to test the edge cases.  Sure. Most of the time a user is going to simply enter a password from left to right, one character at a time, but what if the user copy and pastes in an entire password or, better yet, what if a password is entered and then the user selects and replaces the middle three characters without ever touching the mouse.  Here’s a good one: what happens if the PasswordTextBox mask, perhaps an asterisks, is entered as part of the password string?  Will your control break?  I am pretty sure mine will… Edge cases are tricky and endless.  The main point here is test, test, test anything a user might do.

Test controls in a real world scenario. There’s a lot you can immediately learn about a control once you start using it with purpose.  Is your control easily populated?  Can you easily extract the value?  Can the control be validated?  If necessary, how does the invalid state present itself?   When it comes to look and feel, can your control use existing themes/styles?  Finally, does your control play nicely with others?  Can you tab in and out of your control smoothly?  Can you programmatically give focus to your control?  What happens when your control loses focus?  Until you drop your control into an application, some of those questions may not be considered or answerable.

Again, I am not a control developer, but I will keep the thoughts above in mind the next time I create a control.  Happy coding.