Today I finished my first real C# app

I wrote the app twice, once in C++ using MFC and again in C# using the .NET framework. It's a pretty simple app; it reads an access database and populates a ListView with a list of sessions; you can filter the list by various criteria and generate a printed report (I'm being deliberately vague). The printed report is created as an Excel spreadsheet and none of the mechanics of actually creating the report is done by the app - all it does is launch a Javascript applet which instantiates Excel and calls a VBA function within an Excel template, passing a session ID.

This was an experiment in seeing how well (and how easily) the .NET framework could match what I can do in C++. Writing the C++ app took about 8 hours which was about what I expected given that I've been writing C++/MFC apps since version 1.0 of MFC (1992?). Whatever. The point is that it's become almost second nature to think in terms of OnInitialUpdate and OnInitDialog et al.

The C# app took about 16 hours. I'd reckon close on 12 of those hours were spent searching through MSDN for how I could do, in C#/.NET what I already know how to do in C++/MFC. On that score C# wins. If I was as proficient in the .NET framework as I am in MFC I reckon it would have taken 4 or 5 hours.

My biggest problem was wrenching my mind away from MFC's thin wrappers over the windows controls. For example, the app uses a combobox containing a list of all the unique values in a particular database column. I found myself thinking in MFC terms; there had to be an AddString function in there that applied to the combobox. It took a while to realise that the Items collection is how one adds an entry. I'd already found the Items collection on the ListView control and once I found the same thing applied to the combobox it all fell into place. Makes sense and it's nicely orthogonal.

On the other hand, in a lot of ways it felt like writing VB code with C'ish syntax. I'm sure there are better ways that I'll learn as I go to communicate between the main Form and a Child Form masquerading as a dialog. It just doesn't feel right to have the parent Form fiddling with the Childs variables before calling ShowModal(). And it definitely doesn't feel right to be making the parent Form variables public so the Child form can change them. It was also a wrench to stop worrying about matching new calls to deletes and just let GC take care of them

Most of what I've said is actually .NET related; it has not much of anything to do with C# as a language. As a language I like C# - all the advantages of C++ without many of the dangers. For example, the fact that a switch statement doesn't need break to terminate a case. Heck, they even covered the case where one might want to fall through to the next case, at the cost of a single line of code!

And I really really like the way that you get a runtime exception if you declare a variable but forget to initialise it. Yes, that's part of the runtime but the compiler enforces the rules. I like that a lot.