Beef Up Windows Apps with the Visual C++ 2008 Feature Pack

7 Comments

• It's such a shame this stuff is for MFC. If it was Win32-API style C then everyone could use it, using any language that they can already use to write Windows apps, including MFC (with a very simple wrapper) if that's what someone wants to use.
  
  Since it's MFC only a subset of people can use it and many people hate MFC for complex GUIs as it obfuscates things and actually makes life more difficult once you move beyond a simple app. :( (I use MFC for little dialog-based apps but, having tried a few times, I would never go near it again for anything complex.)
  
  I wish MS would move the people writing non-standard UI elements for Office into the Windows team so that those GUI controls are part of the entire platform. I'm sick of every Office release breaking all the UI rules just to make itself look new an the previous version look old, and then other programs being expected to mimic Office (but always slightly differently) so that they don't look old. The company that owns the platform owns the code to the real Office UI controls and (if they are written generically enough) could let everyone use the real thing. UI consistency on a given OS platform is so important and yet so neglected on Windows.
  
  It seems mad that MS bought a 3rd party MFC emulation of their own controls, too.
  

• Leo Davidson: Thanks for the comments. Historically Microsoft has pioneered new user experience paradigms in Office (e.g. toolbars and property sheets). The lifecycle looked something like this:
  1. Office introduces control X
  2. Then the next version of MFC includes an emulated version of control X.
  3. Then the next version of Windows includes a win32 common control for X.
  4. Then the next version of MFC replaces their implementation of X with a win32 common control wrapper.
  Personally I don’t use MFC either preferring ATL/WTL but it seems clear that there are still many more MFC developers out there so Microsoft spent their money where it would help the most number of (native) customers in the short term.
  In the longer term I expect to see a native implementation provided by the Windows shell team, perhaps in Windows 7 (just speculating here). I also expect to see a WPF version at some point. At that point everyone will be able to use a standard and consistent implementation from their favorite programming environment.
  

• Just seems odd to me to make something only for MFC users -- even if there are a lot of them -- when it could just as easily be made for everyone (including the MFC users).
  
  Of course, this assumes someone has written such a thing or that MS want to write it themselves. I realise in this case that MS bought an MFC control off the shelf from a 3rd party.
  
  Which leads me to what I suppose is my real question: Why are so many 3rd parties only making MFC controls to sell to people, instead of making controls which can be used by all Win32 languages? :( Writing a straight Win32 API control is no more work than an MFC control, and writing an MFC wrapper around that is trivial, so why go the MFC-only route and exclude part of the market? Perhaps they think that only MFC users will buy controls but that's definitely not true.
  
  It's pretty horrible the way UI controls and look & feel are so fragmented in Windows, and new UI frameworks seem to come out of Microsoft every couple of years while the old ones wither away and die. It's unfortunate that the one many of us really wish would die (MFC) is instead getting new life. :)
  

• Kenny,
  I was wondering if the following usage of the polymorphic functor you mentioned in your article is correct:
  
  function f = AddFunctor();
  
  Somehow it is a bit confusing syntax to me. I would think I would need an object of AddFunctor type first:
  
  AddFunctor myFunctor;
  function f = &myFunctor();
  

• Arnošt Löbel: It’s correct. The beauty of the function class template is that it encapsulates everything that is required to call the function so there’s no need to carry around an additional "context" for the call. In your example you would now need to worry about the lifetime of the myFunctor variable.
  

• Thanks for the answer. I guess I will just have to learn the new tricks :-)
  As for the life-span of myFunctor, I guess I ought not need to worry if the () operator in myFunctor was not virtual and would not be using any members of the class. That, actually, should apply to your new syntax as well, shouldn't it? Since you do not have an actual object, the functor's method cannot be virtual and cannot use members of an instance of its class, correct?
  

• Arnošt Löbel: why do you say there isn't an actual object? It employs value semantics. In the first example it would basically copy construct (conceptually). There's a great deal of value (excuse the pun) in using functors for the very reason that they can carry state. But please give it a try yourself. There's no better way of learning!