If I want to build a native GUI application on Windows (C++), do I have to use MFC for the UI building framework, or are there other technologies I can use? I know it's a silly question, and the answer is probably, "use MFC or make API calls directly", but I'd like to hear some opinions.
I second that. I've done a good deal of GUI work in WTL, primarily on Windows CE, and we didn't need the MFC for anything.
Dave Van den Eynde
2008-11-04 16:23:36
WTL is great once you know it, but documentation is sparse.
conmulligan
2008-11-04 18:32:32
Docs are sparse but the WTL group on Yahoo ( http://tech.groups.yahoo.com/group/wtl ) is a great community for help with the framework.
Brandon Corfman
2008-11-05 15:32:47
+9
A:
Writing Win32 code in C++ is not that hard, once you have memorized the GDI documentation, a process that should take no more than ten years .. :-)
I would not recommend MFC as a platform -- it offers no real advantages over the "raw" Win32 calls and adds considerable complexity. It also uses a model of OO programming based on older, less featureful, versions of C++.
I have also had reasonable experiences of using ATL to design custom controls (COM controls). You could probably exploit this by creating your app as a control and then making the executable be a simple shell that displays it.
You could look in to wxWidgets or Qt, both of which are C++ and have Windows versions, but will also give you the opportunity to go cross-platform.
pdc
2008-11-04 16:20:33
MFC does make a lot of GUI development easier, its pretty much point-and-click (well, it was in VC6), newer versions of the classwizard do make it a lot harder though. Forget the helper classes etc in MFC though, stick to the GUI parts.
gbjbaanb
2008-11-05 19:21:26
I'm not a fan of MFC. The wizards work well, but I've repeatedly found that as soon as you spent more than about 2 days on a project, you started just passing around HWND's and wishing MFC would get the heck out of your way
Orion Edwards
2008-11-05 19:35:56
I'm not a fan of MFC either but I do challenge the claim that it offers no advantage over raw Win32. In my experience, anything more than a trivial application is *significantly* easier in MFC. Of course I'd prefer wxWidgets or Qt (or gtkmm or FLTK or FOX or anything really!) over MFC.
MattyT
2008-11-06 12:22:47
Actually, that's not such a bad suggestion. I've never used C++ Builder, having a lot of experience from "back in the day". I do remember there were some difference between C++ and Delphi concerning the constructors, which made them a bit awkward in using the VCL from C++.
Dave Van den Eynde
2008-11-04 16:25:43
Constructor issue is not something even worth mentioning IMO. You just can't create Delphi classes on the stack. So, instead of declaring "TButton btn(blabla);" one should do "TButton *btn = new TButton(blabla)". Simple as that.
utku_karatas
2008-11-05 07:50:31
there are issues with object construction order of Delphi vs C++Builder objects, but they're not serious in practice. Also, Delphi constructors can have different names, which they can't in C++.
Roddy
2008-11-05 17:50:11
We used C++ builder (versions 5 and 6) at a previous job - the libraries (VCL) were brilliant and miles ahead of MFC, however the IDE was a pile of rubbish. It would crash, do strange things, and just generally ruin your day. I hope they've improved it!
Orion Edwards
2008-11-05 19:37:46
The issue I had with C++ Builder was that the compiler was terrible when it came to templates and standard library support. It's been awhile though; anyone know if the situation has improved?
MattyT
2008-11-06 12:24:05
+6
A:
I would second Joel's answer of WTL, but also did you know that MFC had a significant update in VS2008? If you don't want to use it purely because of the historically poor support for modern controls and UI styles then you may be pleasantly surprised by the new version. This is an MSDN blog post with some screen shots, and this is a post announcing the final release.
I've just noticed that this MFC update went into VS2008 SP1 too, along with the new TR1 features.
Stu Mackellar
2008-11-04 16:25:00
Is there support for multi-threading? Because historically MFC has been horrible with interaction between threads.
Tim
2008-11-05 19:29:27
A:
If you are planning on sticking with the Windows platform, I would really recommend going the managed route for the GUI at least. Either of WinForms or WPF are really easy to learn an work with. WPF makes it very easy to separate your presentation from the rest of your application, which could be written in either native or managed C++, but at least some of the UI code would have to be done in C#.
C++/CLI makes it very easy to do managed/native interop, with most stuff just working. I would think about running a couple threads (or processes). One dealing exclusively with the UI (especially since WPF is single-threaded anyway), and one managing acces to the backend, and passing messages/data back and forth. This would also help with maintaining UI responsiveness while your business logic is working. WPF fits very well into a command/message passing centered architecture.
Eclipse
2008-11-04 16:53:15
A:
We currently do most of the UI programming in MFC. After attending PDC, I'm thinking we are going to start to try and make the switch to WPF. Basically, WPF gives you much of the power (both hardware acceleration and drawing capabilities) of Direct3D, with a fairly complete control library. If your interfaces between the UI and logic of your application are clean, it should not be too difficult to write the UI in managed code and leave the rest in C++. Although, I do have to say that the recent VS2008 update to MFC did add some nice controls that are not yet available for WPF. However, Microsoft said that many of those controls will be available by the time Visual Studio 2010 ships.
bsruth
2008-11-04 17:04:05
A:
The only problem with doing managed/unmanaged is that you will have transitions in your application.
What I'm trying to access is this: Our application logic is written in C++, we have our calculators, business engine in C++, and I'm trying to decide what UI framework to use. The guy who wrote our engine is not a user interface person, and hense there isn't a user interface. The back end code works, it's been tested and it functions great. My task is to build a UI on top of it.
If using WPF to C++ isn't that difficult in terms of time, sure I'll go that route, but if it's more trouble than it's worth, I'll investigate WTL or MFC.
It's amazing to think that we have come so far in presentation, and yet we still have technologies based on command routing.
ON a side note, are Visual Studio and Office built using MFC? It really makes me wonder what the end game of .NET is. Microsoft is still using C++ (obviously) for the majority of their applications, and probably because the .NET team hasn't created wrappers around the C++ goodness of the OS, fine whatever.
Cheers!
Office is built with it's own display framework, I don't know about Visual studio, but I suspect it would be the same.
Eclipse
2008-11-04 17:31:29
Office is built with MFC, that's why you got a MFC ribbon control well before the managed version (which I think is still in development)
gbjbaanb
2008-11-05 19:23:12
Office is not built with MFC, it's codebase precedes MFC by some margin. The new MFC ribbon control (along with most of the other new stuff) was bought from a third party by MS.
Stu Mackellar
2008-11-05 20:19:43
A:
Tue 11/04/2008 12:47 pm. I've found C++ Builder the easiest way to do Windows GUI programming; that's probably why the product has no future ... but who knows? ... There's a learning curve, but it's surely no harder than the decaying MFC, or nouveau QT etc. You understand, as far as I know, only C++Builder has a two-way graphics composition IDE (see my GUIRAD definition http://home.att.net/~owen_labs/rant10.htm#guirad). ... I wouldn't recommend it for large GUI projects, i.e. don't write the next text editor in it. But for utility programs etc. that need a GUI, I don't really understand why it isn't used more. Of course, it costs a fortune these days; I'm still with version 5 (year 2000).
A:
A year ago I would of said WTL but with the addition of the VS2008 feature pack MFC has a new lease of life.
Rob
2008-11-04 18:11:48
+4
A:
C++ Builder from Codegear is well worth a look.
You get an incredibly mature framework (the VCL Visual Component Library), compatiblity with the huge range of Delphi third-party components, a superb two-way RAD Design environment, and - with the latest version - some C++0x support and Unicode support in the VCL.
Roddy
2008-11-04 18:24:15
A:
My personal opinion (and I worked with a lot of UI design tools) is that you should use Code::Blocks with wxSmith plugin (included by default in the IDE). (Unfortunately?) You need to have the wxWidgets library compiled with the compiler you are using (Code::Blocks supports a lot of compilers: GCC(many flavours), MSVC, Intel, Digital Mars...).
The wxSmith designer is simply awesome (I personally found sizers to be the greatest idea ever made for UI design).
As a conclusion: wxWidgets, nothing else for GUI API and wxSmith from Code::Blocks. They absolutely rock!
Iulian Şerbănoiu
2008-11-05 19:15:50
A:
I think some of the more exciting aspects of development today would be to use the 'alternative' GUI toolkits such as QT or wxWidgets or WTL.
However, if that's not your bag for whatever reason and you have to stick with MS technologies (and you can't/don't want to slap a webby front end onto it - something that could be very promising if you don't need direct server to client communication), then its MFC or WPF. Forget Winforms, nobody wants to use that anymore now WPF is here.
The best way to connect your WPF to C++ code is to make use of hwndSource. This gives you a WPF 'surface' that is hosted inside a hwnd.
It even exposes a lot of MFC hooks so your existing MFC code can be ported to use it "easily". Given that, you might like to go with that to keep your MFC/WPF options open.
gbjbaanb
2008-11-05 19:37:27
+2
A:
Hands down, QT from Nokia. I've used ALL of the above technologies and for ease of use, power and RAD ability, QT has them all beat.
The library is LGPL. And I have bought commercial licenses for my own use. It is that good. I am currently at a place that won't use QT due to the Nokia association. Because of that, I have fallen back to WTL. Doing good UI in Win32, MFC and WTL is painful. As far as frameworks go, they fall to the bottom of the heap. I have been interested in frameworks all the way back to the 90's. I have worked with Borland's OWL, MacApp, Bedrock (look it up, I'll wait), MFC 1.0 to the present, C++ builder, Java AWT and SWING. I contributed to the ET++ framework. I've messed with wxWidgets. I have done .Net Windows forms and recently, WPF and .Net 3.5.
Six years ago, I was introduced to QT and will use QT every time, if given the choice. .Net is slow! If you go to Mono, you will be forced to choose a UI framework. QT is the binding of choice. Mono has Forms, but then your application looks like a Windows application under KDE and Mac. Yuck!!!
Hope this helps.