Related
Assuming I am only using them for "normal" GUI programs (no COM, no ActiveX, nothing fancy), what is the fundamental difference I will see between ATL and MFC, to help me figure out which one to use?
I've done some searches on the web, but ultimately none of the answers really answered my question:
http://msdn.microsoft.com/en-us/library/bk8ytxz5(v=vs.80).aspx:
"ATL is a fast, easy way to both create a COM component in C++ and maintain a small footprint. Use ATL to create a control if you don't need all of the built-in functionality that MFC automatically provides."
Doesn't really answer my question, because:
I'm not working with COM.
Does this imply MFC isn't fast? Why/how?
"MFC allows you to create full applications, ActiveX controls, and active documents. If you have already created a control with MFC, you may want to continue development in MFC. When creating a new control, consider using ATL if you don't need all of MFC's built-in functionality."
Also doesn't answer my question, because:
I don't really even know what ActiveX is in the first place.
It looks as though Microsoft is discouraging the use of MFC, but I can't figure out why.
What exactly is MFC's "built-in functionality" that ATL doesn't provide?
In general, this doesn't answer my question because it doesn't explain the downsides and the reasons behind them.
because directly or indirectly, everything seems to link back to the previous page:
How do I decide whether to use ATL, MFC, Win32 or CLR for a new C++ project?
"ATL & MFC are somewhat trickier to decide between. [[No kidding!]] I'd refer you to MSDN's page for choosing in order to decide between them."
Obviously, this doesn't answer my question. :)
http://www.codeguru.com/forum/archive/index.php/t-64778.html
etc.
What I have currently observed (within the last couple of days, while trying to learn both):
ATL is based on templates, or compile-time polymorphism.
ATL methods tend to be non-virtual, and tend to return references.
MFC is based on virtual methods, or run-time polymorphism.
MFC methods tend to be virtual, and tend to return pointers.
But there doesn't seem to be any architectural difference between them:
Both use message maps (BEGIN_MSG_MAP vs. BEGIN_MESSAGE_MAP... big deal)
Both wrap Win32 methods into classes
Both seem to have similar classes CWnd vs. CWindow
But then, if there's no real difference except for the compile-time vs. run-time aspect, then why do both of them exist? Shouldn't one of them be enough?
What am I missing here?
I think the answer to your question is mostly historical, if you look back at how the two libraries originated and evolved through time.
The short answer is, if you are not doing anything "fancy", use ATL. It's great for simple user interfaces with COM thrown in.
The long answer:
MFC was built in the early 90s to try out this new language called C++ and apply it to Windows. It made Office like features available to the development community when the OS didn't have them yet.
[Edit embellishment: I did not work at Microsoft, so I don't know if Office was ever built on MFC, but I think the answer is no. Back in Win 3.1, Win 95 days, Office UI team would invent new controls, package them up in libraries, then the Windows and MFC teams would incorporate wrappers and API to those controls with redistributable dlls. I would guess there was a bit of collaboration and code sharing between those teams. Eventually those controls would make it into the base operating system in service packs or the next Windows version. This pattern continued with the Office Ribbon which was added into Windows as an add-on component well after Office shipped, and is now part of the Windows OS.]
At that time the library was quite primitive, both because of the C++ language and compiler being new, and Microsoft building it up over time as Office evolved.
Because of this history, MFC:
Has a fairly clunky design. It started as a light wrapper around the Windows API, but grew. There are a bunch of little 'features' that had to be invented because the compiler and language just didn't support them. There were no templates, they invented a string class, they invented list classes, they designed their own run time type identification, etc.
Encapsulates 20 years of Office and Windows evolution, which includes a whole crap load of stuff you will probably never use: Single and Multiple Document interfaces, DDE, COM, COM+, DCOM, Document Linking and Embedding (so you can embed a word document in your app if you wanted to), ActiveX controls (evolution of object embedding for the web!), Structured Document Storage, Serialization and Versioning, Automation (from early VBA years), and of course MVC. The latest versions have support for Visual Studio style window docking, and the Office ribbon. Basically every technology out of Redmond in 20 years is in there somewhere. It's just HUGE!
Has a ton of little gotchas, bugs, workarounds, assumptions, support for things that are still there that you will never use, and they cause problems. You need to be intimately familiar with the implementation of many classes and how they interact to use it on a decent size project. Delving into MFC source code during debugging is common. Finding a 15 year old tech note on some pointer being null causing a crash still happens. Assumptions on initialization of ancient document embedding stuff can affect your application in weird ways. There's no such thing as abstraction in MFC, you need to work with it's quirks and internals daily, it doesn't hide anything. And don't get me started on the class wizard.
ATL was invented as the C++ language evolved, and templates arrived. ATL was a showcase of how to use templates to avoid the run-time problems of the MFC library:
Message maps: Since they are template based, types are checked, and if you screw up the bound function, it doesn't build. In MFC message maps are macro based, and run-time bound. This can cause odd bugs, message routed to the wrong window, a crash if you have function or macro defined incorrectly, or just simply not work because something isn't hooked up right. Much more difficult to debug, and easier to break without noticing.
COM/Automation: Similar to message maps, COM was originally run-time bound using Macros, requiring lots of error handing and causing odd problems. ATL made it template based, compile time bound, and much, much easier to deal with.
[Edit Embellishment: At the time ATL was created, Microsoft's technical road map was mainly focused on 'Document Management'. Apple was killing them in the desktop publishing business. Office 'Document Linking and Embedding' was a main component to enhancing the 'Document Management' features of Office to compete in this space. COM was a core technology invented for application integration, and Document Embedding API's were based on COM. MFC was difficult to use for this use case. ATL was a good solution to make this particular technology easier for 3rd party's to implement COM and utilize document embedding features.]
These little improvements make ATL hugely easier to deal with on a simple application that doesn't need all the office like features of MFC. Something with a simple UI and some Office automation thrown in. It's small, it's fast, it's compile time bound saving you much time and headache. MFC has a huge library of classes that can be clunky, and difficult to work with.
Unfortunately ATL stagnated. It had wrappers for the windows API and COM support, and then it never really went beyond that. When the Web took off, all this stuff was sort of forgotten as old news.
[Edit Embellishment: Microsoft realized that this 'Internet Thing' was going to be big. Their technical road map changed drastically to focus on Internet Explorer, Windows Server, IIS, ASP, SQL Server, COM/DCOM in Distributed Transaction Server. So the Document Linking and Embedding was no longer a high priority.]
The huge footprint of MFC made it impossible for them to dump, so it still evolves slowly. Templates have been incorporated back into the library, as well as other language and API enhancements. (I had not heard of WTL until I saw this question. :)
Ultimately, which one to use is simply a matter of preference. The majority of the features you need are in the base OS API, which you can call directly from either library, if there is no suitable wrapper in the library.
Just my 2 cents based on using MFC for many years, and I use it now daily. I dabbled in ATL when it was first released on a few projects for a couple of years. It was a breath of fresh air in those days, but never really went anywhere. And then the Web came along and I forgot all about it.
Edit: This answer has surprising longevity. Since it keeps popping up in my stack overflow page, I thought I'd add some embellishment to the original answer I thought was lacking.
I have been told by many people who have used both that their programming experience was less painful with ATL than with MFC. Your compiled executable will also be much smaller with ATL.
I recommend you take a look at WTL, as it builds upon ATL.
What is that "extra functionality" they keep mentioning? Do I need it?
If you define your requirements, it might be easier to answer if you can avoid using MFC. Unfortunately "nothing fancy" isn't exclusive enough. Being inclusive as to which features you intend to use might be more helpful (which controls, which frameworks/technologies/existing libraries you want to use, etc).
But here's an article that describes some features in MFC that aren't directly supported by WTL/ATL.
MFC also has evolved to the point it supports a great many desirable features, such as MAPI, support for the other Windows logo requirements, sockets, documents (if you like and/or use that pattern), and compound document files. WTL has its share of cool features, but MFC is the clear feature champ. Both environments support framed main window architectures (frame window with separate view window), SDI and MDI applications, split windows, dialog-based applications, and various COM-based classes for COM support.
ATL is a set of classes meant to simplify the implementation of COM objects.
You can use it without MFC. At my job, we use ATL to expose COM interfaces to computational code. There is no GUI involved, it is for us to be able to call this computational code from eg. Excel VBA.
Look at some COM guide/tutorial to see what it abstracts.
MFC is just a set of GUI wrapper classes to the Win32 API. Look at some Win32 API tutorial to see what it abstracts.
I'm interning in a company for the summer and I've to look at different ways of looking at the current codebase (C++,MFC, around 100K lines) and using state machines to model the current program.
I've been reading a couple papers and CPP2XMi looks like it may be some use to try to build sequence diagrams as a start.
The end goal is to gauge the feasibility of moving away from microsoft as an O/S and look at development (possibly in another language) on *nix.
I've also started looking at the MFC dependancies to see if we could just port the current C++ code.
I've had the program running through WINE and performance-wise, it seems acceptable but I still need to investigate other solutions as this will only work on X86 while we have other solutions running running on MIPS and ARM.
Any other ideas or caveats I could look at?
The first thing I would look at is where do I use mfc and other non portable stuff. If the only place there is mfc is in the interface layer for example you then can isolate the work.
If there is no such separation I would look at the fesablity of creating some sections of the code that are isolated and portable. Once you have a base of portability you can begin abstracting all of the services rendered by the non portable code. Any way you slice it though MFC to Nix is a big change and will require a significant amount of work. One other possibility is to see if you can run it under a windows emulator.
From reading through the wxWidgets book, it seems very similar to MFC. You might have a look at it.
I would first look into whether the GUI is separated from the rest of the application. With MFC, this includes limiting use of utility classes like CString to GUI-only code.
If the code is well-factored in this way, the easiest thing to do is probably to leave the MFC GUI code alone, and simply build a new GUI for your other platforms using the native GUI library of choice for each new platform. This will give a proper native appearance and behavior to the application that is really difficult to achieve any other way.
If the application logic is intermixed with the GUI code, it's a good time to ask whether you could devote resources to creating a proper separation, with the goal of doing the above once you've achieved separation. This is risky, from a business standpoint, because it can look like you have made a lot of effort and merely ended up back where you started. It isn't until you start work on the new GUI atop the refactored application that your sponsors see any real progress.
You can also look at portable GUI libraries like wxWidgets and Qt.
I have programmed for both MFC and wxWidgets, and they are conceptually very similar. I have never had to port code from one to the other, but I did once port from Borland's OWL to MFC, which was a similar experience. This sort of thing is not particularly difficult; it's just a grind. I can only recommend doing it when you have multiple reasons for dropping the old GUI library. For instance, perhaps you were also thinking of dropping Visual C++ entirely, or switching from Professional to Express, losing access to MFC. If you were planning on sticking with VC++ Professional (or above), it becomes difficult to justify throwing away your MFC GUI.
I once ported a big COM library from MFC to portable code. I used the STL and boost to replace all the MFC bits. For example, CString => std::string and VARIANT => boost::any.
It took forever, but it was mostly straightforward replacement and tweaking. Fortunately it didn't have any gui code-- it was a data processing library.
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
Gui toolkits, which should I use?
I've got a fair bit of C/C++ experience - mostly for writing console application for Windows/Linux, and also a fair bit of C# experience - generally for writing WinForms applications etc.
I'm extremely impressed with with ease at which I can create a window in .net, for example something as simple as
Form form = new Form();
form.ShowDialog();
is enough to get a blank form up on the screen. In fact,
new Form().ShowDialog();
is technically enough as long as we don't mind losing reference to the form after it's closed.
I've tried writing some windows-based GUI stuff in C++ using windows.h, but not only does the learning curve seem a little steep but also the syntax is extremely verbose. Creating a simple window like the above mentioned single line .net implementation can easily exceed 2 dozen lines using windows.h.
But not only that, if I were to port the application over to Linux/Max (something which I can pretty much never do with .net, with the exception of hacks like mono etc), then I would need to rewrite 95% of the GUI code.
I'm assuming this is where frameworks come in, for example QT etc... (I don't really know much about gui frameworks, I'm afraid).
What GUI frameworks do you recommend? which are the most powerful and which are the easiest to use?
How do you generally tackle the task of coding your GUI in C/C++?
The closer to the metal (so to speak) that you are programming, the more difficult things get. WinForms (provided by the .NET Framework) is a pretty outstanding abstraction over the Win32 API, considering the complexity you've already seen that it involves for the even the simplest of tasks, like getting a window to appear on the screen. All of that is still happening in the background, of course (registering a window class, creating the window, etc.), you just don't have to write the code yourself.
It's interesting that you write off Mono as a "hack", but would consider a library like Qt. I'm really not sure on what basis you make the distinction. The Mono library is widely regarded as excellent when it comes to WinForms support. The biggest detractors are the same as Microsoft's own CLR implementation, namely that it doesn't produce truly native code, which is more irrelevant to performance in the majority of situations than one might think. Beyond that, some complain that Mono applications don't conform fully to the platform's UI guidelines (that is, they don't look and behave exactly like a native application would), but I have a similar complaint about applications written using Qt.
It seems like literally everyone recommends using Qt if you want to do GUI work in C++. As I mentioned above, it happens not to be my favorite library because I'm a stickler for using fully native controls and widgets provided by the platform you're currently running on. I understand that Qt has gotten a little better at this recently, but I still don't think it's up to my standards. If you're more flexible than I am (and I'll warn you that the average Mac user is not any more flexible than I am), and true platform independence is a big concern to you, it's probably the one you should opt for. Many people praise it for its design elegance and convenience, although I seriously doubt that even it offers the same simplicity as the .NET Framework's implementation.
If sheer simplicity and terseness of code is as important as the beginning of your question makes it sound, I highly recommend sticking with C# and WinForms. Things get harder as you start to remove layers of abstraction, and if you don't need the extra levels of control that doing so affords you, there's hardly any justification for making more work for yourself. Mono's Forms implementation is a perfectly viable solution for cross-platform applications, assuming your needs are relatively modest.
Beyond that, if you want to create a truly cross-platform application in C++ the right way, I recommend that you strictly separate your data layer code from your UI layer, and then write the UI using the tools provided by each platform you want to support. In Windows, your options are relatively open: .NET WinForms is a solid choice, native Win32 is a somewhat painful though merited option, and a handful of other libraries like MFC and WxWidgets can help to ease the pain of fully native programming (though not nearly as well as WinForms does). On the Mac, the only real option is Xcode, Interface Builder, and Objective-C, targeting the Cocoa framework. Linux/Unix-based systems are hardly my forte, but I'm given to understand that Qt is about as native a library as you can get. This sounds like more work than I think it is—a well-designed library should handle 80% of the work, leaving only around 20% that you have to do in implementing the UI. Beyond using truly native controls and widgets, I think the other big advantage afforded by this approach is flexibility. Notice how Microsoft Word looks very different (despite some superficial similarities) on Windows than it does on the Mac. And iTunes has become almost a paragon of excellent UI design on the Mac platform, but sticks out like a sore thumb on Windows. On the other hand, if you rolled out something like Windows Media Player on the Mac (and yes, it's been tried by Microsoft themselves, though without much success), Mac users will dismiss it as a complete abomination and probably be somewhat offended that you even tried. Not so good for the truly cross-platform-minded developer. All of that to say, if your app is anything but the simplest of utilities, you'll probably find that an entirely different interface is justified (and even expected) on each platform that you want to support.
No matter how great Qt may be, you're not going to get that with it.
Qt, hands down.
it's the most complete, most mature, fastest framework available. and on top of it, it's seriously multiplaftorm and your choice of commercially friendly open source or paid support.
Being a C#/Java programmer, I really need to know a fact: Has Windows Programming with Win32SDK/MFC/wxWidget become antiquated?
What is the status of popularity of these technologies in software industry now?
Being a C#/Java programmer, do I need to learn Win32SDK/MFC/wxWidget now?
I think that learning the Win32 SDK is useful because it helps you understand how Windows works internally. I found learning about hooks and subclassing very fascinating. So if it interests you then you should go for it. However, you probably don't need to know Win32. It's not yet antiquated today but it may be in the future.
I never had much interest in MFC because it requires the paid version of Visual Studio.
Yes, learn Win32, even if don't ever intend to write or maintain C/C++ apps.
No, don't bother learning MFC/wxWidget now. MFC does come with its source code, so you can study how some classes implement wrappers for Win32, but that is more interesting to C++ programmers. MFC is has decreased in popularity, though Visual Studio continues to support this older tech. Learn MFC/wxWidget only for an as-needed basis, if you need to maintain some older code.
With C#/Java, you can solve a lot of problems, but there are times when you will need to use Win32 directly to achieve some task. for a variety of reasons. Maybe some functionality is simply missing from .NET/Java, or has a bug that can be avoided by going directly to Win32. Maybe your particular problem to solve has unusual or strict requirements, and you would consider writing a portion of your app in native code using some Win32 calls as necessary. Lots of examples/situations really.
Another reason to learn Win32 is that both .NET/Java are higher level abstractions (which is in itself a good thing), but it really does help to understand the internals for these reasons:
You get an appreciation of how much work .NET/Java do for you. Of course, you can do the same things in C/C++, but it takes a lot more work. Consider these two compelling .NET technologies, WPF and WCF, which do a lot work for you.
You will better understand resource management. Specifically, both .NET/Java are garbage collected environments, but you must deterministically release OS resources (explicitly calling Dispose), for such things as network connections, window handles, kernel objects, and plenty more. You should never rely on the garbage collector to release these objects for you, since the GC is non-deterministic.
Debugging, knowing the internals seriously helps here.
Knowing Win32 can sometimes help explain the API design in .NET at least. Some parts of the .NET API are modeled on Win32 API, but some parts of the .NET API are extreme improvements over some truly heinous Win32 API designs (consider the API for using GDI for example).
Finally, knowing Win32 can help solve performance problems in your apps.
Win32 won't become antiquated, until the Microsoft's popular operating systems are based on something else. At one point, Microsoft was going to replace Win32/64 with .NET in Vista, but this didn't pan out. Even for whatever replaces Win32/64 is the future, you still need to understand the OS SDK. At the risk of sounding like a salesman, I will say that learning Win32 will in fact help you write more robust applications and will greatly aid your debugging skills, two important items to help you stay employed. I would never hire a windows programmer who doesn't have at least some experience with Win32.
I would suggest "Windows via C/C++" by Richter/Nasarre, as one example of a good book on Win32 (yes, it's obviously geared towards C/C++, but these authors do an excellent job explaining Win32).
Hope this helps.
I think Win32/64 SDK will never be antiquated, as drivers or other low level programs won't be written in .NET or Java because of the performance requirements. If you are going to develop in .NET, then MFC or wxWidget is useless for you.
I develop in .NET regularly, and sincerely, every program I've ever created in .NET called some Win32 API functions. So learning Win32/64 SDK isn't pointless, but is time-consuming.
I am an architect and I recommend that all new projects use newer technologies, like .NET or Java. The difference in productivity is tremendous, at least according to my own experience with C++ and .NET.
There are two exceptions:
- I work for a software company and we are bound by the requirements of our customer, usually including the programming environment. So, if a customer only has people knowing, say, MFC, we will make an MFC project. But this is becoming rarer and rarer. If we have the choice, we will go with .NET or Java.
- You have a team with expert people in these older technologies and they are quite productive with them.
There's plenty of work for people like you, so I'd advise not learning these for job purposes. We have some MFC apps, but that's partly because it's what we had and partly because we had more faith in C++ performance, and performance is very important for them.
I wouldn't call C++ or MFC antiquated, but there's relatively less new work in it. (I would very much like to never support another Win32 program, though.) The new C++ standard should be out in 200B, and people will continue to work on it, and Microsoft has been adding new classes to MFC, so obviously there's continued interest and continued work.
For professional development, I'd suggest you learn something different, but that would be something like Lisp or Haskell, rather than C++, and as far as I can tell there's no particular virtue in knowing MFC.
Realistically Microsoft forces business to use their latest and greatest technologies. There will always be work for someone who knows both technologies because someone has to port legacy code.
Many small devices (phones) or games require lighter solutions. If you intend to work in those areas you will definitely need those technologies.
You need to decide where you want to go. Once you have a map then you can lay in the right supplies for the journey.
I found Java horrendous to work with compared to Win32. Someone needs to cut about ninety percent of the inbuilt libraries.
I wouldn't call Win32 and such antiquated. As other people have said, it really depends on the app. As a game developer, I use Win32 less and DirectX a hell of a lot more. I could double or triple my Windows code, and it would still be an extremely small portion of the project.
However, if you're writing a primarily interface application with a relatively small and lightweight backend, .NET might well be a good choice for you.
As for Haskell, I just found that to be a truly terrible language in pretty much every respect. It seemed to me that it served some abstract mathematical definition of "functional", rather than a real definition of "programmable-in".
Win32 SDK is nowadays used in niche markets, where more modern technologies can't be used for some reasons (legacy Win32 systems, games, system drivers, Windows Embedded systems). If you aren't planning on pursuing a career on these markets, I wouldn't bother learning Win32 now. It is not that is useless and has no new things to teach you, but let's face it, there are so many new technologies coming out even at the time we speak. I have a dozen of technologies/languages in my waiting list to start learning and experimenting with. You can certainly find more interesting and more career favorable technologies to learn.
Performance critical apps (games) typically use C++ Win32 API.
C# and .NET are actually built on top of the Win32 API. To access some of the advanced features of Win32 that aren't exposed through C# and .NET you use Pinvoke to manually expose a C Win32 function to your C# app.
I'm looking to be able to build GUI applications quickly and painlessly as possible. I'm competent (though not expert, and have no formal training) in C++, but have never used a GUI building toolkit or framework or anything. I am not a professional programmer and am totally inexperienced and ignorant when it comes to building GUI apps. Have spent hours researching trying to figure out what to do; only getting more confused and discouraged though.
Qt and wxWidgets seem like the most popular options for cross-platform apps, though cross-platform isn't necessarily all that important to me; Windows-only is fine if that means the fastest learning curve.
Qt seems cool and the Qt Creator is sweet looking with lots of good demos, except it has its own classes for everything, and I'm not overly keen on learning a bunch of stuff that's only applicable to the Qt platform itself rather than more generally. I suppose I could avoid using the Qt classes except for the GUI stuff where I have to use them, but I have no idea how wise or unwise that would be.
I was thinking Visual Studio would have the smallest learning curve, but when I open a test GUI app, I see a bunch of foreign looking stuff like carats (^) all over the place - I found online that these mean "handles", which I have trouble even understanding the definition or purpose of ("sort of like pointers but not really" is basically how I've read people define them).
I know pretty much nothing about wxWidgets, or how it compares with Qt.
So every option has a big learning curve - and ideally I'd like to know which one minimizes the time you have to spend learning the toolkit/framework itself. Since I'm likely never going to be making money from the programs I create, the time I spend learning a specific toolkit would be pretty costly. I just want to be able to make a functional program using the C++ knowledge I have, but in GUI form. At the moment it seems if I want to make a GUI app, I'd have to spend way more time learning the GUI framework I'd use than writing the functional part of the app itself.
Any input from people wiser and more experienced than me would be appreciated :)
First and foremost, start simple. There's a lot to the subject. If you are finding it hard, don't try and take it in all at once.
Most of the good GUI packages have tutorials. The best advice I can give is that you try each of them, or at least a couple of them. They are the best short introduction you can have to the library you choose and if they are any good they narrow down what you need to absorb at first. That will give you some basis for comparison, because they are each trying to do very similar things (and you will see some of them before you are done), but they have different feels. You will likely find you have a preference for one and that's the one to get serious with. It will also give you a sense of what's hard about GUI programming as separate from the particulars of one package, which, if you have only used one, you won't have seen. Personally I find this sort of knowledge very helpful, because it makes me less intimidated by particulars.
Here's a list of tutorials in one place, though you have likely seen them already:
Qt's tutorial
WxWidgets' tutorial
Gtkmm book. Not quite a tutorial, though there are lots of examples.
.NET tutorials, either for WinForms or for WPF.
Second, it sounds to me that you need to get some in depth understanding of the concepts of GUI programming, not just a particular library. Here there is no substitute for a book. I don't know all of them by a long shot, but the best of the bunch will not just teach you the details of a toolkit, they will teach you general concepts and how to use them. Here are some lists to start with though (and once you have titles, Amazon and Stack Overflow will help to pick one):
List of Qt books
WxWidgets book (PDF version)
There are tons of WPF and WinForms books. I can't make a good recommendation here unfortunately.
Third, take advantage of the design tools (Qt Creator, VS's form building and so on). Don't start by trying to read through all the code they generate: get your own small programs running first. Otherwise it's too hard to know what matters for a basic program and what doesn't. The details get lost. Once you've got the basics down though, Do use them as references to learn how to do specific effects. If you can get something to work in the design tools, then you can look at particular code they generate to be able to try on your own hand-written programs. They are very useful for intermediate learning.
I'm not overly keen on learning a bunch of stuff that's only applicable to the Qt platform itself rather than more generally.
I second the comment of GRB here: Don't worry about this. You are going to need to learn a lot specific to the toolkit no matter which toolkit you use. But you will also learn a lot that's general to GUI programming with any of the decent toolkits, because they are going to have to cover a lot of the same ground. Layouts, events, interaction between widgets/controls, understanding timers -- these will come up in any GUI toolkit you use.
However do be aware that any serious GUI package is an investment of time. You will have a much easier time learning a second package if you decide to pick one up, but every large library has its personality and much of your time will be spent learning its quirks. That is, I think, a given in dealing with any complex subject.
I suppose I could avoid using the Qt classes except for the GUI stuff where I have to use them, but I have no idea how wise or unwise that would be.
You do not need most of the non-GUI classes of Qt to use Qt's GUI properly. There are a handful of exceptions (like QVariant) which you'll need just because the GUI classes use them. I found you can learn those on a case-by-case basis.
Which is the easiest to learn is really going to depend on how you personally learn.
Personally, I've found Qt to be the easiest to learn so far. The GUI classes are rather nice to use, but I've found the non-GUI classes to be excellent, making it easy to avoid a lot of common issues you'd normally get with a more basic API. The documentation is excellent, IMO, as are the books, the examples, etc. It's also being very actively developed, with a few new technologies coming in the near future (like DeclarativeUI).
I've found Visual Studio/Windows API/.Net to be a good bit more complicated to learn. The API documentation on MSDN is rather complicated and not really organized in a manner that I find intuitive.
I've tried learning WxWidgets a few times, but I've never liked the API documentation.
All this is just my personal experience, YMMV of course. I'd say just dabble in all of them and see which one takes you the furthest, it won't hurt to try multiple.
As a person who learned C++ through Qt, I can only say that they work very well together. C++ purists (like I have become) will find lots of things in Qt not to their liking (the moc preprocessor, e.g., and the continued absence of exceptions for error reporting), but looking back, Qt provided a very gentle introduction to C++ for me.
And if you're like me, you throw in a handful of boost libs in each Qt project, because we want to write "real" C++, not the softened thing Qt uses :)
I would suggest wxWidgets. To me, it's pretty intuitive and looks nice.
Code::Blocks was built with it, so check that out to see if you like the graphics.
There are also a slew of bindings for wxWidgets, such as wxPython, wxErlang, and others, so if you decide to switch off of C++, you can take wxWidgets with you.
I also use wxWidgets and use it all the time for Windows-only applications (the only downside is that wxWidgets is notorious for large .exe filesizes, which may or may not be a problem for you). I found it very simple to use from the start, especially when combined with a GUI designer (personally I use wxDev-C++).
I've never used Qt, so I can't speak to its simplicity, but I doubt the difficulty is on a vastly different scale than that of wxWidgets. However, what I can say is that no matter what API you use (wxWidgets, Qt, WinAPI, etc) your code will be "locked into" that particular platform, so don't worry if you feel that learning Qt will lock you into the Qt platform (because the same thing will happen with any of those APIs).
If you're working solely on Windows however, you may want to do a few simple programs with WinAPI first. That way you have a basic understanding of the lowest level of Windows GUI programming before you move onto Qt/wxWidgets. That said, if you're really into cross-platform programming, then don't worry about that and go straight into Qt/wxWidgets.
I can't intelligently comment on the learning curve aspect, but a quick survey of StackOverflow questions shows about twice as many Visual C++ questions as Qt questions. Probably means that there is a larger support group in place for Visual C++. Might make learning it a little easier if there are more folks to help out.
No matter what you pick, I am quite sure it won't be easy and painless.
Having said that, I know that in some schools they use FLTK because they consider it relativelly easy to learn. I have never tried it.
In my everyday work I use WTL which is as close to the system as it gets while still providing some level of abstraction over pure Win32. I am not sure if I would consider it easy to learn, though, especially given the lack of documentation.
I recommend codegear C++ builder (previously known as borland C++ builder) from codegear which comes with a 30 trial. The nicest thing about it is that the GUI provides you with components that you drop onto a form in a WYSIWYG fashion and make functional by adding code to handle the events it fires. It comes with a whole bunch of compontents out of the box and you can add 3rd party components to it too, like the awesome ExpressQuantumGrid from devexpress, or write your own. It's very powerfull if you know what you're doing but intuitive enough that a beginner can write a database CRUD application in about 20 lines of very simple code.
Since nobody has mentioned it yet, for the sake of completeness, have a plug for the Fox toolkit. This is the one I used last time I did any C++ UI work of my own volition. There are also binding for this to Ruby and Python (the latter being many years out of date, though).
In general, the choice of a toolkit for self-directed work comes down to personal preferences for
the layout manager style
the event handler registration style
How native the widget set looks/can be made to look
If cross-platforming is not necessary, try .net + msvs or delphi. easy, all-in-one, no pain.
Qt is the best option for you. It's the easiest to learn, the most elegant and powerful and it is completely free.
Visual C++: This is an IDE, but it comes with its own GUI library called MFC. MFC is an old library with many quirks and it is difficult to learn and use. Many C++ programmers use it on Windows because it comes from MS, it's fast and it's free if you buy Visual C++. Since VC++ is an IDE, you can also use wxWidgets and Qt with it, although in your particular case I would recommend Qt Creator instead.
You seem to have experimented with Managed C++. Don't use that, even MS recommends that you only use Managed C++ as glue between C++ and C#.
wxWidgets: This one was a strong contender up to the day when Qt became free for commercial projects. It was always in the shadow of Qt and it is known that the documentation is not very good and the API is not as easy to learn as Qt's. Cross-platform MFC would be a good way to describe it.
C++ Builder: Borland made too many mistakes with C++ Builder and ended up getting out of the dev tools business altogether. It was a good product and I originally learned Windows GUI programming in one of the first versions, but I won't use it any more. There are better options and it is too expensive.