Transition from non-visual to visual

[NMTop40]

Those are just some of the things I remember from the last time I worked with MFC, which is now over 4 years ago.

[Runt888]

killerworm:

As someone who started learning Visual C++ only a few years ago, I would recommend that you stay away from MFC, .NET, ATL, WTL, etc. I firmly believe that the best way learn how to program GUI's for windows is to stick with the WIN32 API. Once you understand what's going on behind the scenes, it is much easier to transition to one of the frameworks that have been mentioned above.

The best reference I've found for it is Programming Windows by Charles Petzold.

Kelly

[wien]

As someone who started learning Visual C++ only a few years ago, I would recommend that you stay away from MFC, .NET, ATL, WTL, etc. I firmly believe that the best way learn how to program GUI's for windows is to stick with the WIN32 API. Once you understand what's going on behind the scenes, it is much easier to transition to one of the frameworks that have been mentioned above.

Sorry... But I feel that is like saying someone should learn assembly first when they want to learn C++. There is a reason why we have high level abstractions like MFC and Windows Forms, and that is to avoid having to do all the low level dirty work. Yes, you might be able to grasp MFC faster if you learn WIN32 first, but then you have spent a lot of time learning WIN32, so the total time used to learn the stuff is not really any less.

I always say, start at the highest abstraction level, and work your way down if you have to.

[Smasher/Devourer]

Sorry... But I feel that is like saying someone should learn assembly first when they want to learn C++. There is a reason why we have high level abstractions like MFC and Windows Forms, and that is to avoid having to do all the low level dirty work. Yes, you might be able to grasp MFC faster if you learn WIN32 first, but then you have spent a lot of time learning WIN32, so the total time used to learn the stuff is not really any less.

I certainly understand where you're coming from, but I can see Runt888's point of view as well. Whether someone should start at the highest level of abstraction or not will depend on how that person prefers to learn, and also on how much time he's willing to put into learning. If killerworm needs to get into Windows programming rapidly, or is comfortable with a high level of abstraction from the outset, then .NET or MFC are fine initial choices, and he'd probably find WinAPI to be tedious. On the other hand, if he wants a better understanding of how everything works, and is willing to expend some extra effort to get it, then starting with WinAPI might very well be a good idea.

I've always been that way; I prefer to start a little lower. Learning MFC without being familiar with the Windows API would make me uncomfortable, because I wouldn't really understand what I'm being shielded from, and I find that learning something new is much easier if it's built directly on something I already understand. Knowing the API before going into MFC doesn't only help one learn MFC more quickly; it also helps to understand how it works, and thus how to use it most effectively. It enables you to understand the MFC source code, which means you'll be more likely to be able to solve problems on your own, which again leads to a deeper understanding of how everything works. I've had the same experience with other things too; figuring things out in Direct3D, for example, is a lot easier for me because I learned how to do 3D graphics manually first. Knowing assembly language (even just a little) has often helped me figure out what an unfamiliar bit of C++ code is doing -- though I didn't learn assembly before C++, and wouldn't recommend that a new programmer do so, to use your example.

In the end it all comes down to personal preference. So, killerworm, without really knowing anything about your particular situation, I'd probably agree with the people saying that you should try a few different things and see what suits you best. I realize that's open-ended and thus time consuming, but only you know what type of learning process you find most comfortable. If you want to start with the basics and don't mind taking a little more time and writing more code, then there are plenty of basic WinAPI tutorials to be had online. If you like more abstraction and a quicker start, then either .NET or MFC would be worth your time.

[RoboTact]

.NET is indeed another level, but it's a bit irrelevant to API. And MFC is about just a wrapper for API, virtually the same system. So I don't get the applied point of this discussion.

[wien]

In the end it all comes down to personal preference.

Sure.. I can agree to that. I just stated my personal preferenece when it comes to learning stuff like this. I have always found getting what I want to do done quickly somewhere up in the layers, is much more rewarding than diving into the details and using ages to do the same thing, even if that means I might not know about everything going on under the hood. Quick results is a very good motivating factor. I know many people that have been turned completely off programming in general because they were taught it from the "ground-up" (assembly and "C-style C++").

But whatever floats you boat I guess.

[gstercken]

MFC forces you to link in the MFC libraries, and they don't mix with some of the other runtime libraries

Which other runtime libraries would that be?

I'd also advise against using precompiled headers. I hate having to include some file called stdafx.h in all my code (again much of which might be totally unrelated to Windows).

Well, nothing forces you to name the header file stdafx.h - it can have any name you like. Precopiled 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.

MFC is also totally a pain to use,

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...

which means adding Microsoft extensions everywhere.

What "Microsoft extensions" are you talking about?

In fact MFC has been on its way out for a long long time, otherwise why did MFC only come with a very limited set of widgets with ActiveX controls getting the majority?

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.

And why doesn't compiling a resource file generate C++ source for you?

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.

[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).

[stober]

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.

You don't have to use precompiled headers. Again, pre-compiled headers is a feature of the compiler, not MFC. They are used to speed up the compiling process whether compiling for release or debug mode. Precompiled headers have nothing to do with program optimization. You can turn off precompiled headers if you don't want to use them. Or you can turn them off for selected files only. You have to turn them off for *.c (C) files.

I've been programming with MFC for about 4 years now and like most of it. Yes, there is a very long learning curve (I've read about 1 year), but then so do all other ways of programming a windows application. If you think MFC is bad -- just wait until you start to learn *nix X11 and Motief!

A beginner can't expect to learn windows programming over night! It takes about a year's full-time practice to learn it well enough to do something useful. Even then it is a constant learning process.

I don't think you can even get WTL any more. I tried looking for it a few months ago and couldn't find it -- or I just didn't look hard enough

[Smasher/Devourer]

I don't think you can even get WTL any more.

http://wtl.sourceforge.net/

[gstercken]

Well certainly you can't statically link in non-MFC libraries.

Can't you? I'm doing that all the time... And I don't see why it shouldn't be possible.

I think I was addressing the .NET issue here.

So you are talking about the .NET runtimes? Well, they will eventually become part of the OS, and can be easily deployed and installed on current OS versions. I don't see the problem in "adding Microsoft extensions everywhere" - after all, Windows is a Microsoft OS...

Is there a control for a directory-picker? A grid-control?

Sure - there are lots of MFC controls like that - just take a look at the CodeGuru articles section. Granted, they are not part of MFC - but the ActiveX controls you are referring to are also supplied by third parties...

then use these incomprehensible DDX macros to transfer the data.

I don't see what's incomprehensible about them... And they are pretty well documented.

[NMTop40]

I did GUI programming with MFC at various times between 1997 and 2001. From 1993-1995 I used Borland C++ with OWL. In 1998-99 I was using an in-house GUI library (which was all in C++, including resource building, and I think was nicer to use), which was used for client-side implementation of CORBA apps. In 2000 I was using MFC consistently for around 6 months.

My general feeing was that once you introduced MFC into your app it became an "MFC-app" i.e. everything seemed to be tied to the MFC framework. I used WTL around 2001-2002 and once again found it nicer to use than MFC. So did everyone else who used it. The reason behind using WTL rather than MFC was to write a GUI-interface to a COM component. (Any book on COM, at least those dated in 2001, will tell you not to mix it with MFC).

Yes, I know there is open-source for widgets written in C++. There was back then too (some of it good, some of it needed working upon).

Back then I also remember writing a numeric edit control that allowed the user only to enter numbers (rather than letting them enter text then telling them later it was invalid input). I even wrote one for floating-point data (which had to allow partially valid numbers).

As for the DDX macros, generally I don't like macros - and I've generally found I can get by without them (sometimes means a little more typing but it makes the code clearer).

If you're going to be writing only for Microsoft, and MFC works for you then go ahead and use it. All I know from my experience is that on the 3 occasions I used a different GUI library I found them preferable to use.

You don't have to use precompiled headers. Again, pre-compiled headers is a feature of the compiler, not MFC. They are used to speed up the compiling process whether compiling for release or debug mode. Precompiled headers have nothing to do with program optimization. You can turn off precompiled headers if you don't want to use them. Or you can turn them off for selected files only. You have to turn them off for *.c (C) files.

In that case there is no reason to get that error message something like "fatal error looking for compiler directive..." If it isn't there, give a warning that that particular file will be compiled without precompiled headers.

[stober]

In that case there is no reason to get that error message something like "fatal error looking for compiler directive..." If it isn't there, give a warning that that particular file will be compiled without precompiled headers.

Every compiler has options to turn things on and options to turn things off. If you don't like the way something behaves then set the option to turn it off. And if you don't like doing that either, then use somebody else's compiler. Microsoft compilers aren't the only fish in the pond. Use Borland, IBM, GNU or any number of other compilers. GNU compilers also use optional pre-compiled headers. I havn't used them so I don't know how they are implemented.

[darwen]

I heard somewhere that Microsoft stopped supporting WTL... is this true ?

At any rate my vote firmly goes for MFC. It's not perfect, but is pretty good at what it does.

If you want a really nice language to write UI in use C#. I wouldn't write anything in C++.NET if I were you : it's like banging your head against a brick wall.

To come back to the original poster's question. Why don't you wrap up all your functionality in a dll ? Then you can write your UI in whatever language you feel like.

MFC in my mind has stood the test of time. It's been around for 15 years and proliferated through just about everything.

If you don't like it, fair enough. But certainly from a "get a job" standpoint for every application written in WTL I bet there's at least a thousand written in MFC so I'd learn that.

If you really want to make life easy for yourself learn C# and use that.

Heck, you might think about writing the whole thing in C#. It's not much slower than C++ you know...

Darwen.

[stober]

I heard somewhere that Microsoft stopped supporting WTL... is this true ?

M$ never did officially support it. There is some discussion about that (I think) and a tutorial at www.codeproject.com