MFC vs. WinApp

**moemen ahmed** · 07-10-2002

hi,
I noticed that many people here dont appreciate MFC, while I c it very usefull and helpfull, for example MFC gives you the ability to treat the messages from windows os effectivly with almost no great effort, while u ve to write WinMain() to catch the messages and then wright ur own WinProc() with a huge switch statement to respond to the varios messages ..

I would like to discover what do u think about using MFC , and I like to read long explanations full of details supporting ur opinion

thanks in advance

**Hershlag** · 07-10-2002

the "message map" IS a switch statement. it's just hidden behind macros. I have never found the message map idea to be any easier than just writing the function. it's just about as much code. MFC has a lot of down side. for one, you have a versioning problem because exported classes are a no-no. Name mangling was never standardized and as a result MFC is painfully version dependant. so you application has to distribute it's own version of MFC or you aren't guaranteed that it will work. As I stated above though my main reason for not using MFC is it actually isn't any easier.

**Fordy** · 07-10-2002

Originally posted by Hershlag
the "message map" IS a switch statement. it's just hidden behind macros. I have never found the message map idea to be any easier than just writing the function. it's just about as much code.

Its actually a little more clever than that in the way it passes the messages down to the classes it derives from........but yeah it does a similar thing....

Originally posted by Hershlag
MFC has a lot of down side. for one, you have a versioning problem because exported classes are a no-no. Name mangling was never standardized and as a result MFC is painfully version dependant. so you application has to distribute it's own version of MFC or you aren't guaranteed that it will work. As I stated above though my main reason for not using MFC is it actually isn't any easier.

If you have a decent version of VC++ you can statically link the MFC runtime code....but this does give a bit of a code bloat..

Personally I prefer MFC for GUI as I find it much faster to produce a standard window (and its added dialogs, menus,controls etc...)....I cant see how it is as tedious as creating a window "SDK style"....but then each to thier own...

**achacha** · 07-10-2002

I use MFC a lot, it's not for the feint of heart, but a lot better than writing a WinApp. I have not had any real problems with MFC or MFC DLLs while going through version 5, 6 and not 7 of MSDEV.

I think MS did a great job of writing a set of foundation classes for windows. And personally I think MFC is way ahead of any other class library on the market for writing Windows applications.

**Hershlag** · 07-10-2002

I have always hated how C++ guys think they have to use MFC. I do object oriented WinAPI coding all the time. As far as the "cleverness" of the message map goes.... Here's how I determine which class I'm in for Win32 API C++ coding:

Code:

long APIENTRY WindowProc(HWND hWnd, UINT iMessage, WPARAM wParam, LPARAM lParam)
     {
     ClassName *This = (ClassName *)::GetWindowLong(hWnd,GWL_USERDATA);
     if(iMessage==WM_CREATE)
          {
           CREATESTRUCT *cs = (CREATESTRUCT *)lParam;
           ::SetWindowLong(hWnd,GWL_USERDATA,(long)(This = (ClassName *)cs->lpCreateParams));
          This->m_hwnd = hWnd;
          }
     return This?This->CallBack(iMessage,wParam,lParam):0;
     }

This makes Callback() your "Message Map" and it works well. This is no harder than learning acres and acres of MFC macros.

**Enmeduranki** · 07-10-2002

> I do object oriented WinAPI coding all the time.

Is it possible to encapsulate all message handlers for child windows within their own class (rather than having a parent class handling them), using WinAPI? I've not really looked into it but this is often brought up as a reason why C++ and straight WinAPI don't mix. How do you know when writing the parent class, that it's going to have to handle the messages of child classes that may not have been written yet?

**Hershlag** · 07-10-2002

Enmeduranki, it is absolutely possible and in fact critical to make all windows into objects. It is a natural way of windows programming. Of course parent windows will need to be notified of certain actions such as button clicks but that is why you used a button in the first place, to notify the parent of an action to be requested in that window.

All windows with callbacks can be encapsulated nicely. All children can have their own encapsulation.

**Hershlag** · 07-10-2002

Originally posted by Enmeduranki
I've not really looked into it but this is often brought up as a reason why C++ and straight WinAPI don't mix.

This is unfortunate. Please tell whoever told you this that MFC is an encapsulation of the Win32API and therefore a "mix" of C++ and WinAPI. So if they were arguing for MFC on this point they should be put to sleep.

**Enmeduranki** · 07-11-2002

>Of course parent windows will need to be notified of certain actions such as button clicks but that is why you used a button in the first place, to notify the parent of an action to be requested in that window.<

This is not encapsulated. A child class should handle it's own messages. How would you develop a library of self contained child controls (based on the existing common controls) that can be 'plugged' into an application?

**Hershlag** · 07-11-2002

you are not understanding encapsulation then. Let's focus on buttons since that seems to be the easiest. Encapsulation means you can do something like this:

Code:

Button mybutton;
mybutton.CreateWnd(parentwnd, x, y, w, h, "text");

and be done with it without calling any API directly. Here's the way it would work...

parameters:
parentwnd is needed cause the button needs to know where it is created (true in MFC of course). x, y, w, h is obviously positioning info on the parentwnd, "text" is obvious.

Let's pretend that the button text is "Exit" and it means the window needs to be closed. obviously this is an action intended for the main window. Therefore it is a message sent to the parentwnd and NOT the buttonwnd. The button window will handle those appropriate to itself but messages sent to the parent are OBVIOUSLY (to any reasonable person) still within the bounds of the object oriented encapsulation.

I understand what you are trying to do. You are attempting to say that the button class itself should handle the click. Not true. How should he exit the parent window if it is handled internally. That's just nonsense.

COM has an example of this sort of thing (parent being called by child) It's called events. Get used to it. It's within the bounds of reason for C++ and does not break from proper encapsulation.

Think... Think... Think....

**Hershlag** · 07-11-2002

I believe I know why you are confused on this one. Messages appropriate for the encapsulated window would be handled in that class. Messages appropriate for the parent window would be sent to the parent class. Thus the encapsulation of messages is present I think that's what you are after. but windows MUST send messages to eachother in some form otherwise how could a parent know that his button did something? how could he know to close in an exit button? Notification is after all the purpose of a button.

**Enmeduranki** · 07-11-2002

>Let's focus on buttons since that seems to be the easiest<

No, lets not. Let's focus on a common control, as stated in my last response.

Thanks for the encapsulation lesson anyway.

**Hershlag** · 07-11-2002

"Button" IS a common control genius

**Enmeduranki** · 07-11-2002

>Messages appropriate for the parent window would be sent to the parent class. Thus the encapsulation of messages is present I think that's what you are after.<

Yes, but you don't have the choice. If you want the listbox, button, etc to be self contained it's not possible. How would I create a class to list and run execs using the standard list box. No message needs sending to the parent window. Using the API, every time I create an application and want to use my custom list box based class I've either got to re-type or copy/paste the code that that should be handled by the child to the parent.

>but windows MUST send messages to each other in some form otherwise how could a parent know that his button did something?<

Why does the parent need to know? I'm not disputing that some messages need to be passed between windows, but that messages are passed to the parent even though they could (and should) be handled by the child. This breaks encapsulation.

>"Button" IS a common control genius

Sorry, you're correct. But your example is fudged. If the message is intended for the parent, of course it doesn't break encapsulation. However, in your over-eagerness to use a 'simple' example you completely missed the point.

**Hershlag** · 07-11-2002

no I didn't miss the point. What you're not understanding is that common controls messages are never seen by us. they are hidden in windows dll's and handled inside windows dlls. What you're probably looking for is CUSTOM controls where we actually have our own message handling.

one of my initial replies handled that issue. all messages intended for a particular window would be handled nicely by that window's object. "encapsulated"

View Poll Results: which u prefer in programming

Thread: MFC vs. WinApp

Thread Tools

Search Thread

Display

MFC vs. WinApp

Similar Threads

MFC Controls and Thread Safety :: MFC

WIndows programming?

Release MFC Programs & Dynamic MFC DLL :: MFC

Beginning MFC (Prosise) Part III - Now What? :: C++

MFC is Challenging :: C++