WTL - What's All The Fuss About?
-
Mark Nischalke wrote: There is also the distribution issue, WTL doesn't require the MFC dll's to be shipped. Umm.. MFC doesn't require that MFC DLL's be shipped, either. That's an urban legend promoted by the early MFC team. Link statically.
But the dll's must be present (and the correct version). If they are not the app won't work so you must distribute them or statically link. Again increasing the size of the app or the distribution or both.
-
But it drastically increases the size. Would you rather download 3MB or 300k?
I statically link MFC and I use the MFC collection classes, and I ship three separate executables that are each about 250k in release mode. It zips down quite nicely, too (a little less than 400k). "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 Please review the Legal Disclaimer in my bio.
-
I was looking at Eugene Polonsky's ATL Snapping Framework article, and Ijust have to ask... What is the big deal about WTL? What does it do that MFC doesn't do? (And "code bloat" is not considered a valid response.) What doesn't it do that MFC does? Are the various app/class wizards still available? Does it make development faster? Are your apps faster? Are your apps more reliable? What's the point of the library? Can it be used *with/alongside* MFC? Why should I consider using it? "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 Please review the Legal Disclaimer in my bio.
John Simmons / outlaw programmer wrote: What is the big deal about WTL? What does it do that MFC doesn't do? (And "code bloat" is not considered a valid response.) I like it because it is a small a light weight frame-work that is very close to the SDK. I especially like the use of template. One of the things that templates gives is something called simulated-dynamic binding, or virtual binding, I am able to change the root class implementation of a fundemental part of the framwwork by just changing a template arguement. This task is not so simple in MFC or C++ with out templates for that matter. Especially if you want to change something at the root of the MFC framework, you will need to build a completely new MFC dll and distribute that. In WTL, all of the code is built into your EXE. There is a lot less code to wade through if you want to figure out how something is done. There are only about 25 header files if you include the code from ATL. There is a default template for the multi-threaded SDI program that models the new document-centric model that microsoft has taken with their office products. Where each new document in a single word program gets its own top level window. I am not sure if MFC has this yet. John Simmons / outlaw programmer wrote: What doesn't it do that MFC does? It creates a framework for message handling including pretranslate message. It does dialog data transfer, ui update. It wraps all of the standard and common controls in a very shallow manner. It provides the ability for an MRU list. Basically every thing that you need in order to do basic windows programming with all of the window objects. John Simmons / outlaw programmer wrote: Are the various app/class wizards still available? I believe that you can still use the class wizard to create classes and things like that, but you do not have a wizard to insert new message handlers and things like that, you still have to do that manually. John Simmons / outlaw programmer wrote: Does it make development faster? I think that depends on how well you know either tool. I also think that it depends on what you are trying to do. If you are doing basic windows development I think that it is teh same. If you are doing something that MFC has already written a class for that you don't have it may be slower. There are somethings that WTL will make faster. Like I mentioned earlier
-
But the dll's must be present (and the correct version). If they are not the app won't work so you must distribute them or statically link. Again increasing the size of the app or the distribution or both.
You really should do a little research. If you statically link with MFC, you DO NOT need the DLL's AT ALL, and the application will IGNORE the DLL's that exist on your system. Even better, your app will function fine even if an older or newer version of the DLL's exist on your system. "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 Please review the Legal Disclaimer in my bio.
-
What is the big deal about WTL? It' could have been a next-generation desktop framework for Windows, were Microsoft interested in such a thing. What does it do that MFC doesn't do? (And "code bloat" is not considered a valid response.) Nothing, really; it is better from an architectural standpoint, in that makes use of more modern programming paradigms, in particular, templates. This makes multiple inheritance simpler. What doesn't it do that MFC does? A lot. There is no doc/view architecture, or in fact any soft of high-level app framework. Are the various app/class wizards still available? Heh. Nothing of much use. No class wizard at all, not even the pathetic thing foind in VC7. You're totally on you won for adding new members. And since there is no documentation, this usuall means going back to the WTL source and unraveling the message macros for every member function you want to add. Does it make development faster? Not at all; it's about 3 timne slower. See above. Are your apps faster? They should be, but i don't know; I only built a smallish test app before giving up. Are your apps more reliable? No reason they should be. What's the point of the library? It seems to be a pet project of someone at MS who did not like MFC. Can it be used *with/alongside* MFC? Nope. Why should I consider using it? Got me.
It doesn't take 3 times the amount of time to create a WTL application. The only time that really comes into play is when you have to re-invent a feature in MFC that isn't in WTL. Tim Smith I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
-
I was looking at Eugene Polonsky's ATL Snapping Framework article, and Ijust have to ask... What is the big deal about WTL? What does it do that MFC doesn't do? (And "code bloat" is not considered a valid response.) What doesn't it do that MFC does? Are the various app/class wizards still available? Does it make development faster? Are your apps faster? Are your apps more reliable? What's the point of the library? Can it be used *with/alongside* MFC? Why should I consider using it? "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 Please review the Legal Disclaimer in my bio.
Er, "code bloat" is just about the most important reason. I have re-written one of my MFC apps (a GUI form designer) in WTL and it is has shrunk from 1.5MB to less than 500KB. My users are VERY happy and the application is just as functional. Why is "code bloat" not considered a valid response? In order to ensure our MFC apps run on any Windows platform correctly, we have to statically link with MFC - this creates HUGE EXEs - this is a bad thing IMHO. What does it do that MFC doesn't? Not much, apart from being simpler hence much easier to understand. This may not be an issue for many people, but personally, I like to know how the framework I am using fits together, and MFC is getting complicated under the hood. WTL apps actually have a WinMain! The message maps are easier to follow, etc. I think that over the years, MFC has gotten too big and too complicated. Keeping It Simple has got to be a good thing surely? I am using WTL7 with VS.NET - I don't have full ClassWizard support, but I can add message map handlers, etc. Yes, VS.NET could do with more WTL support, but it has basic enough support. Faster development? Well, there is a learning curve like any new framework. I have been using MFC since 1995 and I consider myself very productive using it - WTL has taken a little getting used to (mainly the C++ template side of things) but I now use it for all new projects. I have been using it now on and off for about 4 months and would say I am almost at the MFC productivity level. Faster apps? I cannot tell yet, but I will be re-writing a critical app using WTL this summer which will be the acid test for memory usage and speed... More reliable? Being a simpler framework, I am inclined to think so but that really depends on the programmer doesn't it? However, as WTL resides in a dozen or so header files (no LIBs!!) then any bugs that do exist (in the library) are easily fixed. In-house we keep a copy of WTL on CVS - this will allow us to apply fixes, etc. easily. This would be hard to do with MFC. I am going off at a tangent here, but perhaps in the future people will also be able to use WTL with non-MS compilers (there is a Watcom fan club here at my company - in fact, as an MS compiler user I am in a minority!!!) Can it be used with MFC? I can't see much point in doing this, but as WTL is really "ATL with a UI", then I guess it could be done. Many WTL classes use the same names as MFC, which may be problematic, though I guess namespaces could help here. Why should you consider
-
You really should do a little research. If you statically link with MFC, you DO NOT need the DLL's AT ALL, and the application will IGNORE the DLL's that exist on your system. Even better, your app will function fine even if an older or newer version of the DLL's exist on your system. "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 Please review the Legal Disclaimer in my bio.
This is getting out of hand. Yes if you statically link you don't need them but if you dynamically link you do. I have distributed apps that were broken by incorrect versions of dll's as I'm sure you and most others have. 'nough said
-
I was looking at Eugene Polonsky's ATL Snapping Framework article, and Ijust have to ask... What is the big deal about WTL? What does it do that MFC doesn't do? (And "code bloat" is not considered a valid response.) What doesn't it do that MFC does? Are the various app/class wizards still available? Does it make development faster? Are your apps faster? Are your apps more reliable? What's the point of the library? Can it be used *with/alongside* MFC? Why should I consider using it? "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 Please review the Legal Disclaimer in my bio.
Test case was a do nothing dialog app (i.e. Just click through the wizard and compile in release) MFC Statically linked: 200kb ATL: 32kb
-
Honestly, code bloat? Gimme a break here. Do two apps in class wizard using MFC statically linked of each type described below, and then do the same two apps just using WTL with all the required code compiled into the executable (no DLL's). 1) A simple dialog-based app. 2) A simple MDI application that doc/view, a toolbar, and statusbar. The app doesn't have to do anything other than what the MFC app wizard gives you. How much difference in executable size do you really expect (or realize)? In my experience, the code starts to grow when you start adding things like MFC's collection classes and such. More often than not, code grows primarily due to non-MFC UI related (core) app-specific code. What "new UI" are you talking about, the XP bubble interface? "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 Please review the Legal Disclaimer in my bio.
Shrug. Is this a good example John? None of the above apps really does anything, so I expect both to be small. From personal experience, WTL generates smaller apps. One big problem I have had with MFC in the past is getting a COM Automation interface working correctly with an SDI/MDI app - all sorts of gotchas when calling it from VB, etc. In the past I have gone to great lengths to get ATL support working with it (Nick Hodapp wrote a legendary article about this years ago) - with WTL however, it is a breeze. COM in general is much easier with ATL/WTL.
-
I was looking at Eugene Polonsky's ATL Snapping Framework article, and Ijust have to ask... What is the big deal about WTL? What does it do that MFC doesn't do? (And "code bloat" is not considered a valid response.) What doesn't it do that MFC does? Are the various app/class wizards still available? Does it make development faster? Are your apps faster? Are your apps more reliable? What's the point of the library? Can it be used *with/alongside* MFC? Why should I consider using it? "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 Please review the Legal Disclaimer in my bio.
I have not yet used WTL in a real application because of the following reasons: Very little or no documentation, known bugs, no doc / view, limited classwizard support, most of the code available is MFC and will have to be rewritten for WTL, and MS does not officially support it and they may pull it at any time. After saying all this, I may still use WTL in my next project because I develop all my applications multithreaded and the design of MFC's doc/view forces you to create all views in the main thread otherwise you will get into a lot of trouble. John
-
Shrug. Is this a good example John? None of the above apps really does anything, so I expect both to be small. From personal experience, WTL generates smaller apps. One big problem I have had with MFC in the past is getting a COM Automation interface working correctly with an SDI/MDI app - all sorts of gotchas when calling it from VB, etc. In the past I have gone to great lengths to get ATL support working with it (Nick Hodapp wrote a legendary article about this years ago) - with WTL however, it is a breeze. COM in general is much easier with ATL/WTL.
Sure it is. It would take me all of 5 minutes to create both apps using MFC and AppWizard. How long would it take you to duplicate the same functionality using WTL? The AppWizard-generated MFC code in that form would compile to about 200k using VC6. How big would it be using just WTL (and the Windows API of course)? As far as COM goes, I've never had a problem with using it in an MFC app. COM in and of itself is diffcult to work with and is WAY over-used, but that's a different topic. I will concede that there are times when an application has to be as thin as possible in both memory and disk footprint (especially embedded code), but for a normal desktop app with possibly hundreds or thousands of features, is the (apparently minimal) size difference really worth the extra time you would need to implement the same functionality without the benefit of MFC and the accompanying AppWizard and ClassWizard tools? "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 Please review the Legal Disclaimer in my bio.
-
This is getting out of hand. Yes if you statically link you don't need them but if you dynamically link you do. I have distributed apps that were broken by incorrect versions of dll's as I'm sure you and most others have. 'nough said
I can honestly say that I have NEVER had an app break because of errant MFC DLLs because I *always* statically link. The MFC42.DLL is 973k. Why in the world would I want to ship that with my app? I guess I'm just too unsophisticated to be drawn into all of Microsoft's newest whiz-bang technologies. "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 Please review the Legal Disclaimer in my bio.
-
I have not yet used WTL in a real application because of the following reasons: Very little or no documentation, known bugs, no doc / view, limited classwizard support, most of the code available is MFC and will have to be rewritten for WTL, and MS does not officially support it and they may pull it at any time. After saying all this, I may still use WTL in my next project because I develop all my applications multithreaded and the design of MFC's doc/view forces you to create all views in the main thread otherwise you will get into a lot of trouble. John
John M. Drescher wrote: MS does not officially support it and they may pull it at any time. There have been very few changes to WTL since its initial version 3.0 release except a few bug fixes, a dynamic dialog resizing class and a few other features. So even if Microsoft pulls WTL the 16 header files that make it up still exist and provide an awesome framework for developing low overhead applications, you don't need much more than that to use WTL. I would like some documentation on it to make looking up function signatures a little easier but it is still a very viable solution for developing applications.
Build a man a fire, and he will be warm for a day
Light a man on fire, and he will be warm for the rest of his life! -
John Simmons / outlaw programmer wrote: What is the big deal about WTL? What does it do that MFC doesn't do? (And "code bloat" is not considered a valid response.) I like it because it is a small a light weight frame-work that is very close to the SDK. I especially like the use of template. One of the things that templates gives is something called simulated-dynamic binding, or virtual binding, I am able to change the root class implementation of a fundemental part of the framwwork by just changing a template arguement. This task is not so simple in MFC or C++ with out templates for that matter. Especially if you want to change something at the root of the MFC framework, you will need to build a completely new MFC dll and distribute that. In WTL, all of the code is built into your EXE. There is a lot less code to wade through if you want to figure out how something is done. There are only about 25 header files if you include the code from ATL. There is a default template for the multi-threaded SDI program that models the new document-centric model that microsoft has taken with their office products. Where each new document in a single word program gets its own top level window. I am not sure if MFC has this yet. John Simmons / outlaw programmer wrote: What doesn't it do that MFC does? It creates a framework for message handling including pretranslate message. It does dialog data transfer, ui update. It wraps all of the standard and common controls in a very shallow manner. It provides the ability for an MRU list. Basically every thing that you need in order to do basic windows programming with all of the window objects. John Simmons / outlaw programmer wrote: Are the various app/class wizards still available? I believe that you can still use the class wizard to create classes and things like that, but you do not have a wizard to insert new message handlers and things like that, you still have to do that manually. John Simmons / outlaw programmer wrote: Does it make development faster? I think that depends on how well you know either tool. I also think that it depends on what you are trying to do. If you are doing basic windows development I think that it is teh same. If you are doing something that MFC has already written a class for that you don't have it may be slower. There are somethings that WTL will make faster. Like I mentioned earlier
One more thing that I forbot to mention that is an advantage for WTL, is that it is based on ATL which was designed from teh ground up to support COM. COM had to be Shoe-horned into MFC and is in many ways very clumsy to deal with, although it works. COM support in WTL is simply more natural.
Build a man a fire, and he will be warm for a day
Light a man on fire, and he will be warm for the rest of his life! -
Sure it is. It would take me all of 5 minutes to create both apps using MFC and AppWizard. How long would it take you to duplicate the same functionality using WTL? The AppWizard-generated MFC code in that form would compile to about 200k using VC6. How big would it be using just WTL (and the Windows API of course)? As far as COM goes, I've never had a problem with using it in an MFC app. COM in and of itself is diffcult to work with and is WAY over-used, but that's a different topic. I will concede that there are times when an application has to be as thin as possible in both memory and disk footprint (especially embedded code), but for a normal desktop app with possibly hundreds or thousands of features, is the (apparently minimal) size difference really worth the extra time you would need to implement the same functionality without the benefit of MFC and the accompanying AppWizard and ClassWizard tools? "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 Please review the Legal Disclaimer in my bio.
John Simmons / outlaw programmer wrote: Sure it is. It would take me all of 5 minutes to create both apps using MFC and AppWizard. How long would it take you to duplicate the same functionality using WTL? WTL comes with an app wizard to create the generic MDI, SDI, multi-threaded SDI, or dialog based apps with a view, toolbar support with the possible use of command bars and rebars, status bars, contain activeX controls and what not. But in WTL's case I think that it would only take about 4 minutes to create both apps :)
Build a man a fire, and he will be warm for a day
Light a man on fire, and he will be warm for the rest of his life! -
Code Bloat - That is a valid reason. Just because you don't think so doesn't mean it isn't. Faster - Yes. Not as much UI crap in there. WTL tends to be more lightweight. Reliable - No, I can't really say this. Alongside MFC - Yes More Versitle - I am able to do more with WTL than MFC. The more you vary from MFC's design the harder it is to get it to do what you need. The DOC/VIEW stuff isn't in WTL. Updated UI - Well, not that important now since MFC7. But WTL had the new UI before MFC. Tim Smith I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
Tim Smith wrote: More Versitle - I am able to do more with WTL than MFC. The more you vary from MFC's design the harder it is to get it to do what you need. The DOC/VIEW stuff isn't in WTL. I would like to comment on this. MFC has a generic way of doing things, that it assumes all developers want to develop their app the same way. WTL is straight application development. There is no assumption in the way that you are going to develop your app. So Tim is right in the fact that the more your app deviates from the generic windows app that MFC is designed for, the more difficult it will be for you to develop your app. This is not an issue with WTL.
Build a man a fire, and he will be warm for a day
Light a man on fire, and he will be warm for the rest of his life! -
Sure it is. It would take me all of 5 minutes to create both apps using MFC and AppWizard. How long would it take you to duplicate the same functionality using WTL? The AppWizard-generated MFC code in that form would compile to about 200k using VC6. How big would it be using just WTL (and the Windows API of course)? As far as COM goes, I've never had a problem with using it in an MFC app. COM in and of itself is diffcult to work with and is WAY over-used, but that's a different topic. I will concede that there are times when an application has to be as thin as possible in both memory and disk footprint (especially embedded code), but for a normal desktop app with possibly hundreds or thousands of features, is the (apparently minimal) size difference really worth the extra time you would need to implement the same functionality without the benefit of MFC and the accompanying AppWizard and ClassWizard tools? "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 Please review the Legal Disclaimer in my bio.
It takes the same amount of time. I use the WTL AppWizard. The WTL versions of both examples are smaller. The WTL code, IMHO, is easier to follow. This is a no-brainer surely? If you haven't had problems with COM and MFC then you are a lucky man! It has caused me no-end of problems. I agree it is over-used and probably needs killing off, but some of our customers demand it for various reasons. is the (apparently minimal) size difference really worth the extra time you would need to implement the same functionality without the benefit of MFC and the accompanying AppWizard and ClassWizard tools? In my opinion - yes! The WTL AppWizard already exists, and I am getting along fine using VS.NET with WTL. Now I am familiar with the framework, I am writing smaller apps in much the same time as I can with MFC -this has got to be a good thing. I will concede that there is a LOT of good MFC code that I couldn't use without doing a WTL conversion - but, in reality, most MFC classes can be made to work with WTL very easily indeed. It isn't rocket science converting most classes - MFC is a pretty thin wrapper around Win32 in many places. I am building up a veritable library of WTL classes - perhaps I'll even post some soon ... :) Don't get me wrong - I love MFC, but I think it has reached the end of its life. Let's face it, there isn't going to me an MFC8 is there? Look how ATL came about - people wanted a framework to allow them to write small COM objects without the bulk of MFC. WTL is the same for UI apps. If anything, WTL is the future for C++ GUI development under Windows (I sure ain't in any hurry to learn C# and jump on that particular bandwagon!). I think MS are surprised at how popular WTL is getting, so I think its future is rosy (and being a light framework consisting of a bunch of header files, even if MS do drop it, someone else will pick it up and move it forward!).
-
I have not yet used WTL in a real application because of the following reasons: Very little or no documentation, known bugs, no doc / view, limited classwizard support, most of the code available is MFC and will have to be rewritten for WTL, and MS does not officially support it and they may pull it at any time. After saying all this, I may still use WTL in my next project because I develop all my applications multithreaded and the design of MFC's doc/view forces you to create all views in the main thread otherwise you will get into a lot of trouble. John
John M. Drescher wrote: Very little or no documentation This situation is improving. There are many sample programs out there that demonstrate all of the available classes. Here are some handy links: http://www.viksoe.dk/wtl/ http://wtl.50megs.com/wtl.htm http://groups.yahoo.com/group/wtl/ Large chunks of WTL use the same class names and method names as MFC (the GDI classes, control classes, etc.). Picking it up is easy once you have a few samples, and the source is very easy to follow. I was cautious too at the beginning - but I played with WTL in my spare time, wrote a few small test apps, and now I am a total convert (as you have no doubt noticed!). John M. Drescher wrote: known bugs Hardly an issue, especially now WTL7 is out. Besides, to apply a bugfix you simply change the appropriate WTL header file - with MFC you need to wait for a service pack! John M. Drescher wrote: no doc / view I came across this "problem" - then I looked at the MFC source for CDocument/CView and realised there isn't much to it. In fact, I think there is a basic WTL doc/view framework available on CodeProject! I can see why this may be cause for concern, but depending on the application, this is not necessarily a big issue. John M. Drescher wrote: limited classwizard support True, though VS.NET goes further and improves this slightly. John M. Drescher wrote: most of the code available is MFC and will have to be rewritten for WTL Probably the main reason more people aren't flocking to use WTL. However, my experience has shown me that it isn't difficult to convert most MFC classes. There are also plenty of "MFC" classes that rely on little more MFC support than CString and/or CWnd - both of which can be duplicated with WTL code easily enough. Besides, as the library grows in popularity, so will the available codebase. John M. Drescher wrote: MS does not officially support it and they may pull it at any time And how exactly does MS "support" MFC? By posting the odd sample on MSDN? MFC is dying - and I believe that any future C++ GUI framework will be more like WTL than MFC. If there is an MFC8 then I will be very surprised (unless it is a bugfix service release ;)). The chances of MS pulling WTL are slim - there are many users now, and because the framework is lightweight, it would be picked up by an eager
-
I have not yet used WTL in a real application because of the following reasons: Very little or no documentation, known bugs, no doc / view, limited classwizard support, most of the code available is MFC and will have to be rewritten for WTL, and MS does not officially support it and they may pull it at any time. After saying all this, I may still use WTL in my next project because I develop all my applications multithreaded and the design of MFC's doc/view forces you to create all views in the main thread otherwise you will get into a lot of trouble. John
John M. Drescher wrote: After saying all this, I may still use WTL in my next project because I develop all my applications multithreaded and the design of MFC's doc/view forces you to create all views in the main thread otherwise you will get into a lot of trouble. MFC is indeed a bitch when you are doing multithreaded GUI development, but it is possible. ED for Windows (see sig) makes extensive use of multithreading, and operations like Find/Replace in Files use multiple threads and create doc/views from those threads. One day when I have some time I really need to write an article or two. Neville Franks, Author of ED for Windows. www.getsoft.com
-
I was looking at Eugene Polonsky's ATL Snapping Framework article, and Ijust have to ask... What is the big deal about WTL? What does it do that MFC doesn't do? (And "code bloat" is not considered a valid response.) What doesn't it do that MFC does? Are the various app/class wizards still available? Does it make development faster? Are your apps faster? Are your apps more reliable? What's the point of the library? Can it be used *with/alongside* MFC? Why should I consider using it? "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 Please review the Legal Disclaimer in my bio.
WTL's greatest strength, from an architectural standpoint, is that it mixes extremely well with the current C++ standard and with ATL. It is hard to compare it directly to MFC, because MFC is a kitchen-sink framework and tries to tackle areas as diverse as COM, HTTP, file handling and database support as well as UI support. WTL is almost completely focused on UI classes only. For someone who's been immersed in MFC for a while and used to it, it probably doesn't look that bad, but MFC has collections, RTTI and exception handling that have all been superseded by the '96 C++ standard. Also, MFC's most egregious flaw is the six- or seven-level-deep inheritance hierarchies that cause so much trouble for new (and old) developers. The C++ community has long since abandoned such thinking as bad practice (and for good reason). WTL makes a clean break from the MFC style by advocating the ATL mixin style of multiple inheritance. Consequently, if you're doing a standard dialog/view, you derive your classes from CDialogImpl. If you want to mixin scrolling support, then you also inherit from CScrollImpl. For dialog resizing support, mixin CDialogResize. The same goes for DDX/DDV support, splitters, printing and idle handling, to name a few. I find it much easier to guide my junior developers toward current C++ best practices under WTL than with MFC. I also find it much better to point developers toward a current C++ book to handle their questions on collections, file handling and exceptions than to explain the clunky MFC approaches. As was mentioned by someone else, WTL is built on top of ATL, so using ATL's COM support is natural. For those projects that require lightweight COM, integrating ATL and WTL is painless. MFC and WTL/ATL are much better integrated in VS.NET than in VS6. There were several posts on the WTL newsgroup about integrating MFC with the old WTL 3.1, but in most cases, the integration wasn't straightforward. When you understand what WTL does well (lightweight up-to-date UI's with a modern C++ approach) and that it's not trying to replace MFC, then it's easier to evaluate it on those merits. What WTL does tackle, it certainly does better. Brandon The WTL newsgroup: over 1400 members! Be a part of it. http://groups.yahoo.com/wtl
