[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.

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++

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++).

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.

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.

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++

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é

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