# Visual studio like app on MFC

This topic is 1750 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hello.

I know that new MFC has an MDI variant with VS 2008 and higher interface with almost the same features and real VS has, but I want to ask a few question regarding this:

1) Could this MFC project by default realize the same behavior for TabWindow control (central window inside app) like the real VS. I mean - that user could drag this tab window out from the main window? Or could this behavior be implemented somehow?

2) Is there some good books for MFC that describe work with MFC feature pack and MFC MDI application in particular?

##### Share on other sites

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.

##### Share on other sites

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.

##### Share on other sites

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.

lol, took out the words right out of my mouth.

Restored post contents from history.

##### Share on other sites

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.

I really wish Microsoft would create an appropriate replacement for it. I always wondered why C++ didn't get some sort of WinForms library. Then again, these days things like Qt are around.

##### Share on other sites

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.

In fact, you can save lots of time, as the OP is attempting to do, by using some of the ready-made stuff in MFC. It's pretty easy to set up a GUI that works exactly like some common MS programs (office, VS) and be done with it.

##### Share on other sites

1) I looked up your question, and it seems that it's possible to do what you want:

http://msdn.microsoft.com/en-us/library/bb983663(v=vs.90).aspx

As for 2), I guess this is pretty much it:

http://msdn.microsoft.com/en-us/library/bb982354(v=vs.90).aspx

The MFC extension pack is based on components by BCGsoft, so looking at their documentation might help a little also.

##### Share on other sites

It's not that terrible.

Yes, it bloody is. Take it from someone who's worked professionally with it for over a decade.

If you only want to target Windows, it's perfectly fine.

So if you're only targeting windows, why wouldn't you use the infinitely better winforms?

MFC is structurally pretty much like wxWidgets, but I never hear people complaining about that being evil.

In fact, you can save lots of time, as the OP is attempting to do, by using some of the ready-made stuff in MFC. It's pretty easy to set up a GUI that works exactly like some common MS programs (office, VS) and be done with it.

Yes, and if you have a legacy code base that uses MFC, that is exactly what you should do. If you're writing new code, use something else and leverage the huge library of code for that.

##### Share on other sites

Yes, it bloody is. Take it from someone who's worked professionally with it for over a decade.

I'm glad that you are talking from experience. Most people who shout "MFC sucks" have never used it extensively. I used to be one of those people myself.

I have worked with it professioanlly for six years. I have alwo worked with other toolkits. They all have quirks that make them suck in some way. Often these ways of suckage are the same as in MFC. Perhaps you could elaborate on what aspects of MFC it is that you think makes it suck so much more than other toolkits?

So if you're only targeting windows, why wouldn't you use the infinitely better winforms?

There could be lots of reasons. 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.

Yes, and if you have a legacy code base that uses MFC, that is exactly what you should do. If you're writing new code, use something else and leverage the huge library of code for that.

I am not completely against using MFC for new projects today. It does make certain types of UI a lot easier to create than any other toolkit. Also, unlike what was claimed in this thread, MFC is just as supported as any other library that comes with Visual Studio, and it is still being actively developed. There also exists excellent third-party components (BCGsoft, CodeJock) for it that have been refined for a very long time, and contain some stuff that really doesn't exist for other toolkits.

Of course, it would not be my first choice, but if the situation and type of application is such that using MFC could save a lot of time, I would at least seriously consider it. Shipping on time is a nice feature to have. Edited by wack

##### Share on other sites

Of course, it would not be my first choice, but if the situation and type of application is such that using MFC could save a lot of time, I would at least seriously consider it. Shipping on time is a nice feature to have.

While I agree that business concerns trumps technical concerns, I'd struggle to imagine any situation where a new project would be better written in MFC than another language/toolkit/framework. The only one I can think of would be if you were doing a small urgent project and MFC was the main skillset on your team.

##### Share on other sites

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.

##### Share on other sites

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 dont 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 dont think that MFC worse than any other modern technology.

##### Share on other sites

If you want VS like interface and do think you'd like to try Windows.Forms, look into WeifenLuo's docking interface. It provides all the VS like behaviour you'd want.

##### Share on other sites

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#.

Edited by BlackJoker

##### Share on other sites

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.

Actually, the UIs of Visual Studio 2010's and Expression Blend are built with WPF, not MFC. Apparently, they did so because you're not the only developer who is skeptical about WPF's usefulness in "real-life work" and Microsoft wanted to prove everyone wrong. ;)

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 dont 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.

##### Share on other sites

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

Edited by BlackJoker

##### Share on other sites

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.

Edited by RobTheBloke

##### Share on other sites

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)