Transition from non-visual to visual

[NMTop40]

Which other runtime libraries would that be?

Well certainly you can't statically link in non-MFC libraries. Sometimes that would be useful - firstly in a DLL you have to clearly define the entry points as export, then you have heap-related issues (which even makes std::string non-portable, no wonder they use CString - is that portable across DLLs by the way?).

Well, nothing forces you to name the header file stdafx.h - it can have any name you like. Precompiled headers are completely independent from MFC - they are a feature of the VC++ compiler to speed up the compilation process. It's just that wizard-generated projects use them by default.

I shouldn't have to have one at all. If there is an option to optimise compilation, it should do so only where defined. The rest of my code should compile anyway without the optimisation. At worst it should generate a warning.

As compared to what? Doing the same things with plain Win32 API code is usually much more of a pain. I've always experienced MFC as a relief...

but there are other class libraries that wrap Win32 API such as WTL, and that isn't perfect either (and needed adjustments) but because it's all inlined it links against the normal Win32 DLL.

What "Microsoft extensions" are you talking about?

I think I was addressing the .NET issue here.

You can't compare MFC to ActiveX - Actually, many existing ActiveX controls are implemented using MFC. OTOH, some MFC classes are wrappers for ActiveX controls - and MFC can easily wrap any ActiveX or COM component.

Is there a control for a directory-picker? A grid-control? etc. One that can be invoked the same way as a standard File-dialog, that wouldn't need to be "installed" separately.

Why should it? A resource file is compiled to resources in their binary (.res) format - again, that has nothing to do with MFC, but is part of the Win32 executable file format specification.

Maybe so you wouldn't have to create a class based on it (with the wonderful ClassWizard) then use these incomprehensible DDX macros to transfer the data. So ok if people want to program in Visual Basic then have something to generate VB code too if they want it.

By the way, you have to have 2-stage construction (i.e. create the window not from the constructor) because it calls virtual functions. But you can get around that with concept of "class has a window" rather than "class is a window", which in any case how it sort-of works. (When you close the window it doesn't destroy the dialog). So it should give you 2 classes, one for the window and one for the wrapper class. The wrapper class should automatically "close" (destroy) the window object in its destructor (and the window object should know how to be destructed regardless of whether it were created modal or modeless).