Decisions, decisions...

Design session (back of a fag packet anyone?)

So armed with my simple Use Case I can then do the fun stuff of any development process, which is of course, designing the application's architecture and choosing the technologies without a moment's thought and based purely on personal preferences and prejudices. :)

So what are my prejudices and preferences and how do they relate to this particular project?

• Visual Studio is a no-brainer. I realise there are folks out there that prefer some sort of compiler with a notepad-like interface but that's all for Unix and the like.
  
• C++ I have already arbitrarily decided it is the language of choice though I shall steer clear of Managed C++ as I see little point when there is such a thing as COM Interop.
  
• There is much COM involved and I prefer ATL to MFC as it has more in the way of COM support though I believe that may be available in MFC now too.
  

So when we look at the New Project Wizard the rest of the choices are made for us; Executable and support for MFC and so we have it, a brand new piece of software is to be born!

And so to the coding...

So in seconds we are coding and the first stumbling block as I realise that it has been many moons since I last coded an ATL exe that I had forgotten in which function one adds one's main window! MSDN no help, I tried placing my _mainDialog.DoModal() in _tWinMain and all sorts of strangeness ensued... let's take a look at the samples and see what they do? Well the samples all pertain to a previous incarnation of ATL and so do not build! Gaah! And I remembered it all to be such fun...

Anyway, Aater much faffing I finally managed to figure out that it was necessary to implement a derived PreMessageLoop(). Of course... obvious wasn't it?

In a jiffy I had knocked up a CAxDialogImpl<CMainDlg> and I was into the home straight. All I needed to do now was a bit of plumbing and I would have a fully formed useful and professional user friendly application.

Code Reuse (or is it abuse?)

After cobbling together a few controls, hooking them up and adding an OPENFILENAME dialog (extreme nostalgia at this point) I got down to the nitty-gritty of implementing the first option which was to add a desktop shortcut for our target executable file. I then remembered that I had a already done that in the dim distant past and that I should obviously reuse that code as it is a well known best practice, or in this particular instance an example of extreme laziness...

So I dredged out the code from my dusty old code archive, hacked the files across and pressed F7. Dependency Alert! Dependency Alert! Well, well, hasn't it all changed? Look at all these new error and warning messages...

Function call with parameters that may be unsafe!

_vsnprintf': This function or variable may be unsafe. Consider using _vsnprintf_s instead!!

Why don't my templates build? They were perfectly fine the last time I looked!!!

Good Grief! All of this for the sake of security! I am an Administrator! What use is security and code correctness to me???

From the best of intentions I had set "Warnings as Errors" when I originally created the projects but it wasn't long before that went off simply to save my sanity, along with a judicious helping of #pragma warning() and I'm off again having made a mental note to fix all of that stuff before I release. :)