|
A lot of it is familiarity. Whilst there's no doubt that some parts of MFC have functionality missing from WTL (the command UI update mechanism and Doc/View are two obvious examples) the common controls aren't among them.
I'm fluent in both frameworks, but I've not had to write a line of MFC in 4 years.
Anna ![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
Tech Blog | Visual Lint
"Why would anyone prefer to wield a weapon that takes both hands at once, when they could use a lighter (and obviously superior) weapon that allows you to wield multiple ones at a time, and thus supports multi-paradigm carnage?"
|
|
|
|
|
For one, WTL is not supported by Visual Studio.
MFC ClassWizard (revamped) is back in VS 2010, and there is obvious reason for it.
|
|
|
|
|
I haven't used the ClassWizard since 1998 (VC4.1) or so - I just found it too restrictive and found it easier to write the code myself instead. Hence I didn't find its omission from VS2002-VS2008 a problem at all.
However, if that's the sort of thing that floats your boat there is a WTL ClassWizard right here on CodeProject - but as I don't find I need ClassWizard I've never used it.
Anna
Tech Blog | Visual Lint
"Why would anyone prefer to wield a weapon that takes both hands at once, when they could use a lighter (and obviously superior) weapon that allows you to wield multiple ones at a time, and thus supports multi-paradigm carnage?"
|
|
|
|
|
Code but how much? There are complicated notification messages (WM_NOTIFY) that can automatically be written straightaway from Resource editor.
As I already mentioned CW is one of the features that MFC has, and not the feature to market MFC.
May be you can point out few features, that aren't available in MFC, but in WTL.
|
|
|
|
|
I prefer to have more control over the code than ClassWizard offers. That's my choice, but I certainly don't condemn yours! As I said, there is a ClassWizard for WTL available for those who are more comfortable with that style of development.
Doc/View and CN_UPDATE_COMMAND_UI are two features in MFC that are notably missing out of the box in WTL; both can be annoying but neither are showstoppers (we actually use a WTL Doc/View port in one of our projects), but it's not in the distribution. By contrast things like ribbon controls and Task Dialogs are included.
On the flipside, it's far easier to extend dialogs and control classes in WTL using mix-ins than in the CObject based single-inheritance model MFC forces you into. For example, adding the same context help fucntionality to a CPropertyPage and a CDialog is very difficult without duplicating the code, and a mix-in class like WTL::CSortListViewImplT just isn't possible in MFC without using window hooks.
Ultimately MFC is a much more heavyweight framework with longer history and therefore backward compatibility induced baggage (remember the CPropertySheetEx fudge?) than WTL, which is rather more lightweight in nature.
If MFC works fine for you, that's perfectly fine; I can only speak for myself - and I have run up against inviolable assumptions in its design which make it unsuitable for the sort of projects I work on at the moment.
Hence, I'm rather enjoying using a more modern lightweight alternative, but I'm not suggesting everyone has to, by any means - use what works for you.
Anna
Tech Blog | Visual Lint
"Why would anyone prefer to wield a weapon that takes both hands at once, when they could use a lighter (and obviously superior) weapon that allows you to wield multiple ones at a time, and thus supports multi-paradigm carnage?"
|
|
|
|
|
Anna-Jayne Metcalfe wrote: I prefer to have more control over the code than ClassWizard offers. That's my choice, but I certainly don't condemn yours! As I said, there is a ClassWizard for WTL available for those who are more comfortable with that style of development.
How many times you need to have more-control? You would love to copy-paste the same code, rather than just let the development environment do it for you? And you don't lose any flexibility either, it is not like ATL/COM complex macros you cannot control - the entire generated code is there for you. Any MFC programmer, after gaining confidence over more-control part (after learning) would prefer automatic code generation; and would have the ability to change the code.
Anna-Jayne Metcalfe wrote: Doc/View and CN_UPDATE_COMMAND_UI are two features in MFC that are notably missing out of the box in WTL; both can be annoying but neither are showstoppers (we actually use a WTL Doc/View port in one of our projects), but it's not in the distribution. By contrast things like ribbon controls and Task Dialogs are included
I don't count is as feature in even in MFC.
Anna-Jayne Metcalfe wrote: On the flipside, it's far easier to extend dialogs and control classes in WTL using mix-ins than in the CObject based single-inheritance model MFC forces you into. For example, adding the same context help fucntionality to a CPropertyPage and a CDialog is very difficult without duplicating the code, and a mix-in class like WTL::CSortListViewImplT just isn't possible in MFC without using window hooks.
MFC doesn't support MI for a reason. Have all classes which are NOT derived from CObject, except one, and you can achieve MI. Why would you need two CObject class participating in MI?
I did not understand about the help-functionality you mentioned!
With CSortListViewImplT, I think you meant a list-control's sorting. You can use virtual-list control! You always don't need callback mechanism for sorting. For less number of items in list-control, you just delete-all and then insert again! What Windows Hooks has to do with it??
Anna-Jayne Metcalfe wrote: Ultimately MFC is a much more heavyweight framework with longer history and therefore backward compatibility induced baggage (remember the CPropertySheetEx fudge?) than WTL, which is rather more lightweight in nature.
Heavyweight. Compared to what? A template-based code that goes into multiple executables? I have developed hundreds of MFC apps, and that needed only one MFC DLL. You know what I am referring here.
MFC is very thin layer over Win32 APIs. Most of the functions are inlined (logically), and they simply call Windows functions (like SendMessage). Yes they are mixed with ASSERT macros, but that's just a defensive approach.
|
|
|
|
|
Ajay Vijayvargiya wrote: Heavyweight. Compared to what? A template-based code that goes into multiple executables?
Pretty much all WTL code gets optimized away by the compiler. Scott Meyers did an interesting experiment with several GUI libraries/frameworks and found WTL to have the least overhead compared to pure C Win32. Can't find the link, sorry - it was a disussion on comp.lang.c++.moderated.
But my biggest peeve with MFC is not the runtime overhead, but the fact that it is an application framework - it works fine as long as your application fits the MFC model, but once your requirements don't fit the model you need to constantly fight MFC, and I find it very frustrating. To be fair, I have the same problem with any other framework I have worked with. ATL/WTL, on another hand, is a library. You can use as much of it as you want and it does not impose any design on you. It does HWND to object mapping fine (much better than MFC), it has a decent message cracking mechanism, enables automatic cleanup of handles for controls, there is a nice optional layout manager[^] - that's almost all I need from a GUI library. Serialization, networking and other MFC provided goodies are orthogonal to GUI programming and have no place in a GUI library, IMHO.
|
|
|
|
|
You really like a good debate don't you? 
I must admit I'd generally prefer to have this sort of discussion over a pint in a decent pub than on a message board anyday, but assuming that's not an option for you (though I will be in Oxford with around 400 like minded devs for the ACCU Conference in April if you would care to carry on the discussion in person) I'll happily expand on the points I made. 
Ajay Vijayvargiya wrote: How many times you need to have more-control? You would love to copy-paste the same code, rather than just let the development environment do it for you? And you don't lose any flexibility either, it is not like ATL/COM complex macros you cannot control - the entire generated code is there for you. Any MFC programmer, after gaining confidence over more-control part (after learning) would prefer automatic code generation; and would have the ability to change the code
Most of the time I do. Automated tools are very poor at formatting code, and tend to (for example) place new methods at the end of the file rather than organising it logically (overrides, operations, impl methods, handlers etc.), so I find I spend just as long moving and reformatting the auto-generated code as if I'd written it myself in the first place anyway (which would seem to defeat the point).
But that's just me. YMMV, of course.
Ajay Vijayvargiya wrote: I don't count is as feature in even in MFC.
Why on earth not? Even if you don't use them all three are significant parts of the framework. I don't use OLE/compound documents (another area MFC has detailed support for but WTL lacks) but I certainly wouldn't claim they aren't important.
Ajay Vijayvargiya wrote: MFC doesn't support MI for a reason. Have all classes which are NOT derived from CObject, except one, and you can achieve MI. Why would you need two CObject class participating in MI?
I did not understand about the help-functionality you mentioned!
With CSortListViewImplT, I think you meant a list-control's sorting. You can use virtual-list control! You always don't need callback mechanism for sorting. For less number of items in list-control, you just delete-all and then insert again! What Windows Hooks has to do with it
The reason MFC does not support MI is simple one - at the time it was designed (for Visual C++ 1.0) it was effectively theoretical - very few organisations used it, and those that did probably didn't do so effectively. That has changed dramatically since the advent of COM and templates - even the MFC CString class is now implemented in terms of templates and traits.
However, the CObject hieraracy is fundamentally incompatible with this sort of design. By contrast the WTL equivalent is far more straightforward to implement as the way messages are routed is more flexible and doesn't make any assumptions about the design of your code.
The reason I raised help functionality is because it is a simple and easy to replicate example. To implement it, you need to write message handlers, which in turn means the class must be CObject derived. Hence, you cannot write an MFC context help implementation which supports an arbitrary base class (not even both CDialog and CPropertyPage) without doing some pretty advanced window hooking or resorting to macros. So you invariably end up duplicating the code, and writing huge base classes which do absolutely eveything.
By the way, WTL::CSortListViewT does a lot more than a simple virtual list control - it handles sorting of items automatically for any list control/list view without any user intervention. As a template you can inject it (or any custom functionality you want to reuse) into any WTL list view with an arbitary base class - something that's next to impossible with MFC because of the CObject based nature of the message map implementation.
Ajay Vijayvargiya wrote: Heavyweight. Compared to what? A template-based code that goes into multiple executables? I have developed hundreds of MFC apps, and that needed only one MFC DLL. You know what I am referring here.
MFC is referred to as heavyweight (and not just by me) in that it assumes certain things are always going to be there in your app (a simple example would be a CWinApp class, which believe me isn't something you want in a COM plug-in DLL for Visual Studio). In other words you can't easily pick and mix the bits you need, so in many applications the resulting executables are larger than their ATL/WTL equivalent. At the end of the day which is the right choice for you depends what you're building, and what experience you have.
It is also interesting to note that recent versions of MFC delegate quite a bit of their base implementation to ATL (of which WTL is effectively just a windowing extension written in the same style). For example, the MFC CString is now just a specialisation of the ATL/WTL CStringT class - the original MFC CString code was dumped in VS2002.
Finally, if you're writing multithreaded interactive COM add-ins for Visual Studio (as I do), you'll also quickly discover that it's next to impossible to get MFC to work reliably in that environment; fortunately a combination of WTL and the Standard C++ Library has proved to give us the control and flexibility we need to develop our products (most notably Visual Lint[^], which is entirely implemented in ATL/WTL), without sacrificing development time.
YMMV, of course. 
Anna ![Rose | [Rose]](https://www.codeproject.com/script/Forums/Images/rose.gif)
Tech Blog | Visual Lint
"Why would anyone prefer to wield a weapon that takes both hands at once, when they could use a lighter (and obviously superior) weapon that allows you to wield multiple ones at a time, and thus supports multi-paradigm carnage?"
|
|
|
|
|
Anna-Jayne Metcalfe wrote: You really like a good debate don't you?
Did you say it to me? I guess not. I like debate. That's the way we share thoughts and information.
Code Formatting shouldn't be a concern, specially by programmer like you, who wants to have full control over code!
Just use clipboard operations, drag and drop, or use Visual AssistX!
I see you are looking more of compatibleness, flexibility and cross-compiler/platform type of points - while I am (from MFC' perspective) more concerned with adaptability, easiness, and approachability with/to other programmers. Unless and until you do need COM, plug-ins and stuff like that, you can always jump in and take MFC. MFC is just an application framework, especially a GUI framework. When I write DLL, I don't use MFC, except CString class (which I include, and not link with MFC!). Other than GUI thread, I don't use MFC stuff (collection classes, I use STL).
Visual Lint is a tool that needs integration, and I haven't written any VS Add-in - but I do understand your concern with CWinApp's bloat-ness.
For me MFC works more than just-fine, I haven't encountered such thing where I'd say "ohh sh.t, MFC doesn't support this, how do I do?".
|
|
|
|
|
Ajay Vijayvargiya wrote: Did you say it to me? I guess not. I like debate. That's the way we share thoughts and information.
I'm more of an in-person debater these days. Preferably over a pint, as I said. 
Ajay Vijayvargiya wrote: Code Formatting shouldn't be a concern, specially by programmer like you, who wants to have full control over code!
Just use clipboard operations, drag and drop, or use Visual AssistX!
Why ever not? I've always found neat code to be more readable and thus more maintainable than poorly formatted code, and as such I tend to use a fairly regular arrangement for code I write. In that whitespace is quite important - so for example I will left align IDs and function names in message maps so I can spot inconsistancies and dead entries quickly without having to pore over every line.
I do use Visual Assist X (among other plug-ins), BTW.
Ajay Vijayvargiya wrote: I see you are looking more of compatibleness, flexibility and cross-compiler/platform type of points - while I am (from MFC' perspective) more concerned with adaptability, easiness, and approachability with/to other programmers. Unless and until you do need COM, plug-ins and stuff like that, you can always jump in and take MFC. MFC is just an application framework, especially a GUI framework. When I write DLL, I don't use MFC, except CString class (which I include, and not link with MFC!). Other than GUI thread, I don't use MFC stuff (collection classes, I use STL).
Visual Lint is a tool that needs integration, and I haven't written any VS Add-in - but I do understand your concern with CWinApp's bloat-ness.
We all have different priorities and needs; a point I made earlier in this thread. Like MFC, WTL isn't cross platform (though it would be very useful if it was - we get occasional requests for Linux support). We'd consider using MFC if we needed to, but in all honesty apart from ResOrg 1.6 (which was written in MFC but is now effectively dead now that the ATL/WTL port is in beta) we've not needed to.
As I said earlier, CString (as well as CRect, CSize etc.) are implemented as inline ATL classes in MFC these days so you can use them independently - they aren't really comparable with their old MFC implementations. WTL classes such as CListViewImpl, CWindowImpl, CPropertySheetImpl etc. are no different - you just pick and choose the bits you need when you need them - even in an otherwise MFC project.
At the end of the day you should use what works for you; just be aware that that can change unexpectedly (as it did for me - I exclusively worked in MFC until summer 2004) and be open to that possibility.
Anna
Tech Blog | Visual Lint
"Why would anyone prefer to wield a weapon that takes both hands at once, when they could use a lighter (and obviously superior) weapon that allows you to wield multiple ones at a time, and thus supports multi-paradigm carnage?"
|
|
|
|
|
Granted, XNA is not what immediately comes to mind for desktop applications, but if you need graphics it might be worth a look. The downside is the lack of a GUI, but I have begun to put together my own last weekend. It already can render some simple controls, but there are also quite a few things left to be solved (like the question how to handle the event-driven GUI vs. the endless rendering loop). Anyway it's really fun to work on and once it reaches a certain degree of maturity, I will port our MVP classes and our application.
A while ago he asked me what he should have printed on my business cards. I said 'Wizard'.
I read books which nobody else understand. Then I do something which nobody understands. After that the computer does something which nobody understands. When asked, I say things about the results which nobody understand. But everybody expects miracles from me on a regular basis. Looks to me like the classical definition of a wizard.
|
|
|
|
|
|
Hey, thanks for the notice! Have you ever used it? Just curious.
|
|
|
|
|
Yes, about 5-6 years ago? I wrote GRip using the VCF, one of the success stories. Unfortunately, had to get a real job (i.e. one that actually pays money ), so had to put it on the back burner.
If I ever have a chance to go back to C++, I'd use the VCF again!
- S
50 cups of coffee and you know it's on!
Code, follow, or get out of the way.
|
|
|
|
|
Oh yeah! Now I remember, I thought the name sounded familiar! Yeah that whole money thing is a real PITA
|
|
|
|
|
I hear ya! My plans to win the lottery have completely backfired!
- S
50 cups of coffee and you know it's on!
Code, follow, or get out of the way.
|
|
|
|
|
I'm not really doing desktop apps, but I write my tools in Java. Always been curious about Qt, but never got a chance to try it out.
|
|
|
|
|
If you're developing a desktop application, it's a bit masochistic to develop it in Silverlight which is a web-based development framework. You can do it, in the same way that you can write a desktop javascript application, roughly in the same way you can nail your own lower lip to the desk. You could, it's just not recommended.
|
|
|
|
|
It gets worse, writing a Silverlight application that is going to be accessed remotely via CITRIX.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
OK. That's nailing your testicles to the desk.
|
|
|
|
|
Thanks for that Pete, I referenced this thread as a second opinion in a management meeting at which I attempted to change the requirement.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Microsoft has recently been promoting Silverlight out-of-browser as the recommended way to write desktop apps, instead of WPF. I suppose in a few years they'll be telling us that desktop apps should be HTML5 out-of-browser. That will be like nailing your testicles to your lower lip.
|
|
|
|
|
Succinct and to the point Mr Smith. I've got a great idea, let's have SL OOB run under a feature rich runtime. Let's see, what could we call it? How about WPF?
|
|
|
|
|
I am working on pure Silverlight application, sometimes with WPF too.
|
|
|
|
|
As a former MFC programmer for over 12 years, Qt was a huge improvement for me. I find it similar to MFC in some ways so the learning curve was not too bad. The biggest advantage is it gives me the ability to write code and without many changes in the code or much effort in the build system (since I pair Qt with CMake) I can also target for linux and macintosh. I do government funded medical imaging research so a lot of what I do should be public domain if any of my peers ask for it.
Other huge advantages are signals and slots and the UI. Being able to generate dialogs and other UI elements in code, through an editor or from a xml file is very convenient. Layouts and dynamic resizing are much better than what I had with MFC in VS 2005 and lower.
The biggest negative I have found with Qt is that the 750+ thousand lines of MFC code I wrote before that has to be ported to be used with the free version of Qt. Although a considerable percentage of that code is stuff that was not in MFC so I had to roll my own (or modify codeproject examples) but this functionality comes standard in Qt. Maybe not as advanced but the standard code is good enough to use.
John
modified on Monday, January 24, 2011 9:24 AM
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
