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
Re: Transition from non-visual to visual
Don't use MFC and use wxWidgets instead. If you have to use Microsoft, still don't use MFC but use WTL instead.
Re: Transition from non-visual to visual
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?
Re: Transition from non-visual to visual
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?
Re: Transition from non-visual to visual
There are very few sources on WTL. Could you suggest a good book or tutorial (besides the ones on this site) on the subject?
Re: Transition from non-visual to visual
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 ?
Re: Transition from non-visual to visual
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++.
Re: Transition from non-visual to visual
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.
Re: Transition from non-visual to visual
i see there is a hot conversation going on here but can you also comment on my question as well? :D thanks
Re: Transition from non-visual to visual
My comment: try and see for yourself. Then forge your own opinion ;) :p
Re: Transition from non-visual to visual
trying without knowing anything would be just a waste of time.. i think i need some assistance...
Re: Transition from non-visual to visual
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.
Re: Transition from non-visual to visual
trying without knowing makes you know ;)
that's called learning... and programmers do that a-plenty! :p :thumb:
Re: Transition from non-visual to visual
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.
Re: Transition from non-visual to visual
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.