title: Alternative to MFC
body: <p><a href="https://stackoverflow.com/questions/149698/what-is-a-good-mfc-starting-book">https://stackoverflow.com/questions/149698/what-is-a-good-mfc-starting-book</a></p>
  
  <p>A lot of the upvoted comments claim there are much better alternatives.  I'd like to know what they might be.</p>
  
  <p>My main requirement is that the UI use the native widgets so that our automation software can work.  Owner drawn windows are much harder to drive.</p>
  
  <p>I'm not particularly liking the design of MFC so an alternative would be good.  Only one I've found is WX, which is the one we've already tried and are considering abandoning.  We need something that doesn't force us to fight with a bunch of cross-platform wrapping we don't care about.  We're writing a Windows application and marketing doesn't give one single crap about targeting Mac or Linux (yeah, it makes my butt hurt too).</p>
  
  <p>I've looked at the .NET option a little bit.  Problem is I don't know much about it but from what I can tell we'd have to use C# to get a lot of the options readily available with MFC.  The C++/CLI toolkit doesn't seem to have docking windows on first glance for instance.  In fact, a straight up WinFroms option doesn't seem to either.  It looks like we'd have to make a WPF project and that doesn't appear to be at all what we really want (and we'd have a huge bunch of crap to learn besides just another toolkit).  Moving out of C++ would also require a lot of wrapping and I don't particularly like the results I've seen from automated wrappers.</p>
  
  <p>The other issue I have with the .NET option is that we've got a pretty drawing intense application (in addition to requiring a lot of forms).  I know that you can get similar results with JIT languages like .NET but I also know you've got to be a lot more careful to do so.  It's an issue I'd like to avoid worrying about at this time.</p>
  
  <p>The other, and probably most important issue with .NET (at least switching languages) is that we've got a huge supply of interface logic that though should be API agnostic, is very much written in C++.</p>
  
  <p>So what are the other options?  Do these people really have points or are they just yelling against anything that isn't their favorite language or toolkit?</p>
  
  <p><b>NOTE:</b><br>
  What is the issue here??  I said specifically that porting to other platforms is NOT even remotely a consideration and that I HAVE TO HAVE something that uses the native widget set so we don't have to completely change everything that testing uses to automate the product!!!!  Did anyone actually read my question?</p>