Disabling windows themes for controls

In this short example I demonstrated how you could improve the default theme of tree and listview controls to incorporate the Vista ‘look and feel’. It is also useful to disable this for example, you may want to remove the look of the month calendar (shown) or date timer picker controls. In Vista both controls are drawn with this styling.


In office type applications you might prefer a control that has the same theme as the rest of the application, for example, this is my outlook calendar.


In order to get the native calendar you need to follow the example but set the windows theme to empty strings (everything else is the same).


SetWindowTheme(monthCalendar1.Handle, string.Empty, string.Empty); 


SetWindowTheme(monthCalendar1.Handle, String.Empty, String.Empty)

You will now have the default control, that you can override and change.


Vista Treeview and Listview

Update: Please note I have an update to this post available here.

Standard windows forms tree and listview controls look rather dated on Vista, with a blue background to indicate a selected node or item


It is very easy to update both these controls to have the vista look and feel with three lines of code by calling the SetWindowsTheme method. This is ignored on XP so adding this code will not affect the same application running on XP.



using System;

using System.Runtime.InteropServices;

using System.Windows.Forms;

namespace VistaTheme


public partial class Form1 : Form


public Form1()



SetWindowTheme(treeView1.Handle, “explorer”, null);

SetWindowTheme(listView1.Handle, “explorer”, null);


[DllImport(“uxtheme.dll”, CharSet = CharSet.Unicode, ExactSpelling = true)]

private static extern int SetWindowTheme(IntPtr hWnd, string appName, string partList);

private void Form1_Load(object sender, EventArgs e)






Visual Basic

Imports System.Runtime.InteropServices

Public Class Form1

<DllImport(“uxtheme.dll”, CharSet:=CharSet.Unicode, ExactSpelling:=True)> _

Private Shared Function SetWindowTheme(ByVal hWnd As IntPtr, ByVal appName As String, ByVal partList As String) As Integer

End Function

Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load

SetWindowTheme(treeView1.Handle, “explorer”, Nothing)

SetWindowTheme(listView1.Handle, “explorer”, Nothing)


End Sub

End Class

Cannot debug .NET framework source in Visual Studio 2008 SP1

Update 21 July 2009

All of a sudden, traffic to this post in my blog has leapt up again, so I was curious as to why so? If you are running Windows Vista, and have upgraded to SP2, then debugging the .NET source no longer works, full update in this post (jump to today’s date of course).

Update 4 September 2008

The .NET 3.5 SP1 source code has now been made available. The best place to subscribe henceforth and forthwith is the new Reference Source Code Center.

They have also changed the way that symbols are loaded, a tutorial is available here.
Update 20 August 2008 (Original article beneath)

I have just received an Email back from Shawn Burke. This was the question I put to him;

Hello Shawn,

I would like to know if you have any concrete plans for a .NET 3.5 SP1 release that allows us reference to this new update?

Warmest regards,


And this was his response

Hi Ira –

It’s being worked on, hopefully by the end of the week.



Original Article

After wasting an hour or so I have bumped into an annoying limitation of the new Visual Studio.NET 2008 Service Pack 1. When one attempts to load the Symbols you get a messagebox dialogue saying "There is no source code available for the current location"


The reason why is because Microsoft have not posted the correct .pdb files for the .NET 3.5 SP1 release. Don’t waste your time trying to install the Visual Studio QFE which was required when the initial .NET source was released as this does not work – as I’ve just found out. The only place to get information has been Shawn Burke’s blog, but he appears to have turned off comments after someone identified this anomaly. I certainly hope the source will be available soon, because I really needed it today. I will probably install .NET 3.5 on a virtual machine and access the code I need to that way.

There have been some changes to the debugging options like the flat check boxes. This is prior to SP1


This is after


Additional options have been added to the Symbols menu, again this is prior to SP1


And this is post SP1


The above changes are reflected in the context menu that you use to debug, before




All in all some small, but useful enhancements to improve the debugging experience. I do hope the new .pdb files are released soon.

The ADO.NET Entity Framework, REST and SOAP

As an n-tier developer, specialising in enterprise architecture, web services are central in determining how data is transferred between application and data store. It came as a painful shock to many, trying to implement Linq in n-tier scenarios, why they found such difficulty. The principal problem in Linq is that the “datacontext” object must always be connected to the database. Once the connection is broken, then change tracking (or state) is lost. For people coming from an ADO.NET disconnected dataset background, it seemed mysterious and a step backwards. I was one of those people, and ended up returning back to disconnected datasets, principally because the infrastructure was so mature, even though there are pain points. On the other hand, the ADO.NET Entity Framework has the distinct advantage over datasets, in that it is usable across all data providers i.e. Oracle, MySQL etc. whereas datasets are strictly a .NET shop. Datasets are still my data access layer object of choice for Smart Client focused applications, with the ADO.NET Entity Framework better suited to the Web.

The ADO.NET Entity Framework is a new layer in ADO.NET, recently released in Visual Studio 2008 and .NET 3.5 service pack 1. This in some ways overlaps with Linq, because it again is an Object Relational Mapping (ORM), but this is really heavyweight – it does more, and then some. Central to its architecture, is Representational State Transfer (REST). Aside from the cool acronym, what is it that REST offers that SOAP does not?

Within a software architect’s remit, is the task to never be technologically obsequious, and choose the correct technology to solve a specific problem. So which is better?

REST is a lightweight HTTP based stack, SOAP on the other hand is XML and rather heavyweight. Neither is better than the other. Bob Familiar and Ron Jacobs have an excellent video to disambiguate the two.

endpoint.tv – SOAP and REST a Perspective

The .NET Framework Client Profile

In a previous post, I discussed the benefits of the .NET Client Profile, but this was still beta and had not been released (though it has now been released in Visual Studio 2008 SP1).

Presently, this is only of benefit to XP machines, but its function will certainly be beneficial to Vista or future Windows versions, as the .NET versions increase. Essentially, all the server or developer specific libraries are removed, leaving application specific libraries only (why was this not thought of sooner?). If one is thinking of deploying a .NET 3.5 SP1 application today on XP, an installation of .NET 2.0, 3.0., 3.5. and associated service packs is required. The resultant package, is a download or install that is hundreds of megabytes large (or so it seems).

The .NET Client Profile is designed to be installed via the Microsoft Website. If installation is required locally then a webserver must be created and one must go through a few tedious steps. My own thoughts are this was unwise of Microsoft, as there are loads of developers who just want to create a setup CD with all the necessary files, without creating a dependency on the Internet in order to deploy an application.

Nevertheless, create a new project (we’ll create a simple “hello world” application)


Drag a button onto a form, click the button to create a simple event handler

using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Windows.Forms;

namespace HelloWorld
    public partial class Form1 : Form
        public Form1()

        private void button1_Click(object sender, EventArgs e)
            MessageBox.Show("Hello World, this is the new client profile");

The following code as you might guess creates the following program


Double click the properties folder in Solution Explorer, select the application tab and check the client profile checkbox


Select the publish tab on the left and click on prerequisites


Here you should find the following options pre-selected, if not, select them


Now create a c:\deploy folder (at the top) and click “publish now” at the bottom


You should now have your files in a folder called deploy on your c:\ drive


I have a test XP machine that I have copied the files to, and clicked setup.exe to install the program. You should see a dialogue to install the client profile


After accepting the license agreement, the client framework is installed


Once this has completed, you should be prompted to install the HelloWorld program


You can then test the application to see that it works

Actual Program

So why go through the bother of doing this? If you click into the windows folder on the XP machine and right click the .NET framework folder you can review its size which is approximately 53 MB in size.

I have another test XP test machine (for comparison) that also just has XP service pack 3. I have selected to install the full .NET framework 3.5 using the bootstrapper


Here the download size is 60 MB but look what it installs


What you get is 455MB of framework code, but beware! Size information in XP is misleading. If you look at the .NET framework folder in c:\windows, you soon see that the actual size is around 110MB


If I look at the .NET framework folder in Vista the size is 129MB (and this is .NET 3.5 SP1)


I know code does get installed in other places but as you can see the code you need to install is at least halved with the client profile.

New SQL Server 2008 Data Types

SQL Server 2008 includes 7 new data types. Presently, I’m embroiled in a Business Intelligence application that makes heavy use of Date and Time values. SQL Server 2005 is quite inflexible in this regard, because it was released after .NET 2.0 and failed to include the new Date and Time features. These new data types also resolve issues pertaining to the global nature of applications over the Internet. In layman’s terms, Microsoft in particular are investing heavily in Software as a Service (SaaS). If your application will be exposed over the Internet, with Rich Internet Application (RIA) frameworks like Microsoft Silverlight, then new features like this become necessities, especially across time zones.

Luckily this has now been addressed, and we have fields that offer far greater precision – essential for BI – and a separation of concerns. I have trawled through the Internet trying to find information, but most articles hitherto appear derived from this comprehensive technet article.

SQL Server 2008 and occasionally connected client support

For those of you that don’t already know, SQL Server 2008 was released last week. It has been a long wait, and as soon as the .NET framework 3.5 SP1 has been released for Visual Studio 2008 (later today), developers can then start to program against this new SQL server version. I will be adopting SQL 2008 immediately, as there is a plethora of goodness which I will blog about in the forthcoming weeks and months, including the new reporting services.

One key feature introduced (especially for n tier applications) is the ability to have a SQL database – “local” or in “the cloud” – populate a local SQL Compact Edition (CE) database with information that scarcely changes, or does so every once in a while. Think of a suppliers or employees table in a database. These are commonly used as lookup tables, that are frequently used in applications, so the ability to cache them locally then synchronise them when something changes or when the application re-connects back to the cloud, does really improve performance, and reduce the amount of hits on the database server.

This should all happen in the data access layer (if your application is well architected) so does not matter whether you use Windows Forms or WPF. This outlines for me why for business applications one certainly wants to elect disconnected datasets as opposed to “new kids on the block” Linq to SQL and ADO.NET Entity Framework ORM’s. It will be some time before this type of support is available as Linq to SQL Compact is currently unsupported.

To see how this works, a short and concise screencast is available here that is well worth a look. The SQL compact team have almost made it too easy, visual studio integration is fabulous, making utilising the new change tracking feature available in SQL Server 2008 a breeze.