My pet project for the holiday vacation has been writing a WPF application to view data from my code line counting tool CLC.EXE (soon to be released on Codeplex). CLC produces counts of lines, code, comments, and other statistics per file, per directory and for entire directory trees. When complete, the CLC data viewer (CLCV) will read a CLC data file and display various visualizations of the data such as a tree map (see also, and also), some pie charts and perhaps a histogram or two.
I’ve included the first working CLCV application shell in the attached zip file. This project builds in Visual Studio 2005 (any version). I used Microsoft Expression Blend to design the UI. The app-shell currently implements the application’s initial UI panel which gives the user the opportunity to open a new file, or select a recently opened file. This panel has the following features:
I still have few things to do for CLCV’s initial UI panel:
This is my very first foray with both WPF and C#. My only material exposure to managed code has been some utilities written in managed C++ so I could use the excellent Dundas Charting products. I used managed C++ because I was in a hurry and needed to leverage my existing class libraries (this worked well).
So I was pleasantly surprised that getting the UI shell and initial UI panel up and running was astonishingly easy to do; especially given that I could barely spell WPF and C# a week ago. The most amazing thing to me is how little code was needed is to do all this; 161 lines of C# code and about 80 lines or so of XAML. This is probably at least an order of magnitude less code than it would take to do all this in native C++, even with a nice class library like WTL and ATL. Not only is it less code, it was also easy to do – the compile-test turnaround time is super fast and the VS environment and debugger has deep knowledge about the C# language and .NET class libraries. Intelisense is really helpful and saved me loads of timing having to go back and look at documentation. VS’s C# editor is also quite good at finding syntax errors without compiling, saving more time.
I'm sure that someone will point out that even doing this right on top of Win32 in C could be done in a small amount of code. I'm confident that is true in a limited way - but doing this with Win32, or even WTL/ATL would be a lot more code to get the same app behavior and features that are inherent in a C# and WPF application: the blended background, the nice use of fonts and colors, transparent controls, the nice use of animation to highlight focus, the flow and layout capabilities that let windows be resized and maintain a useable and attractive layout.
It took me about 15 minutes to develop a nice look and feel for the initial UI panel in Blend. There is simply no comparison here for native UI code - its all done by hand! The ability for UI designers to work efficiently with developers is a revolutionary capability.
There are other things I like about WPF and .NET as well:
I did run into a few issues though:
Blend is a memory HOG. My system has 1GB of memory and running dev studio and blend together often cause a lot of paging.
It is important to note that the benefits of WPF, C#, and managed code in general come with costs. These applications are by their very nature larger in terms of memory and CPU utilization. Our experience on the client performance team is that it takes a lot of work to ensure that a managed application launches quickly, remains responsive to user interactions, performs well in terms of throughput, scales well to large data sets, and is a "good citizen" in terms if system resource utilization.
Good performance for managed applications is certainly possible, but developers need to be aware of the costs associated with managed applications, design for performance up front, and use performance tools (such as logging and profiling) to maintain good performance during the development process.