CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Results 1 to 8 of 8
  1. #1
    Join Date
    Sep 2005
    Posts
    336

    [RESOLVED] Event-driven programming in MFC and VC++.NET

    Nowadays i am trying to learn VC++.Net and MFC.But I know c# well.
    Here i see that MFC's event-driven programming is differnet from VC++.NET
    For example button click in .NEt win. app.:
    Code:
    	private: System::Void button1_Click(System::Object^  sender, System::EventArgs^  e) {
    			 }
    	};
    //and its event:
    this->button1->Click += gcnew System::EventHandler(this, &Form1::button1_Click);
    but in MFC:
    Code:
    void CAboutDlg::OnBnClickedOk()
    {
    	// TODO: Add your control notification handler code here
    	OnOK();
    }
    // and message map:
    BEGIN_MESSAGE_MAP(CAboutDlg, CDialog)
    	ON_BN_CLICKED(IDOK, &CAboutDlg::OnBnClickedOk)
    END_MESSAGE_MAP()
    I see that these are different style, differnet paradigm.I am not well if wrong please correct it.

    And .net version is like c# application.Preparing form, initialing toolbox, user write methods that when event is occured.This is much user friendly and much simplier than mfc's messagemaps.

    Do you have any plans to use this style in mfc or native(unmanaged) windows applications.If this is not possible can you give me please its reasons.

    I am looking for your answers.
    Thanks.

  2. #2
    Join Date
    Jun 2006
    Posts
    17

    Re: Event-driven programming in MFC and VC++.NET

    Your question is probably more an issue of frameworks than native vs. managed code. You're right on that WinForms' delegates and events make for a nicer programming model than MFC's message maps. It's unlikely we would invest in the significant work required to modify MFC to support WinForms-like eventing as well as message maps. Your question does touch on native vs. managed code in that delegates and events are C++/CLI features which are not supported for unmanaged C++ classes. We don't have any plans at the moment to support these features outside of C++/CLI managed classes.

    It is worth noting that you can mix MFC and WinForms code in Visual C++ 2005 if you want to get the best of both worlds, with compatibility with existing code and a more modern framework architecture.

    Thanks,

    Steve Teixeira
    Visual C++
    Last edited by steixeira; June 19th, 2006 at 11:50 AM.

  3. #3
    Join Date
    Jun 2006
    Posts
    3

    Thumbs down Re: Event-driven programming in MFC and VC++.NET

    Quote Originally Posted by steixeira
    It is worth noting that you can mix MFC and WinForms code in Visual C++ 2005 if you want to get the best of both worlds, with compatibility with existing code and a more modern framework architecture.
    Steve, as an observer of the Visual C++ 2005 Express Edition forum on MSDN, I notice that (along with the absence of MFC), it is very difficult to know and understand how the worlds can safely be mixed, especially around the different data types (handles and arrays come to mind) between the native C/C++ world and the C++/CLI world where there are more than framework differences.

    This seems particularly problematic for beginners who want to use VC++ to get to building Windows applications right away. Is there any guidance on how to unconfuse this situation? (My approach is to suggest that if they want to get to Windows applications quickly, use VC# first, but that doesn't satisfy all thirsts for VC++).
    Last edited by orcmid; June 19th, 2006 at 12:01 PM. Reason: Added omitted word

  4. #4
    Join Date
    Sep 2005
    Posts
    336

    Re: Event-driven programming in MFC and VC++.NET

    Thanks Steve

    C++ is nearly common language for desktop applications.In ERP or database or in web applications i see that developers choose C#.Because c# and .net technology is really perfect.

    But in desktop applications no one write code with C# or c++.net.I see that there are 3 reasons:
    1-)Desktop app. is really hard and must use some so many pinvoke.So developers of course choose c++
    2-)Performance
    3-)Decompiling

    And the most important issue decompiling.If you do not stop deceompiling no one will write code wit c++.net.

    I said for database and web app. c# is perfect no one choose c++.But for desktop app. everyone must use c++ because i gave reasons.

    DO you have any plan to stop decompiling.If you have no plan i can say: C++.NET will not have any role for developers.No one choose it because there are no positive reason.Also developers know that everone see their codes.

    So i want you 2 things:
    you said you have no plan but you must change mfc format to event-delgate format and please solve decompiling problem.

    What do you think about my 3 reasons especially decompiling problem?

    Thanks again.

  5. #5
    Join Date
    May 1999
    Location
    ALABAMA, USA
    Posts
    9,917

    Re: Event-driven programming in MFC and VC++.NET

    Quote Originally Posted by sawer
    Here i see that MFC's event-driven programming is differnet from VC++.NET
    That is because MFC programming is not event driven but message driven. MFC very closely encapsulates Windows API.
    Windows program (executable) has two major parts: WinMain, an entry point and WindowProcedure that processes all messages that are sent by OS to a window notifying for example about need to repaint part of the window, about mouse moving over, mouse click, keyboard input, resizing, etc.
    I think it was very unfortunate and confusing when with VS 2002 MS introduced tetrm "Insert Event Handler" instead of "Insert Message Handler".

    In a nutshell:
    In MFC all messages are mapped into a message map using macros that extend to (In nutshell) an array of static array of structures containing message information and handler functions information.
    All of the above is completely transparent in higher level languages that handle messages by using event mechanism.
    There are only 10 types of people in the world:
    Those who understand binary and those who do not.

  6. #6
    Join Date
    Jun 2006
    Posts
    17

    Re: Event-driven programming in MFC and VC++.NET

    orcmid: Yes, it can be difficult for beginning to understand where to use native and managed code and how to interoperate between the two. We know this is an issue and strive to continuously improve in this area.

    sawer: .NET binary code is comprised of MSIL and attributes which can be decompiled back into source code in a fairly straightforward manner. This is the case no matter what language is used to create the .NET code. Some developers choose to use obfuscators to make their code more difficult to decompile.

    Thanks,

    Steve Teixeira
    Group Program Manager
    Visual C++

  7. #7
    Join Date
    Dec 2005
    Posts
    16

    Re: Event-driven programming in MFC and VC++.NET

    Quote Originally Posted by steixeira
    You're right on that WinForms' delegates and events make for a nicer programming model than MFC's message maps.
    I don't agree with you. The MessageMapFunctions union might not be 'nice', but as already said in my other post (Mfc.net) it's more powerful.


    Quote Originally Posted by steixeira
    Your question does touch on native vs. managed code in that delegates and events are C++/CLI features which are not supported for unmanaged C++ classes.
    Delegates would be easily possible in native code if casted member function pointers could be invoked. But although VC++ uses non-standard member function pointer delegates are still possible. Are any improvements planned for member function pointers?


    André

  8. #8
    Join Date
    Aug 2005
    Posts
    23

    Re: [RESOLVED] Event-driven programming in MFC and VC++.NET

    Please see http://www.codeguru.com/forum/showthread.php?t=391460 for the Orcas future plans. Feel free to add your suggestions there.

    Thanks,
    Ayman Shoukry
    Program Manager
    VC++ Team

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  





Click Here to Expand Forum to Full Width

Featured