freehackers.org: Qt vs MFC

Friday, 2 August 2002  |  Numanee

For those of you not yet convinced of the evils of the Microsoft Foundation Classes (MFC), Philippe Fremy presents the English version of an article by Pascal Audoux that pits MFC against Qt. "The [Qt] architecture is a good object-oriented one and was obviously intelligently designed. The result is a toolkit very consistent regarding naming, inheritance, class organisation and methods. Method arguments are the ones you want to supply, no more. They always come in the same order for different classes. And the return value is logical. Everything is powerful and simple at the same time." I also found this old comparison of Qt to Java (see this one too) rather interesting.

Comments:

Im surprised this was posted - anonomous monkey - 2002-08-02

This was in the slashdot developers section a while ago, and most people agreed that the quality of the article is very poor. Although I don't think anybody disagreed with the conclusion that Qt is much better to develop with than MFC, there was also an agreement that the article was of little value. They don't even try to find any advantages to MFC at all, and some /. comments suggest that the author doesn't have all of his facts about MFC correct. Maybe the writing quality suffers a great deal in the translation, but basically, if you want to skip reading the article, here is a summary: Qt's [feature X] is soooo great and implemented in a uber-intelligent way. MFC's [feature X] is implemented in a hairbrained fashion and is ridiculously hard to use (or alternatively, MFC doesn't have [feature X] so Qt is so leet!) Repeat Chorus

Re: Im surprised this was posted - ac - 2002-08-02

That is what it says in the first paragraph of the article. It is still interesting to some.

Re: Im surprised this was posted - Eric Laffoon - 2002-08-02

Of course if you do read the article the auther makes most of these points in a disclaimer that he is not a professional writer and English is his second language. He doesn't claim to be objective and simply referrs to his experience. Here is part of his closing which references the "not finding anything good" about MFC. "Some people complained that this article is biased toward Qt and does not present any MFC advantage. This is simply our experience : we had tons of problems with MFC, and almost none with Qt. Programming with Qt was always simple, documented and efficient. If MFC has good points, we have not found them, apart from being delivered free with Visual Studio." Then again I guess there are some people who will simply let /. do their thinking for them. If they say the article is of little value the question is to who? To you? It's not of value to me as I can't and wouldn't (if I could) use MFC on Linux. It might be of value to a shop using MFC.

Re: Im surprised this was posted - Ronny - 2002-08-02

This isn't a good defense for this article. If the author isn't a professional writer and especially if he's not objective he shouldn't write a comparison article. I did not let /. do my thinking, because I didn't even notice the posting there (only on freehackers.org). When I read the article it didn't seem to be a comparison at all, this was plain and simple Microsoft / MFC bashing. One of the authors 'best' arguments is about MFC's document/view model. He claims you can't nearly program without it... Of course not! If you let all work do the AppWizard.... I've written quite a project using VC/MFC, without document/view (and no, it wasn't just a dialog application). In fact, the document/view model comes in very handy some times. And btw., i'm not a Qt expert, but I think Qt doesn't even have something like that.... I'd say: If you want to write a comparison article between two products (even if you're biased towards one of them) do it fair. Explain where and WHY one feature is better than another.... Cheers,

Re: Im surprised this was posted - altrent - 2002-08-02

"If the author isn't a professional writer [...] he shouldn't write a comparison article." Good point, I would also suggest that only professional posters should post to this forum...

Re: Im surprised this was posted - Greg Fortune - 2002-08-03

Isn't that just begging for the trolls :o)

Re: Im surprised this was posted - Eh? - 2002-08-04

How hard is it to implement your own Document/View model? It's just a matter of seperating the backend and the frontend logically within your code, which is a good design practice anyways...

Re: Im surprised this was posted - James Richard Tyrer - 2002-08-05

<<It's not of value to me as I can't and wouldn't (if I could) use MFC on Linux.>> Are you certain that you can't use MFC on Linux? Has anybody tried doing this with WineMaker? -- JRT

Re: Im surprised this was posted - Ax - 2002-08-03

> Im surprised this was posted Well, I'm not. Because this is a site about KDE. And as you know QT is part of it. Every reader can judge for himself.

Re: Im surprised this was posted - Joshua - 2002-08-05

Hear, Hear! While I know nothing of developing in either environment, from one who reads alot (especially technical publications), the article is very poorly written and is [typically] biased. This isn't an 'us' and 'them' issue, people.

Talk, talk, talk ...:) - asoneofus - 2002-08-03

The Talks, let's discuss with arguments: than good library Qt and than bad MFC. Regrettably, MFC used long ago and much little, but impressions were not bad. Qt - use presently, naturally, better no.

MFC is realy as bad! - Emmeran Seehuber - 2002-08-03

Maybe the author of this article is wrong in some points (e.g. you can program MFC without using it's Document/View model), the overall summarision is right. MFC has realy some bad drawbacks: - The message routing of the windows messages is realy bad designed. Depending of what controls you use, which container control and what styles set, the messages get delivered through different mechanism. (E.g. the parent gets a child notifcation message, the control gets the message directly, and so on). - Ever had some problems not recieving messages or some redraw problems? Try setting the right style combination. This can be tricky since the styles of the parent control matter also (E.g. building own property pages using a tabcontrol. It is much fun to embend other resource dialogs ...) - As stated, the documentation is very poor. - Derivation of controls is not good supported. You can of course derivate from e.g. a CEdit control and create your own CMyEdit. There you can also override some methods or catch messages to implement an own behavor. But if you use resources to create dialogs and want to use your own CMyEdit control instead the CEdit you have to detach the MFC-CEdit object from the Win32 API windows control and then attach your (own created CMyEdit instance) to the Win32 API windows control. - Translation of MFC programs in a Qt like way is possible -- just create your own translation tools ... ;) The problem with the layout remains. Some things got realy better with the "new" ATL library. But this library is more a toolkit then a framework, and does not feature such things like MDI-Frames or a MVC. The real problem is not the MFC -- its the Win32 API. And .NET WinForms is therefor mostly also as bad ... (The wizzards/designer for WinForms are much better than MFC one, also WinForms supports dynamic layout just like Qt, but you can't effectivly derivide from a WinForms control and change it's behavor without playing with Win32 API WindowProc .... -- don't even think about being able to run this in mono ...) cu, Emmy P.S.: English is also not my native language. So please forgive me for my wrong english ;)

Re: MFC is realy as bad! - Jörgen - 2002-08-05

<i>WinForms supports dynamic layout just like Qt, but you can't effectivly derivide from a WinForms control and change it's behavor without playing with Win32 API WindowProc .... -- don't even think about being able to run this in mono ...)</i> *Cough* Bullshit *Cough* Have you ever even tried WinForms?

Re: MFC is realy as bad! - Jean-Marc Molina - 2003-10-25

Hi, Can you provide us with the article URL ? I searched for "MFC is realy as bad" and only found your post. Besides your english is pretty good, maybe I say that because of my french genes :) Thanks, JM

uh, I love QT as much as the next KDE guy, but... - AC - 2002-08-03

Matthias Kalle Swing vs QT is really far from being objetive. One part that really bothered me is when he gives some code examples: whenever Java code takes more lines than C++/QT code for the same functionality, then QT is better because the code is "more intuitive", and when whenever C++/QT code takes more lines, then he explains C++/QT is better, because the code is "more flexible". Biased at its best. Comparing C++ to Java, he also says that Java's big standard API is a problem, because it is hard to find things on it. I don't agree, since Java packaging is well done, and classes are, as in QT, consistently designed, finding something in it is not really hard. I *suspect* it might be easier to find something inside the JDK standard API, than having to look for it everywhere, when you dont find it in the QT API. (And I have to say that 95% of all I have ever needed *is* provided by the QT API.. Oh no!!! QT API is BIG, now I wont find anything...!!). The only 2 reasons I have to prefer C++/QT over Java for GUI aplications are performance and "look and feel". Well, those are HUGE reasons :), but I find it silly to ignore the fact that some stuff as GC actually reduces development time. Kalle quotes some studies showing how for the same task, experienced C++ programmers took less time than experienced Java programmers. I take that study with a grain of salt. I wonder how "experienced" in java the java programmers were compared to the C++ programmers (given that this document is supposedly a bit old, and java is not too old)

Re: uh, I love QT as much as the next KDE guy, but... - Navindra Umanee - 2002-08-03

I haven't read the paper, but I do agree that the Java API, at least that part of it that I've used, is very well done and well-documented. And worse comes to worse you have rt.jar and could look at the source. That comes in mighty handy. Of course, now Java has tons of libraries (CORBA/RMI stuff and all that) that look mighty complicated, but they've never bothered me. I've programmed in AWT before and found it fairly nice. Unfortunately, it looks like and performs like crap.

Re: uh, I love QT as much as the next KDE guy, but... - Sad Eagle - 2002-08-03

Well, one actual problem with Java API, though, is that you get all sort of old vs. new generation classes (I certainly understand why Sun did this, and if I was in place of their engineers, I'd likely do the same -- this is the disadvantage of something being a platform and not a library, in a way)... Take for instance AWT vs. Swing; or the Java1 style Streams vs. Java2-style Readers and Writers vs. Java 1.4 new I/O.. The same with containers, to smaller extent... And further, I am not sure whether they are really consistently designed -- for instance AWT is rather minimalistic, while Swing has a whole lot of complexity for the Model/View separation (which despite looking nice on paper, I haven't found all that much use for, although my GUI programming with Swing experience is rather minimal).

Re: uh, I love QT as much as the next KDE guy, but... - Joachim Sauer - 2002-08-12

Well, ACK, but you should mention 2 things: - not using awt is simple, when designing Swing-Applications - NIO is not a replacement for readers/writers, but a special case for extremly I/O-Intensive applications (that is apps that need the java-equivalent of mmap-ed files (be it files on the harddisk or even access to the graphic cards memory). The Model/View seperation in Swing is extreme, but once you got the hang of it you really find it much easier to write a new Model than to use the kind of workarounds you use when starting to write Swing-Apps (everyone does this, I've never seen anyone start writing Swing code who used custom Modells first).

Re: uh, I love QT as much as the next KDE guy, but - Alex. - 2002-08-04

"The only 2 reasons I have to prefer C++/QT over Java for GUI applications are performance and "look and feel". Well, those are HUGE reasons :)" Right, one more thing: Collection classes. QT provides very powerful, efficient and easy to use classes while Java has what? (Hashtable?, Array? - Come on..) Even more, if you go class by class, QT's equivalent is usually more powerful. Example: look at Java's String vs QString. So if you talk about GUI-only application, add platform Independence and QT seems to bit Java to the ground. And yes I love Java, it is my day job. My 2 cents.

Re: uh, I love QT as much as the next KDE guy, but - AC - 2002-08-04

What is wrong with the java collections framework?

Re: uh, I love QT as much as the next KDE guy, but - Navindra Umanee - 2002-08-05

I like it myself, although it lacks templates. No idea what the original complaint is about though.

Re: uh, I love QT as much as the next KDE guy, but... - TCorbin - 2002-08-04

As for look and feel, there are several great jar files which allow you to greatly improve the look of java applications. Sun's "swing sightings" pages show a lot of good looking swing apps. As for performance, it could certainly be improved. On the other hand, with java 1.4 it's not too terrible anymore. We're developing a complex mapping application from scratch in java, mapping thousands of objects on the screen with huge reaster backdrops, lots of panels to edit map entities. And it's all working quite well as far as performance goes. Another poster mentions java's collection classes. Once they added the new collections api, the collection tools improved a lot. Now all that's missing is templated collections.

While I like Qt, - Sashmit Bhaduri - 2002-08-05

I think comparing Qt to Microsoft ATL/WTL (which is a lot nicer than MFC), or comparing Qt to .NET would be much better. MFC is old hat, having existed for many years, and while many people have invested a lot of coding time and money in it, even Microsoft has gradually moved away from it, starting with ATL/WTL, and culminating in .NET

Re: While I like Qt, - anonymous - 2002-08-05

Then do it yourself! And tell it to the thousand companies programming in MFC only!

Re: While I like Qt, - John Gustafsson - 2002-08-06

How about a comparison of two C# APIs? Or why not all three? GTK# (I feel baised here and says *yuck*), GDI+ (I like it, it is easy to use and powerful, much better than MFC), and the newest addition QT#. All three wrap another API (GTK, GDI/Win32, QT) in some ways and all three uses the same programming language. This would make it easier to write the same software with three different graphical frontends, which would give you an ok chance to evalute them further than just discussion the APIs. Also, don't forget that QT was written as a reaction to APIs such as Motif and Win32/MFC. While QT is not perfect it has the advantage of being written from scratch and having a huge giant's shoulder to stand on. This is progression, we like it, I am sure QT will feel like motif in 10-20 years and young whippersnappers (sp?) will pit future systems against each other and call the users of the "other" system morons;)

Qt, .Net, whatever - Joshua - 2002-08-05

Boy, folks really love their opinions, don't they;-)

Re: Qt, .Net, whatever - Florian W. - 2002-08-07

Hi! That's just a theory. Sometimes I think, that making a decision is a kind of art. There are a couple of ways to do things, and you express yourself in choosing one. And as more you move forward inside your decision, it's hard for you, to take the other way. So I am loosing more and more mental flexibility and I'm loosing the ability to accept that other people make other decisions. And by the way: I hate the QT especially the signal/slot stuff - that's my decision. Regards,.

Agree 100% with article. - maged mokhtar - 2002-08-07

Hello all, I agree 100% and more with the article. I have been programing for many years, always considered talented wherever i worked. I used MFC for 8 years and produced good looking apps with it. I also read nearly every book on it [ including buying multiple versions of the same book ] and studied its internals [ i almost knew by heart the Shepherd/Wingo internals book ]. I could tell you : 1] When i started to use Qt, in 2 [ TWO ] weeks i could do more with it and in significantly less time than MFC. 2] All the developers around me who had experince in MFC were shocked by how easier and more powerful Qt was. 3] The author of the comparison article knows what he is saying, the critic on MFC drawbacks are all valid [ i can even name some more, even nastier pitfalls] The facts are : 1] whoever doubts the article has not used Qt [ maybe not even MFC ] to prove me wrong, i need to see 1 [ one ] developer who used both MFC and Qt and thinks MFC is better or more productive. 2] I believe strongly that MFC was designed by inexperienced developers who knew very little about object oriented design when they started [ and finished ] the library. The fact MFC gained market support was entirely due to MS and not to any technical merit. There is no doubt in my mind that the Qt developers are talented developers. 3] i also believe anyone who claims MFC is good OOP design or is powerful framework is an inexperienced programer.

Re: Agree 100% with article. - Robert Björn - 2002-08-14

I don't think anyone really thinks that MFC is more elegant or better than QT, but there were some inaccuracies in the article that needed to be addressed.

Is this Flame Bait? - Rob Howard - 2002-08-08

Come on, has nobody here written MFC apps seriously yet? This article is so full of errors, misunderstandings and pure opinion that I can only assume it's an anti-MFC troll. Writing an MFC app without the document/view architecture is trivial. Message passing and the signal/slot mechanism for programme flow control are equally valid, with only personal preference to choose between them, really. The same goes for the means of laying out UI; Having seen some of the monstrously bad interfaces produced in Java, Qt _and_ MFC I know that whether controls are fixed in place or located dynamically in a window you can still completely muck it up. The comments about documentation are hilarious. MSDN is an excellent resource, comes on 3 CDs or 1 DVD (where did that "10 CDs" come from?,) is supplied free with the MS IDEs and is free online, anyway. Sorry if this seems to be a flame but I don't intend it to be that way. I'd love to see a well-written and accurate comparison of MFC and Qt, but this article doesn't come close.

qt - maged mokhtar - 2002-08-09

>> Come on, has nobody here written MFC apps seriously yet? yes i have written tons, including taking part in one that could very well be the largest MFC app. it was a direct competitor to an MS product. They were smart, they did not use MFC, we did. >> Writing an MFC app without the document/view architecture is trivial. o From the Book "Professional MFC with Visual C++5" by Mike Blaszczak who was a lead developer in MS's MFC team. page 191 : Title : Document View-When not to use : "The Microsoft Foundation Classes are designed to address the issues faced by most developers in most of their projects. It therefore follows that the majority will find them useful, but may not fit every situation perfectly. Some of these situations require you to abandon the idea of using the document / view aechitecture..... In all candor, you may wish to avoid MFC completely for projects such as these, restricting yourself to stock C++." o In Qt to create a splitter with 2 panes you do like this : splitter = new QSplitter(this); leftWnd = new QLeftWndClass(splitter); rightWnd = new QRightWndClass(splitter); No big deal, all very logical. Now please show how you do these 3 lines in MFC without doc/view. You can not, you will fail miserably and this is guaranteed [ correct me with code if you wish ]. Even after conceding to using doc/view for this there is also a trick to get the right pane different than the left. first you need to define the doc-frame-view template, using only one of the view types [ even a bogus type will do ] CSingleDocTemplate* pDocTemplate; pDocTemplate = new CSingleDocTemplate( IDR_MAINFRAME, RUNTIME_CLASS(CMyDoc), RUNTIME_CLASS(CMyFrame), RUNTIME_CLASS(CMyLeftView)); AddDocTemplate(pDocTemplate); This template binds the doc-view-frame types in one template. The frame will use the view class defined in this template to create the view. If left as is this will create the left view only in the frame. To create the splitter we fool the process by over-riding the frame's OnCreateClient() and create whatever we wish. BOOL CMyFrame::OnCreateClient(LPCREATESTRUCT lpcs, CCreateContext* pContext) { // // Note: Create the CFileView first so the CDriveView's OnInitialUpdate // function can call OnUpdate on the CFileView. // if (!m_wndSplitter.CreateStatic (this, 1, 2) || !m_wndSplitter.CreateView (0, 1, RUNTIME_CLASS (CMyRightView), CSize (0, 0), pContext) || !m_wndSplitter.CreateView (0, 0, RUNTIME_CLASS (CMyLeftView), CSize (192, 0), pContext)) return FALSE; return TRUE; } So not only did we have to use the doc-view for such a simple thing. We had to fool the view creation to bypass the view defined in the doc template. If you think think is a mess, you are right. Yack !!! o Even the most primtive UI framework should support scrolling windows. Can MFC support a scrolling window ? Ehhh No. You have a CScrollView so you have to use Doc/View. Try using a using a CScrollView inside a CDialog and not CFrameWnd, it will crash when you mouse click anywhere in it. It's mouse activation event is handled in a very clever way : walk up to the CFrameWnd parent and assign this view as the "active view" of the doc-view-frame template. No CFrameWnd parent .. bye bye app. Using a CScrollView inside a CFrameWnd without a doc template is also non-trivial. Requires "MFC internal knowledge" : In the first version of Prosise's MFC "Programming Windows with MFC" book shows how like this : pMyView->Create (NULL, NULL, WS_CHILD | WS_VISIBLE, CRect (0, 0, 0, 0), this, AFX_IDW_PANE_FIRST, NULL); the "knowledge" is in assigning AFX_IDW_PANE_FIRST child ID to the view. This hack was not in his second version of the book. o Also assume you have a simple view that goes into a splitter or into a frame, assume you wish to do a very simple thing like add a header label on top of the view [ like a label with a title of "Folders" on top of a cTreeView ]. How do you do this in MFC ? the splitter needs a RUNTIME_CLASS of a single thing that it fits, should we create a new view type that houses the lablel and the cTreeView ? In this case all the doc-view messages go to the wrapper view, how do we route the messages to the CTreeView ? o Dialog Controls are also handled in a very ugly way. for example to get text from an edit control we either use something like : CEdit* pNameCtl = (CEdit*) GetDlgItem (IDC_NAME ); pNameCtl->GetWindowText (m_text); We also have to be careful : the pNameCtl pointer returned is valid only during the processing of the message and cannot be saved and used later ! another way is add the following macro inside DoDataExchange() DDX_Control(pDX,IDC_NAME,m_NameCtl ); though i have no problem using any number of macros, i find these macros less elegant than simply using old style C SDK programming the Charles Petzold way. and certainly ugly compared to the logical : pNameCtl = new QEdit(this); o The CFont class is a classical show of MS C++ knowledge, can you imagine the CreateFont() functions takes 14 paramaters and none have default values, you have to specify all of them like OUT_CHARACTER_PRECIS, DEFAULT_QUALITY. are these C++ experts creating us the library to use ? >> Message passing and the signal/slot mechanism for programme flow >> control are equally valid, with only personal preference to choose >> between them, really o not really, in Qt you can assign any object to receive messages from any other object. you can have many recipients of the same message event. You have total flexibilty. In MFC in non doc/view, the control sends to its parent window, in doc/view ...YACK forget about that. >> The comments about documentation are hilarious. MSDN is an >> excellent resource.. o true, MSDN is an excellent resource but the MFC docs is a very small part of it and very badly done. o As for saying the Qt should be compared to C#. Not really, .NET is a new technology. Qt is a regular C++ framework the MFC developers could have very well produced something like it back then. As far as being unfair comparison, that is true, it is like comparing a jet fighter to a biplane. ..don't forget to call "delete this;" in PostNcDestroy() of your Cwnd's derived classes. ..keep implementing those IMPLEMENT_DYNCREATE() Bye now,

Re: qt - Rob Howard - 2002-08-09

>> yes i have written tons, including taking part in one that could >> very well be the largest MFC app. Sorry, the article was such an unjustified anti-MFC diatribe I presumed you had limited experience. > >> Writing an MFC app without the document/view architecture is trivial. >> From the Book "Professional MFC with Visual C++5" by Mike Blaszczak >> who was a lead developer in MS's MFC team. page 191 : Try a Dialogue box-based app, which doesn't have document-view. Alternatively, create an SDI app and rip out the document-view part. I've done it plenty of times, so I know it to be possible. True, MFC isn't for everybody. I usually use ATL, because you end up with much lighter applications. >> In Qt to create a splitter with 2 panes you do like this : That's hardly an MFC problem, is it? Why should MFC cater for every way of writing a UI? Why not write your own class which creates a splitter? This is hardly a fair point. I could say something like "you can't create COM controls easily with Qt" and it would be an equally unfair comparison. >> Even the most primtive UI framework should support scrolling windows. Just how much code you have spoon-fed to you is indeed a matter for philosophic debate. >> Can MFC support a scrolling window ? >> Ehhh No. You have a CScrollView so you have to use Doc/View. I suppose a CScrollView isn't a scrolling window, then? :) >> Try using a using a CScrollView inside a CDialog and not CFrameWnd, >> it will crash when you mouse click anywhere in it. Any fool can write broken code. Why put a CView-derived window where it isn't meant to go? Scrolling dialogue templates would be no good thing IMHO and, if you want a text area which scrolls, use a CEdit-derived window. >> Using a CScrollView inside a CFrameWnd without a doc template is >> also non-trivial. It's true that, whereas MFC is designed to make easy jobs easier for people new to Windows programming, some things are better done if you have in-depth knowledge of the underlying system. I hope that, as an experienced Qt programmer, you understand its architecture (along with the underlying X-Windows system) inside-out. >> Also assume you have a simple view that goes into a splitter or into >> ...should we create a new view type Why not? It _is_ a new type of view, after all. >> In this case all the doc-view messages go to the wrapper view, >> how do we route the messages to the CTreeView ? Fortunately, MFC handles routing of unhandled messages down to the base class for you! >> Dialog Controls are also handled in a very ugly way. .. >> We also have to be careful : the pNameCtl pointer returned is Congratulations, you've discovered what the scope of a variable means. >> i find these macros less elegant than simply using old style C SDK programming >> the Charles Petzold way. Again, a matter of taste. I prefer to hit the Win32 API directly sometimes, but MFC can make things so much easier. BTW, haven't you discovered the "Member Variables" tab of the class view yet? >> The CFont class is a classical show of MS C++ knowledge, can you >> imagine the CreateFont() functions takes 14 paramaters and none have >> default values, you have to specify all of them like >> OUT_CHARACTER_PRECIS, DEFAULT_QUALITY. are these C++ experts creating >> us the library to use ? Of course, all API calls should come with built-in mind reading so that they can tell exactly what you want! Microsoft's font engine is pretty powerful and has a lot of knobs to tweak, if you want to. You don't have to use CreateFont if you don't want to, though. >> In MFC in non doc/view, the control sends to its parent window, >> in doc/view ...YACK forget about that. You pays your money, you takes your choice. Whichever way you know best will seem to be the correct one. Don't flay MFC with your own opinion. >> true, MSDN is an excellent resource but the MFC docs is a very >> small part of it and very badly done. Piffle.

Re: qt - maged mokhtar - 2002-08-09

>> That's hardly an MFC problem, is it? Why should MFC cater for every way >> of writing a UI? Why not write your own class which creates a splitter? >> Just how much code you have spoon-fed to you is indeed a matter for >> philosophic debate. i just gave 2 examples : scrolling window and splitter, i thought are basic elements any simple ui framework should provide. If you feel these were unfair to expect from a framework, no problem i'll type some other examples later. Note that MFC does provide those when using doc/view which was the original discussion. Also the ugly code i mentioned for creating 2 different views for the splitter is not my hack, it is found in any MFC reference or book that explains the splitter class. This is "official" MFC code. >> Any fool can write broken code. Why put a CView-derived window where it >> isn't meant to go? i was just trying to prove the point that the scrolling support in MFC cannot be used outside the doc-view model, so we both agree here. >> if you want a text area which scrolls, use a CEdit-derived window. i meant a scroll area for a custom window you write [ one that you derive from CScrollView or QScrollView ]. >> I hope that, as an experienced Qt programmer, you understand its architecture >> (along with the underlying X-Windows system) inside-out. my experience in Qt is not great, but in 2 weeks i was more capable with it that my 8 years of MFC. I also know zero X-Windows, yet my Qt code ran flawlessly on both Win32 and Linux. >> Why not? It _is_ a new type of view, after all. >> Fortunately, MFC handles routing of unhandled messages down to the base class for you! you miss my point : this new view is just a wrapper that includes the label control and the original CTreeView derived view [ the real view ], ie we have 2 views. The problem is that MFC will treat the wrapper view to be the one associated with the document. So we have to write code ourselves to route message from-to the wrapper to the real view. >> Congratulations, you've discovered what the scope of a variable means. this has nothing to do with variable scope, it has to do with an MFC screw up that the (CWnd*) pointer returned from (CWnd*) GetDlgItem (); is valid only during a single event handler. Storing this value into a global variable and using it in a latter event will crash. The "wisdom" behind it is that these object pointers are put into a temporarymfc CWnd-HWND hash map that gets cleaned peridically. Thank you MFC ! >> BTW, haven't you discovered the "Member Variables" tab of the class view yet? yes this is what generates the : void CMyDialog::DoDataExchange(CDataExchange* pDx ) { ... DDX_Control(pDX,IDC_NAME,m_NameCtl ); } which i mentioned in my earlier message, i have no problem using these lovely macros and exchange contexts, i just said that i feel regular C / SDK looks cleaner and certainly Qt's logical : m_NameCtl = new QLineEdit(this); is cleaner. >> Microsoft's font engine is pretty powerful and has a lot of knobs to tweak, if you want to. i am not complaining about the Win32 font engine, it is excellent, it could have as many params as it wants. My complaint is the MFC design of the CFont class requiring you yo specify all these params and not making use of C++ feature of specifying default params, this is C++ 101.

Re: qt - gav wood - 2002-08-28

i've used mfc a fair amount and qt a lot. i've also used atheos's framework code, done some heavy hacking on the jx framework and learnt gtk/gnome. this is in addition to designing my own oo app framework/guis a while back. qt is the easiest and most powerful i've used. jx is a very close second - well designed and useful. it uses plenty of the OO functionality C++ ; atheos's gui framework is also rather nice. simple and lets you get the job done with the minimum of fuss. gtk--/gnome-- arn't amazing - but lets face it they're wrappers, so they live upto basic expectations. mfc is, quite simply, bollocks. it only barely passes itself off as an "object orientated" gui framework. some of it doesn't even work to spec (afaik - i specifically the serial port interface was shafted). my personal big time gripe: why the hell do the designers not use default parameters? they wouldn't take away functionality that's for sure. have they not heard of them? maybe m$ are in kahoot with the keyboard manufacturers and all those extra keystrokes will cause extra keyboards to be bought - who knows? i guess they got the random 14 yo kid there on work experience who had a vague idea what classes were and how to translate from stucts{} and function(struct *, ...). i just gotta say for the record, in my experience mfc sucks. big time. i haven't read the article, but assuming it says a similar thing, fair enough ;)

mf c - maged mokhtar - 2002-08-09

o One more MFC classic. In SDK C programing, when dealing with painting code, care is needed to cleanup and deselect GDI objects we selected in the DC (device context) and restoring the DC back after we finish. This was a common error that had nasty effects. When i started to use MFC, i was certain the MFC classes will take care of traking these resources and doing the needed cleanup. Any KID who read the BASICS of C++ will realize the classes should take of this. unfortunately the MFC graphics classes : CDC, CPen..etc do nothing more than the native handles HDC, HPEN they supposed to represent. The code is exactly like using native C / SDK like : CPen pen (...); CPen* pOldPen; CBrush brush (..); CBrush* pOldBrush; pOldPen = pDC->SelectObject (&pen); pOldBrush = pDC->SelectObject (&brush); .. drawing code here pDC->SelectObject (pOldBrush); pDC->SelectObject (pOldPen); This is in-excusable. specially incorrect cleanup was known as a common programming error. Surely the CDC class could have kept a flag of what was selected, what is the old value to use when deselecting, and keep pointers from objects such as CPen,CBrush,CBitamp to their CDC, so whoever goes out of scope the cleanup shuould be automatic.

Re: mf c - Rob Howard - 2002-08-09

Careful there old chap, you're foaming at the mouth. Yep, CPen and CBrush are thin wrappers around Create(Stock)Object and SelectObject. It would have been much nicer for CDC to keep track of what had been selected, then do a restore at the end. It would have made life easier. I'm glad if Trolltech were able to build on Microsoft's work and produce a simpler version, with the benefit of not having backward-compatability to think of.

another code comparison - maged mokhtar - 2002-08-10

Here is another example bewteen Qt and MFC code that involves the use of tree view control. /******************************************************* * 1 View creation ********************************************************/ Qt -- QListView* treeview = new QMyTreeView(this); treeview->setRootIsDecorated(true); MFC --- CSingleDocTemplate* pDocTemplate; pDocTemplate = new CSingleDocTemplate( IDR_MAINFRAME, RUNTIME_CLASS(CMyDoc), RUNTIME_CLASS(CMainFrame), RUNTIME_CLASS(CMyTreeView)); AddDocTemplate(pDocTemplate); // note that in some less frequent uses, instead of using // the above doc-view template to instanciate the view // we do it ourselves without the document CMyTreeView* pMyView = new CMyTreeView; pMyView->Create (NULL, NULL, WS_CHILD | WS_VISIBLE, CRect (0, 0, 0, 0), this, ID_MYVIEW , NULL); // to set creation styles just before creation BOOL CMyTreeView::PreCreateWindow(CREATESTRUCT& cs) { if (!CTreeView::PreCreateWindow (cs)) return FALSE; cs.style |= TVS_LINESATROOT | TVS_HASBUTTONS; return TRUE; } // to set post creation properties BEGIN_MESSAGE_MAP(CMyTreeView, CTreeView) //{{AFX_MSG_MAP(CMyTreeView) ON_WM_CREATE () //}}AFX_MSG_MAP END_MESSAGE_MAP() int CMyTreeView::OnCreate (LPCREATESTRUCT lpcs) { if (CTreeView::OnCreate (lpcs) == -1) return -1; m_ImageList.Create (IDR_TREEICON, 16, 1, RGB (255, 0, 255)); GetTreeCtrl ().SetImageList (&m_ImageList, TVSIL_NORMAL); return 0; } Notes : In Qt, you do not differentiate between the window C++ object and underlying window you see on the screen [ which is the basics of C++ encapsulation ]. As far as the developer is concerned, instanciating the object with new() takes care of everything. To set window properties we use set and get functions. That is it. In MFC, you have to differentiate between the C++ object and the physical window. You also have to be careful when to set properties and be aware of the stages of window creation : - Some object properties are set when instanciating the C++ object. - Some window properties need to be defined when calling CWnd::Create() - Some window properties need to be defined just before the physical window creation : such as in PreCreateWindow() - Some window properties need to be defined just after the physical window creation in OnCreate() such as setting the image icons for the tree. They rely on the physical window having been created. In my opinion, this is totaly un-acceptable Also note the wide use of SDK types and constants such as CREATESTRUCT, TVS_LINESATROOT, TVSIL_NORMAL. Apart from platform portability [ which itself is a BIG thing ], Qt is cleaner, flexible, and easy to understand. /******************************************************* * 2 Adding tree node items ********************************************************/ Qt -- QListViewItem* rootItem = new QListViewItem(treeview ,"Root node text" ); rootItem->setPixmap(0,RootNodePixmap); QListViewItem* childItem = new QListViewItem(rootItem ,"Child node text" ); childItem->setPixmap(0,ChildNodePixmap); MFC --- HTREEITEM rootItem = GetTreeCtrl().InsertItem("Root node text",0,0, TVI_ROOT ); HTREEITEM childItem = GetTreeCtrl().InsertItem("Child node text",0,0, rootItem ); Notes : In Qt when you insert a node, you insert a C++ object of type QListViewItem or a derivative of that type. In many cases, we insert a type derived from QListViewItem, which contains app specific data. For example if the tree represented a list of people, the new QListViewItem derivative will include things like names, telephone, addresses...etc. In MFC there are no C++ objects involved, again we are using SDK style handles HTREEITEM. This makes a big difference as we will see later. /******************************************************* * 3 Responding to user node selection ********************************************************/ Qt -- connect( SIGNAL(currentChanged( QListViewItem * )), SLOT(OnSelChange(QListViewItem*))); void CMyTreeView::OnSelChange(QListViewItem* pNewItem) { } MFC --- BEGIN_MESSAGE_MAP(CMyTreeView, CTreeView) //{{AFX_MSG_MAP(CMyTreeView) ON_NOTIFY_REFLECT (TVN_SELCHANGED, OnSelChanged) //}}AFX_MSG_MAP END_MESSAGE_MAP() void CMyTreeView::OnSelChanged(NMHDR* pNMHDR, LRESULT* pResult) { NM_TREEVIEW* pNMTreeView = (NM_TREEVIEW*)pNMHDR; // pNMTreeView->itemNew.hItem contains the HTREEITEM // pNMTreeView->action contains the action } Notes: In Qt when the tree selection changed, the C++ object of the new node pNewItem is sent to the OnSelChange message handler. As explained earlier, this object could be a derivative of QListViewItem which contains app specific data [ like the telephone, address example given earlier]. Since we have the selected object pointer, we can take necessary action, such as displaying its data in a different pane. In MFC when the tree selection changed, we get ( as expected ) nothing more than the Win32 SDK structutes NMHDR,NM_TREEVIEW from which we get pNMTreeView->action and pNMTreeView->itemNew.hItem which contains the Win32 handle HTREEITEM. As this handle is really meaningless to the app and means something only to the OS, the developer typically builds a lookup table between the HTREEITEM and the app specific C++ data associated with this item, this is typically done while inserting the items in step 2 using a hash map like CMap. During processing of selection changed, the map is used to loockup the C++ object from the HTREEITEM. Other advantages of sending C++ object node pointer instead of an OS handle is we can easily use its functions such firstChild(),nextSibling(),temAbove(),childCount() also delete the C++ object deletes the nodes..etc. In brief we are comparing a C++ implementation vs an SDK one /******************************************************* * 4 Customization ********************************************************/ Qt -- Since we use true C++, customization is truely logical. For example to customize how the nodes are painted [ example to change fonts, colors, bitmap or draw it any shape we want ] just overide QListViewItem::paintCell() and define custom drawing. that is it ! MFC --- Good luck, anyone knows how to customize tree drawing ? ( i dont believe the Win32 HTREEITEM struct will help here ) As a side note here : There are also much more advanced Qt display customization features that handle the overall application look and feel to a desired theme and style. You can dynamically flip through them at run time instantaneously : such themes include Win95, Motif, Solaris, XP, Apple Aqua ..etc This is all the logic result of clean oop design.

Re: another code comparison - ariya - 2002-08-10

The ability to switch the appearance is because of the use of style (which fortunately implemented as plugin). In addition, XP only works on Windows XP (the styles utilizes DLL which does XP theme interface) and Apple Aqua only available in Mac OS.

Re: another code comparison - Florian W. - 2002-08-11

Hi maged mokhtar You wrote a lot of stuff, why you like the QT so much. Are you working for trolltech ? I have programmed several years for windows 3.1 in C. And the C-Windows-Api has a lot of stuff, that xlib doesn't have. Menubars, Scrollbars, Dialogs, MDI etc. The MFC is a wrapper, that a person who understands the C-API can easily understand, because the way of thinking doesn't change very much, it's just more comfortable. Additionaly MS has done a lot of work, to keep the MFC backward compatible. The samples of my MFC 1.0 book are still working. I haven't analysed QT for windows, but it seems to me, that the wrapper is much more higher than MFC. QT also have another message system, so as a windows progammer, I have to care about C++-messages, Windows-messages, Automation-messages and QT-message (the signal/slot stuff) -at least during debugging. Personally, I think that the QT message system is a message-system to much. I have no motivation to learn another abstract model for the windows-api. Every C++ Windows programm knows the MFC. There are no communication problems. There are sites like codeproject.com and codeguru.com with lots of MFC sample code (It's like CPAN for perl). And at least, there is the same framework-killer, similar to OWL: If MS introduces another feature (what they do regulary), I have to wait until trolltech introduces that stuff into qt, if they ever do. If I use the MFC, the sample code is delivered by Microsoft, or I can get it from a third-party-developer. If I write a windows-Only application, I must be brain-dead, if I use QT. Regards Florian

Re: another code comparison - arjuna - 2002-08-11

hi Florian, > And the C-Windows-Api has a lot of stuff, that xlib doesn't have. Because they're basically different. Xlib only provides basic interface, extend it using whatever toolkit you want/evangelize/like/hate. > The MFC is a wrapper, that a person who understands the C-API can > easily understand, because the way of thinking doesn't > change very much, it's just more comfortable. Fine, if it suits for you. For me, the problem is simple: because it's really closed to the C API (like Maged said, even doesn't provide default value to assist the programmer), what's the point of making it a C++ wrapper ? > QT also have another message system, so as a windows progammer, I have to > care about C++-messages, Windows-messages, Automation-messages and > QT-message (the signal/slot stuff) If you use a Qt-only program, why care about Windows-messages ? They're already taken care inside Qt. And what's C messages are you referring, too ? FYI, use ActiveQt (check Trolltech website) and COM-enabled your application easily. > Every C++ Windows programm(er) knows the MFC Such a claim. What about people that don't use MSVC but go with say Borland C++Builder instead ? That VCL abstraction in C++Builder is of course no MFC at all. > If MS introduces another feature (what they do regulary), > I have to wait until trolltech introduces that stuff into qt, > if they ever do So you use every little bit of MFC's features ? Well, the 80/20 should also apply here. Most of time, only the-really-important stuff is being used, which can be done cleanly using Qt. If you want to push the limit of MFC, then go ahead.And I'd also like to know such features (GUI related one) which already in MFC but are not yet implemented in Qt. Note that I'd like to say that it's OK if MFC is your choice, because it serves your purposes very well, but if you try to convice people not to use Qt because "no motivation to learn another abstract model", I simply disagree. Learning Qt is IMHO worth the time, but nobody forces you to do it.

Re: another code comparison - Florian W. - 2002-08-11

>> Every C++ Windows programm(er) knows the MFC >Such a claim. What about people that don't use MSVC but go with say Borland C++Builder instead ? That VCL abstraction in C++Builder is of course no MFC at all. Just google for sites, that handle with VCL and than look for MFC sites. If you know a site as big as codeproject.com or codeguru.com, tell me. Curently I don't know anyone, who is using VCL now. They have switched to Java or MFC. >So you use every little bit of MFC's features ? Well, the 80/20 should also apply here. If Microsoft introduces a new eye catcher, every application, that doesn't use this eye catcher looks old. This has nothing to do with 80/20 - (by the way, about 80/20: http://www.joelonsoftware.com/articles/fog0000000020.html ) But I don't like signal/slot. May be I'm too old for signal/slot, but I prefer fixed message-method mapping E.g. It's possible, that "show" is emitted and "display" is called and later this is re-mapped to "show" again, and I have to search, who has reconnect that slot. I prefer that there is a fixed place, where such kind of mapping takes place in plain C++. I think, to convice people not to use QT, this is not the right place to do it :-) I just think, that using QT on a windows-only project, might not be a good decision. Hating signal/slot is a complete personal thing, but having so much support for MFC, is a fact. The key argument for MFC are these: - It's supported by Microsoft, even if there is .NET and even it's a little bit obsolete (I think, I can trust on Microsoft's future more that on Trolltech). - There is a lot of addtional free support on the web and from third-party-developers (not free, but worth the money). - During hard debugging sessions, I can use my old C-WIN32-API knowledge easily. + I prefer a fixed message-method mapping. Regards Florian P.S. I'm not an employee of Microsoft.

Re: another code comparison - Uwe W. - 2002-08-14

I would have never guessed I'd live to see the day that someone would actually defend the MFC in such a selfless and ardent way as yourself. I'm afraid you've got more religion than even Microsoft themselves, judging by the twins facts that they themselves don't use the MFC internally for anything worthwhile, and that they're in the middle of a wholesale shift to a Qt-like framework. Consider the MFC to be Microsoft's OOP learning phase, the missing link between SDK and C#. You can do some very revealing searches against the MSDN to discover Microsoft's gradual shift from "OOP is overrated" (back during the MSC7 days), through "ok, encapsulation is useful, but inheritance isn't" (COM days) and "what are templates good for anyway?" (obviously pre-ATL), up to today's .NET-mania. Reading all the .NET code samples promulgated by Microsoft shill FTP's (Fawcette Technical Publications) countless magazines, it seems Microsoft finally made their way through Gamma's Design Patterns. Interfaces, abstraction and delegation galore, an exhuberance for OOP never much seen since the early days of Smalltalk. As you can see, even Microsoft isn't of your opinion that the MFC is a Good Thing. They've realized that bread-and-butter programmers don't care about the messy nuts-and-bolts, they just want to get a job done. Unfortunately, the MFC is all about the nuts-and-bolts, it downright forces you to mix levels of abstraction within your code. The shift to comprehensive frameworks is OOP's probably most lasting legacy. These frameworks represent a comparable increase in productivity to the shift from assembly to higher level languages. Sure, it's all still happening underneath, but for most tasks you don't have to care. A good framework hides most of the complexity but lets you drop down below if you have to, a trait similar to what made C so popular. Take Borland's VCL, which lets you program all day long without even knowing what OS you're on. But if you do want to get at the handles and messages, they're right there for the taking. The MFC does no such hiding--in fact, I have no clue why it's even using classes at all, because it offers few of the benefits of OO and takes little advantage of it. Deriving from MFC classes saves very little work and still forces you to sprinkle macros all over the place. Breaking an MFC app is as simple as forgetting to close a message map, resulting in the most bizzare and misleading errors. It took an ex-Borlander for Microsoft to come up with a good framework. So far .NET looks like something an entrenched OO programmer could get to like. It's both powerful and simple, so don't be suprised if Microsoft start writing a lot of their future apps in C# themselves. This time around they might actually do as they say, unlike in the MFC days.

Re: another code comparison - Florian W. - 2002-08-15

Hi Uwe! If Microsoft doesn't use MFC internally, why do applications like word, explorer, internet explorer, etc. are depending on it ? Concerning the base class library like MFC,QT or VCL, I believe, that better service is more important than pure OOP. If you need an specific control, you can write it on your own (e.g. 2 weeks) or you can reuse a ready one (2 hours). I prefer the 2 hours solution and this means MFC ( No I don't repeat the websites here again). That a new class library is more OOP than existing ones is not a surprise. If I had to decide between C# and Java, I prefer Java, because there I'm a little bit more sure, that stuff is working. As I heard, some parts of .NET are currently rewritten from scratch. Regards Florian

Re: another code comparison - Uwe W. - 2002-08-15

Hi Florian, > why do applications like word, explorer, internet explorer [...] depend on it? I'm afraid I have to disappoint you on all three accounts. Using both Dependency Walker and Process Explorer you can see that none of the mentioned apps use MFC*.DLL in any shape or form. They're all straight API apps (directly or using ATL/WTL). Actually, I spoke too soon; Process Explorer does show WINWORD.EXE as using MFC42.DLL, but I believe it's one of the Office Integration components that I'm using (FileNET) that is using the DLL, not Word itself. > I believe, that better service is more important than pure OOP Absolutely, no sane person would be doing OOP just for the sake of it, and user-friendly encapsulation and hiding of complex APIs is what (well-done) OO frameworks excel at. > If you need an specific control, you can write it on your own > (e.g. 2 weeks) or you can reuse a ready one (2 hours). Definitely. > I prefer the 2 hours solution and this means MFC That's where you're dead wrong. There are much more drop-in components and code available for the VCL and Qt than for MFC or (God forbit) OCX. In fact, most of the MFC code I've seen is of the cookie-cutter recipe variety to scratch a very specific itch (i.e. most of CodeCentral), but relatively few ready-made generally useful components. Check out the third-party components available for Borland's Delphi, both commercial and free, they blow away anything available for MFC or VB. This is particularly astonishing in view of the developer ratios. What absolutely flabberghasts me is the lack of a great number of freely available OCX controls, especially after VB introduced the ability to easily create them. I attribute this to the fact that even though there are huge hordes of VB "developers", the vast majority of them are very superficial programmers and have little or no knowledge of COM and OLE controls. Still, after VB5 and VB6 came out, a lot of people had expected that a wealth of OLE controls would soon flood the scene and dwarf the number of Delphi components. I still expect that this might happen with .NET, since it includes a nice language-independent controls model. > As I heard, some parts of .NET are currently rewritten from scratch. Most parts of .NET are written from scratch, including the class framework (with the possible exception of the VS IDE, which seems to be a continuation of InterDev). Incidentally, many people have written their own class wrappers around the Win32 API, even after MFC was released. Sure, not comprehensive frameworks but rather just wrappers for the components they needed. I still have a book on the shelf from the early 90s, Windows++, that shows how to implement your own OO wrapper around the Win32 API. Believe me, the end result looked nothing like the MFC, much more like Borland's OWL and VCL, or like Qt.

Re: another code comparison - Florian W. - 2002-08-17

Hi Uwe! This one goes to you, the epxlorer and most of office doesn't depend on mfc42.dll (but Visual Studio 6.0 and Frontpage do :-). But I don't thing, that they use VCL or QT. I can remember that I compared Visual C++ 1.0 and Turbo C++ V4.5. That time I realized, that I'm faster learning and using MFC than OWL. May be I'm a bad OOP skilled programmer in your eyes, but until now I haven't found a killer inside the MFC that really let me think about a switch (and I got my projects on time). Every problem could be solved with the support of the web and some colleagues. Also I'm prefering that MFC is not so flexible. That's make it easier, to maintain other people's code. Why change a system that works ? Nevertheless the amount of components for delphi/VCL looks really impressive, so I asked a former Delphi user, why he doesn't use it anymore. He told me that Java has better support, better components and an increased productivity than delphi. After that he showed some really cool Java tools (refactoring, unit-test etc.). Believe me, Java has more from a killer than OWL/VCL/QT/.NET. Regards Florian

Re: another code comparison - Uwe W. - 2002-08-17

> But I don't thing, that they use VCL or QT. Never said they did. In fact, for most internal projects MS use plain SDK, the ATL, and the (very little known) WTL. I suspect the reason for that is that it gives them more flexibility in refactoring code later on than with using the MFC, even if it means more work up front (particularly with straight SDK). My point was only that even for Microsoft themselves the MFC isn't good enough for serious long-term projects. > I asked a former Delphi user, why he doesn't use it anymore That has a lot to do with the job market. Unfortunately most large companies stick to MS-only tools consequences be damned, much more for economic reasons (site licenses etc.) than for best-of-breed reasons. > Believe me, Java has more from a killer than OWL/VCL/QT/.NET. Java sucks precisely in the area Delphi (and Qt) excel at: GUIs. Show me someone who actually LIKES Swing apps and I show you a masochist. Java may be great for a lot of things, but the desktop it ain't.

Re: another code comparison - SANNIER Jean-Baptiste - 2002-11-22

One thing with Java is that I can use it to any platform for free; and I should pay a hard price to Visual Studio and Delphi. First point for a developer: the price. QT is expected to work on most platforms, whereas in MFC you only work on Windows. Like you, I choose QT only if I make some multi-platforms program. When you're wrong is to think that in Java we cannot make such powerful graphical interface. Have you heard of QTJava ? As for you, I hate Swing, and a port of Qt in Java represents for me the ultimate solution, as both Java and QT work in most platforms. Final point: by isolating all specific-platform codes, you can easily port your software from an OS to another. QTJava suits well, and QT too. I don't think there is such a lot of guys who use MFC and MFC only. In small applications, we don't need to reinvent the wheel. If you make a component in pure MFC, well congratulations, but porting it to another platform one day could cost you to rewrite it someday. We must always think that Microsoft will one day fall, whereas some other OS will climb. And making solutions that can be easily ported to another platform is not a crazy thing. To defend QT, I will simply say that this library has sufficient features to suit to commercial programs, even in Win32 platforms as it now integrates ActiveX support (IE, and so much components that the developers can use in another platforms... An oriented-objet ActiveX component to handle the System Tray, why not ?). I can access DataBases, make some Networking operations, create some powerful components and graphical interface; and most of it: if one day, the project must be ported to another platform for any reason, it will be very fast to port it... And in MFC ? I know that you don't care about porting your applications, but think that as you cannot say the future, you don't know if someday, you should have to prot your applications.

Re: another code comparison - Vishwanath - 2007-04-24

Java is really good for almost all applications indeed. But when it comes to Desktop applications, C/C++/Delphi has its part. Being programming for various platforms, till day, I fond couple of +ves and couple of -ves in each of the varients discussed in this topic. MFC: 1. MFC has only its use/maintainability till you have the Wizards of Visual Studio available. ;-). Just imagining a senario without the Wizards of the Visual Studio, there is just a little difference between MFC and Qt!!!. You (Programmer) has to do everything. Yes. I do agree that there is a lot of documentation on MFC (Actually not MFC but the Windows API). (I had to look in the 5 DVD manual on the documentation for just finding out a small help!!!). 2. MFC is not available for other platforms!. Means if once a program is developed on Windows platform, The program always have to GLUE itself to Windows. No matter how many bugs it has!!!!. Where as Qt is available on many platforms. 3. MFC Look & Feel is good!. (Because everything looks like the same!). Somewhere I read in a UI design concepts document, that you need to imitate other Programs as far as possible, because the user of your program is an EDIOT!!!!. and doesnt accept changes. (And I find it true :-) ). 4. MFC programs indeed be ported to Other platforms. Using WIND/U code library which comes for a HUGE cost. 5. Windows Programs also can be executed thru WINE emulator. But being Slow!. I also some time back wanted to port one of my MFC code to Linux! Bah... I found Nothing but Errors. MFC library just cant be ported! So. Use Qt: if you want portablility + look & feel Use MFC: If you think that programs will never be ported to any other platform.