If you use something already existing for a GUI then sooner or later (Usually 48 hours) you will get stuck with something it can't do. I would just make my own GUI framework based on a frame/panel. A tree structure can store the recursive behaviour for how it resize everything according to the window. For each panel, calculate the dimensions of each child panel and tell them to resize their children. When dragging a panel, show 5 icons on each other panel where it can be released. Move it to be a new child to that panel with it's location given by the icon that you moved it to.

http://my.opera.com/adelamro/blog/win32-docking-system

Thirst of all thanks to wack for clear and direct answer to my questions.

Second - I use MFC because it provide interface in VS 2008-2012 style which is the best interface for IDE, which I actually start developing now.

Using MDI MFC application is much better than WinForms MDI application which don`t have such suitable interface till nowadays. I am not talking about WPF which not allow MDI legally at all. And if you remember that all native Windows application like VS, Office and other develope using MFC, you will understand that it is the best practice fro Windows developing a complex MDI applications.

By the way, in WinForms(which actually in same state as MFC) or WPF you just cannot do some specific things which you can do on C++ and to do them, you need to go deeper.

So, I don`t think that MFC worse than any other modern technology.

May be so, OK. But this is not default behavior and needs to be integrated to VS. I already had some trouble with 3rd party controls which has their own bugs, incorrect behavior and bad support, so I want to use native MS technologies. Besides, I wrote my engine on Win32 so, it would be more suitable to connect C++ to C++ than C++ to C#.

And if you remember that all native Windows application like VS, Office and other develope using MFC, you will understand that it is the best practice fro Windows developing a complex MDI applications.

By the way, in WinForms(which actually in same state as MFC) or WPF you just cannot do some specific things which you can do on C++ and to do them, you need to go deeper.
So, I don`t think that MFC worse than any other modern technology.

I have built the first version of my RPG game editor with MFC before switching to .NET/WinForms. The only thing MFC has that I miss in WinForms is WM_CMDUI and maybe updating widget controls directly in member variables because I'm not a fan of data binding in WinForms. (It looks better suited for database binding than objects.)

I'm a big defender of MFC, and I really think it's not as bad as people make it out to be. It might not be a marvel of software engineering, but it has been powering applications since 1992. If I have to build a Win32 GUI application in C++, I'd rather use MFC than Qt, for example.

But as much as I like MFC, I find its range of use cases very narrow. Big commercial applications that need native speed and responsiveness (like Adobe Reader) are typically built in Qt because cross-platform is becoming increasingly important. Business applications and internal enterprise tools are built in .NET or Java because who needs C++ to build a bunch of text boxes bound to a database table? Microsoft is starting to use WPF and WinRT for Windows-specific with rich UIs. Games only need a blank window so just learn how to make one using the Win32 API. I wouldn't be surprised if Visual Studio 2014 does not support MFC.

If so, I cannot understand how VS with all amount of components use so little memory? I wrote not big WPF applications and during work they use near 100 MB of memory. VS is very huge application an it use only ~ 300-400 MB. How could that be if it created using WPF (C#) or they use it only for face and C++ for "background"?

By the way, this info suggests otherwise:

http://blogs.msdn.com/b/vcblog/archive/2012/03/05/10278210.aspx

Please don't use MFC for new code.

It's ancient, unsupported, non-idiomatic C++, and full of evil pitfalls and gotchas. It really needs to just go die in a corner somewhere.

It's not that terrible. If you only want to target Windows, it's perfectly fine. MFC is structurally pretty much like wxWidgets, but I never hear people complaining about that being evil.

It is so beyond terrible it's not funny, and wxWidgets is the only GUI library known to mankind that is noticeably worse. I've got many wx-related 'tales of horror from the trenches', but I'm not going to go into details. It took years of counseling before I was able to forget about those poor souls who died by the millions in the trenches alongside me, and it's an experience I do not want to be reminded of!

Seriously, use windows.forms or Qt.

Perhaps you could elaborate on what aspects of MFC it is that you think makes it suck so much more than other toolkits?

Because it's C++ only, and it's so limited in it's scope, it's just plain retarded in comparison to the competition. With Qt, you can put together the core app in C++, but then quickly add huge swathes of GUI code using one of the many script bindings for it (e.g. pyQT). With windows.forms, you can do the same thing using C#/VB/python (via the CodeProvider classes). All of this allows you to create, modify, and test the GUI at runtime, which makes the turnaround time for adding new features to your app many orders of magnitude quicker. In Qt, you've got extensive support for OpenGL and OpenVG, so it's trivially simple to knock up a custom node-editing framework, or any other visually appealing UI you can think of. Both Qt and windows.forms have an extensive community behind them, so there are many actively developed extensions available (again, cutting down your dev time). Qt is cross platform, unlike MFC and wxWidgets. Yes I know wx claims to be cross platform, but in reality that means a basic dialog with a few basic controls. As soon as you do anything mildy complex, you soon realise that you're going to have to rewrite most of it to make it work on say linux. The X version of wx is missing a huge number of features, so much so, that the best options for wx on linux is to use the Win32 version, and link it against the WINE libraries. This means you'll be (mostly) restricted to Windows 95 controls, which means you'll be missing localisation support due to a lack of wide string support. Once you encountered THESE things, you'll understand why everyone is saying that wx and MFC are a pile of shit. It's not because we're being arsey, it's because they truly are a pile of stinking shit, and they need to be left to fucking die.

Perhaps you want write all of your program in one language? It's not like it's an order of magnitude more difficult to use MFC than to use winforms.

If you really think that writing user interface code in C++ is a good idea, you need therapy. I'd suggest trying some C# for a bit, look at the C# CodeProvider classes, and understand the benefits of being able to write your GUI code from within your application, whilst it is running.

Most people who shout "MFC sucks" have never used it extensively.

I have used it extensively, and have also used wx, Qt, and windows forms to the same degree. If I was about to embark on writing an app from scratch, I'd use winforms for personal projects (or projects that I know will only ever need to target windows), but I'd use Qt if there was even a wiff of the possibility that the app may need to be cross platform one day.

If so, I cannot understand how VS with all amount of components use so little memory? I wrote not big WPF applications and during work they use near 100 MB of memory. VS is very huge application an it use only ~ 300-400 MB. How could that be if it created using WPF (C#) or they use it only for face and C++ for "background"?

Microsoft Visual Studio is not monolithic. It's a mish-mash of multiple technologies that have been accumulated over years, some programmed directly against the Win32 API, some programmed in COM, others in .NET, OLE, ActiveX, etc. Visual Studio .NET added a lot of managed code, (AFAIK the WinForms editor is run by managed code), but there's no way Microsoft could afford to rewrite the entire developer suite in .NET.

Visual Studio 2010 is still using all these native components. What was remade was the entire presentation layer in WPF, whcih had to be re-written in managed code. Due to the large native codebase the VS team inherited, they had to hook the main loop in C++/CLI to dispatch the messages to the native components that need i, but the user-interaction code remains largely WPF and .NET. Microsoft has made a presentation about how they converted Visual Studio to WPF. (ie: http://www.microsoftpdc.com/2009/CL09)

Very interesting presentation, but I cannot understand how they could do so and WHY they don`t provide in WPF that MDI framework which they use to create VS dockable UI, but provide that in MFC???