Korkboard has been updated to version 1.1.0.0 after a couple changes and fixes. If you have already installed Korkboard, it will check for the update next time you run it. It will install the update the next (next) time it is run. If you do not have Korkboard, you can download it for free!

Here is a full list of the changes made since 1.0.0.4:

• Added drag and drop sorting.
• Added item pinning (will stay at the top).
• Added settings for turning off (and on) certain data formats.
• Added a “Clear Korkboard” button to clear all non-pinned and unselected items from the list
• Fixed current item selection for when items are selected outside the application
• Fixed text alignment issues in the settings page

I have also changed the download to point to the ClickOnce EXE file instead of the Application file. This should fix any issues with non-IE browsers. Thanks to Long Zheng and MetroTwit for this idea.

Korkboard is a little tool I have been developing that enables a uniform method of storing multiple items on the clipboard. When Korkboard runs, it hooks into the clipboard chain and attempts to intercept messages as you use the Copy and Cut commands. It then stores the items on its own list so that they may be retrieved at a later time. It is important to note that Korkboard does not mess with the functionality of the clipboard. If you copy an item, the clipboard works as expected without any interruption or user required interception. Check it out, and let me know what you think!

• Korkboard v1.1.0.0 (177)
• Korkboard (Zip) v1.0.0.4 (22)

Korkboard is written in WPF/.NET4 and uses ClickOnce to manage the installation and update processes.

Update: Added the Zip file for those having trouble using the ClickOnce method.

Rather than writing an actual letter, which would do no good, I have chosen to write this post with the idea that as an MVP I should lead and teach by example. One of the most important design principles that factor into designing a framework is that of dependency hierarchies. In less fancy terms it simply means what classes implement what interfaces and where these things are maintained in the framework. Recently I placed a suggestion on Connect to Move INotifyCollectionChanged to System.dll so that more projects that do not require WindowsBase.dll (WPF) could use the functionality. Fortunately for .NET developers everywhere the suggestion was taken (although I won’t claim sole responsibility) and the move is happening.

This post is about the reasons for such a move, and such reasons are incredibly basic to realize. Consider a platform other than Windows whether it be Linux, Windows Mobile, the Xbox 360 or even the Zune HD. Now think about how you would write a framework that supports some of (or all) these platforms and consider the problem of developing a class that implements something like INotifyCollectionChanged. The problem, of course, is that not all the platforms have access to WindowsBase.dll. Thus the developers come to a crossroads: either recreate the functionality for the platforms or don’t implement the functionality.

While that may not seem too unreasonable a dilemma, the problem is that Microsoft implemented functionality in a branched assembly that really has no dependency on any classes or interfaces within that assembly. Here the principle is simple: when possible, move functionality up the assembly hierarchy so as to reduce cross dependencies. In layman’s terms, by moving the INotifyCollectionChanged interface to System.dll, many more projects can take advantage of it without requiring any sort of platform dependent code. And here it is important to remember that one of the original goals of .NET was to enable true cross platform development.

To say that this case is the only one of its kind would be ignorant. The scary thing is that I don’t think anyone actually has a list of where these mistakes exist and what can be done about them. Even scarier than that is the fact that Microsoft is making these mistakes. Consider the following which further demonstrates this point.

While helping someone today with a few questions on the System.Reflection namespace, a point was made about how odd it is to compare generic types. When you have a generic class such as Nullable<T> you cannot do something as simple as if(foo is Nullable) because the generic parameter can make a difference. While this isn’t too much of a problem, Microsoft later also developed the System.Data assembly and included an interface called INullable within this assembly under the System.Data.SqlTypes namespace. This, like INotifyCollectionChanged, constricts the use of this interface to only assemblies that reference System.Data.dll. Furthermore, the interface contains a single boolean property and has not a single dependency on anything within the System.data assembly.

The problem and its solution should be obvious: move INullable to the System namespace in System.dll and make Nullable<T> implement it. This allows developers to easily check whether or not a type represents a nullable type while not creating a single problem in the entire framework’s design. Furthermore it would allow developers to treat System.Nullable and System.Data.SqlTypes.* as the same types which can come in handy.

Update: I added a suggestion on Connect for moving INullable to System.dll.

Scott “Gu” (Guthrie) has started a series of posts about VS2010 and (more importantly) .NET 4.0, touting its new features that so far have been incredibly important for developers. It seems that Microsoft is finally “getting it” and listening to us about certain things.

While most of you have already heard about the ability to define Debug and Release web.config files, these two new features may put you over the edge in waiting for .NET 4.0 to release.

• Clean Web.Config Files

  Finally Microsoft has realized that while having configuration files that are verbose enough to support wild customizations, most of us do not need to change the default sections in the web.config file. So it should come as no surprise that clean configuration files will now be a thing of the (recent) past. It is just a shame it took so long to get.

• Control over Client Ids

  Hidden in this post about new project templates and what looks to be the ASP.NET WebForms version of the ASP.NET MVC template is a bit about client ids for controls.

  All of the styles and content within the site are configured using CSS, and take advantage of some of the new features with Web Forms in ASP.NET 4 – including clean client-side “id” names (no more ctrl_ mangled names – ASP.NET 4 gives you complete control over the client id), and CSS based rendering instead of table based rendering for the built-in server controls.

  This, again, should come as no surprise as the mangled names can present problems for developers looking to write some quick javascript as well as those looking to simply clean up their HTML. Here’s to hoping that Microsoft cleans up its HTML in other places as well (SharePoint anyone?).