View Poll Results: which u prefer in programming

Voters
16. You may not vote on this poll
  • MFC libraries

    5 31.25%
  • plain Winapp

    11 68.75%

MFC vs. WinApp

This is a discussion on MFC vs. WinApp within the C++ Programming forums, part of the General Programming Boards category; hi, I noticed that many people here dont appreciate MFC, while I c it very usefull and helpfull, for example ...

  1. #1
    looking for the truth moemen ahmed's Avatar
    Join Date
    Feb 2002
    Location
    Egypt
    Posts
    161

    MFC vs. WinApp

    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
    Programming is a high logical enjoyable art for both programer and user !!

  2. #2
    Registered User
    Join Date
    Jul 2002
    Posts
    273
    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.

  3. #3
    &TH of undefined behavior Fordy's Avatar
    Join Date
    Aug 2001
    Posts
    5,789
    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...

  4. #4
    Registered User
    Join Date
    May 2002
    Posts
    66
    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.

  5. #5
    Registered User
    Join Date
    Jul 2002
    Posts
    273
    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.
    Last edited by Hershlag; 07-10-2002 at 03:40 PM.

  6. #6
    Registered User
    Join Date
    Jun 2002
    Posts
    151
    > 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?

  7. #7
    Registered User
    Join Date
    Jul 2002
    Posts
    273
    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.

  8. #8
    Registered User
    Join Date
    Jul 2002
    Posts
    273
    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.

  9. #9
    Registered User
    Join Date
    Jun 2002
    Posts
    151
    >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?

  10. #10
    Registered User
    Join Date
    Jul 2002
    Posts
    273
    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....

  11. #11
    Registered User
    Join Date
    Jul 2002
    Posts
    273
    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.

  12. #12
    Registered User
    Join Date
    Jun 2002
    Posts
    151
    >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.

  13. #13
    Registered User
    Join Date
    Jul 2002
    Posts
    273
    "Button" IS a common control genius

  14. #14
    Registered User
    Join Date
    Jun 2002
    Posts
    151
    >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.

  15. #15
    Registered User
    Join Date
    Jul 2002
    Posts
    273
    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"

Page 1 of 5 12345 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. MFC Controls and Thread Safety :: MFC
    By kuphryn in forum Windows Programming
    Replies: 0
    Last Post: 12-06-2002, 11:36 AM
  2. WIndows programming?
    By hostensteffa in forum Windows Programming
    Replies: 7
    Last Post: 06-07-2002, 09:52 PM
  3. Release MFC Programs & Dynamic MFC DLL :: MFC
    By kuphryn in forum Windows Programming
    Replies: 2
    Last Post: 05-18-2002, 07:42 PM
  4. Beginning MFC (Prosise) Part III - Now What? :: C++
    By kuphryn in forum C++ Programming
    Replies: 5
    Last Post: 03-03-2002, 06:58 PM
  5. MFC is Challenging :: C++
    By kuphryn in forum C++ Programming
    Replies: 8
    Last Post: 02-05-2002, 01:33 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21