If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

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.

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

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

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.

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

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.

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.

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

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.

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?

* The Perfect Platform for Game Developers: Android
Developing rich, high performance Android games from the ground up is a daunting task. Intel has provided Android developers with a number of tools that can be leveraged by Android game developers.

* The Best Reasons to Target Windows 8
Learn some of the best reasons why you should seriously consider bringing your Android mobile development expertise to bear on the Windows 8 platform.