Transition from non-visual to visual

Hi everyone... I'm a beginner in c++ and i work on console applications at the time. I'm actually more interested in visual programming. however my deitel & deitel book covers only non-visual c++. After i start feeling myself experienced enough, i will have a transition from non-visual to visual c++. Luckily I have Microsoft Visual Studio .NET where i can program both of those kinds. My question is, what do you recommend me about this transition, in terms of books, resources, or any tips and strategies?
Thanks

Don't use MFC and use wxWidgets instead. If you have to use Microsoft, still don't use MFC but use WTL instead.

Quote:

---

Originally Posted by NMTop40

Don't use MFC and use wxWidgets instead. If you have to use Microsoft, still don't use MFC but use WTL instead.

---

Can you explain why are you advising against using MFC?

MFC forces you to link in the MFC libraries, and they don't mix with some of the other runtime libraries, which means that everything you link in must be MFC-friendly even when it has nothing to do with anything Windows related.

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

MFC is also totally a pain to use, and is in any case being phased out in place of .NET which means adding Microsoft extensions everywhere. 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? And why doesn't compiling a resource file generate C++ source for you?

There are very few sources on WTL. Could you suggest a good book or tutorial (besides the ones on this site) on the subject?

Are you sure it is windows non-related at all ? MFC although still contains several weaknesses in its implementation design but truly no other frameworks have so far appeared to show they are any better, and that this framework is a true windows-based one. But surely, newbie with API will misunderstand what you said...
Their .Net is better, isn't it ?

Ok I will tell you what might be non-Windows related.

Suppose I have a long process that I want to do. The process itself has nothing whatsoever do to with Windows, and say I write an app or classes etc to do it.

Now suppose I want the following:
- A small GUI to configure the process that will be done
- A progress bar to show the progress as part of the GUI.

So I will want to link the non-Windows code into the Windows code. (By the way, anyone implementing such an app, ensure you do the processing in a separate thread).

Now suppose that my "processing", for example, is going to be a musical device that plays mp3s. So I might want to have a menu to load mp3s into my player and play them. But I don't really have any need whatsoever for a CDocument class (do I?). I might want to be able to queue up several mp3s, so hey, is it a multi-doc/view app or a single doc-view app? No, I have one view and multiple files, and I'm not going to edit them.

As for whether .NET is better, maybe, but it's really based around writing C# in different flavours. I guess if there's something in favour you can probably easily link in "unmanaged" C++ (i.e. normal C++ with no extensions) into "managed" C++.

I think mfc is a framework created to meet different people's general need whereas what you are trying to prove is solely based on your own specific demand. I have heard a lot about mfc common base object's bad design leading to loading a bunch of unnecessary libraries, which i think is not far away from what you have just described.
Plus, there is actually no standard out there for GUI application designs like the one for C++, and that is why, also.

However, there are still a lot of other frameworks like ACE, coral, QT etc, and many libraries for one to link and make her/his own framework that suits her/his need, specific design.

i see there is a hot conversation going on here but can you also comment on my question as well? :D thanks

My comment: try and see for yourself. Then forge your own opinion ;) :p

trying without knowing anything would be just a waste of time.. i think i need some assistance...

There are plenty of toolkit/APIs for doing GUI design, MFC and .Net are just two examples that MS put together. There are toolkits intended for platform independance as well as toolkits specific for a certain OS/windowing system. You need to be sure you know what you want, your question is a bit vague and open ended, hence the 'non-informative' replies.

trying without knowing makes you know ;)

that's called learning... and programmers do that a-plenty! :p :thumb:

i do it too. however it didn't work out when i tried it on visual c++. I just got lost. How can i learn to put a picture inside a rectangle if i don't even know how to draw a rectangle? So, i'm expecting some resources that might help me.

NMTop40
I have no idea what are you talking about... Yes, MFC doesn't provide you some exotic patterns, but you can develop required logic independant from MFC. There is no need in changing anything in non-MFC code. You can easily add some controlling&playing windows - as you pointed out without taking direct advantages of MFC way of doc/view if your code classes have different logic. But it's the same way for all but the one environment which is compatible with your programm, or so it seems from your explanation. In fact it's good to develop most of the code system-independent, in this case MFC-independent.

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

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

Quote:

---

Originally Posted by Runt888

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.

Quote:

---

Originally Posted by wien

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.

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

Quote:

---

Originally Posted by Smasher/Devourer

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

Quote:

---

Originally Posted by NMTop40

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? :confused:

Quote:

---

Originally Posted by NMTop40

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.

Quote:

---

Originally Posted by NMTop40

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

Quote:

---

Originally Posted by NMTop40

which means adding Microsoft extensions everywhere.

---

What "Microsoft extensions" are you talking about?

Quote:

---

Originally Posted by NMTop40

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.

Quote:

---

Originally Posted by NMTop40

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.

Quote:

---

Originally Posted by gstercken

Which other runtime libraries would that be? :confused:

---

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

Quote:

---

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.

Quote:

---

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.

Quote:

---

What "Microsoft extensions" are you talking about?

---

I think I was addressing the .NET issue here.

Quote:

---

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.

Quote:

---

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

Quote:

---

Originally Posted by NMTop40

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! :eek: :eek:

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 :rolleyes:

Quote:

---

Originally Posted by stober

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

---

http://wtl.sourceforge.net/

Quote:

---

Originally Posted by NMTop40

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.

Quote:

---

Originally Posted by NMTop40

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

Quote:

---

Originally Posted by NMTop40

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

Quote:

---

Originally Posted by NMTop40

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.

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.

Quote:

---

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.

Quote:

---

Originally Posted by NMTop40

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.

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.

Quote:

---

Originally Posted by darwen

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

Quote:

---

Originally Posted by darwen

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

---

Exactly. MFC might not be a textbook example for perfect OO design - but it serves it's purpose very well: Creating real-world applications.

Quote:

---

Originally Posted by darwen

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.

---

If you mean the managed extensions from VC++ 7.x here, you're right. However, with C++/CLI and VC++ 8.x, things will change notably. As for C#: Microsoft is currently positioning it against Java as a rather "academic" language - with C++ remaining the language of choice for real-world, industry-strength applications.