MFC sucks

[VirtualAce]

Ok, ok, ok.

So MS didn't like the C++ language the way it was. So they made it 'easier' with crap like this:

/ Overrides
	// ClassWizard generated virtual function overrides
	//{{AFX_VIRTUAL(CMapView)
	protected:
	virtual void OnDraw(CDC* pDC);      // overridden to draw this view
	virtual void OnInitialUpdate();     // first time after construct
	//}}AFX_VIRTUAL

And I've seen afx_msg void Func_name(). Unless afx_msg means virtual...what else is going to go in front of void in a C++ program??

And what the heck is //{{ //}}?

Oh and to create a class with a PROTECTED constructor I don't make the constructor public...I use this:

CRuntimeClass* pRuntimeClass = RUNTIME_CLASS( CMyClass );
CObject* pObject = pRuntimeClass->CreateObject();
ASSERT( pObject->IsKindOf( RUNTIME_CLASS( CMyClass ) ) );

Wow thanks MS, that really clears the air for me.



What the heck is all this garbly gook and how am I supposed to use it? I feel like I'm learning an entirely new language here.
Too many macros.

[pianorain]

I think the ClassWizard uses //{{ and //}} to know where to add more "garbly gook".

I agree. I've been working with MFC for at least six months now, and I still don't get it.

[Exile]

I messed with MFC for a couple of weeks. I got tired or sorting out all the MS crap that gets thrown in there by the wizards and whatnot.

The standard C API calls work fine for making GUI's from what I can tell. They don't seem to look as pretty, but if you tinker enough with the flags and settings you can get then looking pretty good. The only real downside is that withough playing with MFC a lot of the COM and .NET libraries will be a real pain to get working.

Its been my opinion that just about any program that tries to generate code for you just causes problems. Its always some mystifying stuff like that, that mere mortals weren't meant to understand.

[jverkoey]

I can't stand MFC. period. I've dabbled with it a little bit, but there's way too much overhead with it. I prefer just straight Win32 as it gives you probably the best access to the API without having to do anything overly complicated or that will make code unreadable.

[LuckY]

I can definitely relate to the feelings of, well, everyone who's posted so far. I've been using MFC for about 4 years now (self taught) and I was completely lost in the beginning (reading a book helps too), but it's funny because I was never really angry about the complications I was faced with, but of course that's just me. MFC is such a complicated animal because, as you could probably guess, it was built in an attempt to surround the API with OOP while always considering complications with execution.

The //{{ and //}} guys are there for MSVC. Without them the IDE wouldn't know where to add/change/delete the things it sticks in there automatically. afx_msg is there for a similar reason. It might please you best if you simply ignored those things altogether because, generally speaking, you do not need to use those things in any code you write yourself and you shouldn't have to modify any of that stuff directly.

MFC really isn't that bad. What you're experiencing is the effects of trying using AFX and the classwizard, etc. If you were to write an MFC application by hand, without any automatically generated code, you'd see how very simple it really is. In my opinion it is much better than API programming because it provides the same control, but through an interface that is much easier to use. You just have to derive a CAppWin class and you can go from there.

To all the haters:
Don't give up on MFC just yet. It has a lot to offer. Try reading Programming Windows with MFC by Jeff Prosise. You'll be very glad you did. Really.

[okinrus]

Bubba, it's not that hard once you get used to it. There are few classes that are too close to the underlying api. For instance, CDialog is designed poorly, and requires filling in winapi structures. As for your complaint about the RUNTIME macros, MFC uses the them because MFC was developed before runtime type information was added into C++.

jverkoey, MFC runs fairly fast, at least on my computer, and that's really something.... There might be increased size to your program, in both memory and harddisk space, but the benefits compared to the winapi are worth it, I think. Furthermore, what's usually slowing down your program is not the GUI(unless your using Swing), but something else.

[okinrus]

I meant CFileDialog, my bad.

[jverkoey]

jverkoey, MFC runs fairly fast, at least on my computer, and that's really something.... There might be increased size to your program, in both memory and harddisk space, but the benefits compared to the winapi are worth it, I think. Furthermore, what's usually slowing down your program is not the GUI(unless your using Swing), but something else.

Well, I can't say I know what Swing is other than the Java GUI's Swing.....however, I'm perfectly happy with the speed that my win32 programs run and I've created my own classes for win32 which, IMO, work a lot nicer and easier than the MFC ones.

[okinrus]

Well, I can't say I know what Swing is other than the Java GUI's Swing

Yes, Java Swing is what I meant. Because Swing is non-native and implemented in Java, a fairly large swing application will run very slow on my computer.

.....however, I'm perfectly happy with the speed that my win32 programs run and I've created my own classes for win32 which, IMO, work a lot nicer and easier than the MFC ones.

Have you tried wxwindows(wxwidgets)? wxwindows was first written using MFC, but now uses the winapi.

[nvoigt]

While MFC looks ugly and has some minor design uh... core meltdowns, I really can't imagine doing Dialogs in WinAPI. That has to take AGES. Or you have to write your own framework, which is bound to the same mistakes... five more years of C++ experience from now, it will look and feel horribly misdesigned.

Best advice so far in this thread: If it looks like an MFC macro, just don't touch it.

[VirtualAce]

Well I tell all the new graphics programmers to go and buy books if they want to learn anything, so I'm heeding my own advice and have several MFC books on the way.

It won't beat me and I'm gonna learn it if it kills me. I have to learn it in order to create good tools for my games. I realize that .NET probably nullifies all this MFC stuff and I'm probably very late on the scene for MFC...but I still need to learn and master it.

[Darkness]

I hope you don't spend too much time on this stuff because you could instead be spending time working on the other cool stuff you've posted. It might be better to just write game tools in Visual Basic. Some reasons why:

-It's easier to make applications that look better
-It's faster to throw together win32 applications
-When something goes wrong it's easier to find problems in visual basic
-Little 'support' is needed to keep the code working once it's written

To be fair I don't know how 3D graphics run with VB, and if you're doing something like a complex map editor where you need to have a 3d representation, then it might suck.

[jverkoey]

I really can't imagine doing Dialogs in WinAPI. That has to take AGES. Or you have to write your own framework, which is bound to the same mistakes... five more years of C++ experience from now, it will look and feel horribly misdesigned.

That's why visual studio's resource editors rock, heh. All forms I make, I just draw using visual basic's tools. The only code I have to do that involves positioning the actual controls is putting the code in in the case that I allow the window to be resized, in which case I have to take in to account the new size and size the window accordingly.

[VirtualAce]

I made my first tools in VB and wanted to call my engine DLL from VB but really had no idea about how to go about mixing the two languages. The core engine DLL is all I need and it only needs to know what objects are on the map and their orientation. When someone places an object I would simpy create that object and add it to the vector. Since that object is the selected object I would flag it somehow and the engine DLL would draw a 3D wireframe cube around it indicating that item is the current selection. Multiple objects would just be a matter of flipping flags or booleans.

However there are a lot of issues to deal with as I make the editor. Syncing the two applications and sending messages from my editor to the DLL is not a trivial task. There are many approaches to take, but I'm currently undecided about all of them.

It is a big test of my programming skills because I need to combine Windows GUI with windowed Direct3D and also track the mouse in 3D space when it is in the render window.
I've used several map editors for current games out there now so I have a good idea about what needs to be done. I want to make it as simple as possible to create missions and/or levels that my engine can use. I also want to support custom vertex and pixel shaders and allow the tool to switch shaders and apply the switch local to any object. How it looks in the editor is how it will look in the game. I would also like for the editor to allow the user to script an entire DirectX effect file complete with techniques, vertex shaders, and pixel shaders. The editor would then compile it and then compile it into a resource format of my own choosing. It can get quite complex if you think about all that has to be done.


But...as I said this is a major challenge...however without it my game can only progress so far. Right now it's screaming at me that it needs some tools.