Integrating the Rad.net framework in MFC

MFC has a history of more than more than 10 years, but until today, he remains a key component of Visual C + +. Since the 1996 Visual C + + 4.2 so far nearly 8 years, the main features of MFC has not changed significantly, is still the "old" face, so the various comments on this class library is naturally understandable things. From my personal point of view, the MFC function is still robust, strong, and is the industry's rare, stable, long enough history to test the development framework. If you delve into this class library, you'll find that the wine gets more and more mellow. One of the success factors of MFC is to provide a complete set of Document/view framework, but this is also a lot of criticism against the MFC point of view. Perhaps because this frame is too classic, it makes people look like MFC no longer "Tingting Yuli", but "old age", so that the opening of today's visual Studio IDE, how much will be a little uncoordinated feeling: compared to other based. NET Framework development language, with MFC development will appear very "rustic", "lonely"--no rad mechanism, obvious lack of and other fashionable objects "interoperability" ability, and strictly abide by their own territory. Every time we generate a document based MFC program, we always see a vicissitudes of the face, like Grandma Liu into the Grand View garden, and around the fashionable C #, VB. NET, there are obvious "generation gap" and "incompatible". There have been many people asked me MFC still have a future? Are you dead? about whether it is MFC or. NET's discussion. The CLR is a fascinating world, which makes C #, VB. NET and so become dazzling. However, MFC does not age, if you in-depth understanding of MFC, you will find that MFC can be completely with C #, VB. NET Flourish ...

Using Managed Extensions in an MFC project

Support for Managed Extensions

The managed extension support provided by the. NET Framework ensures that the Managed Extensions (CLR) are supported in the MFC project, and that developers can make the MFC project (we will use test as the project name) to increase the managed support for the compiler by opening the Managed Extensions properties switch for the project (Figure 1).

(Figure 1: Open managed compilation support switch)

Dual. NET objects

After you open the Managed Extensions compilation switch, you can use managed objects in your MFC projects, typically by matching a managed object for each important MFC object to form a dual pair, and matching objects that contain pointers to each other, so that the other. NET object can manipulate the MFC object by using the. NET object in dual pair, while other MFC objects can manipulate. NET objects through the MFC objects in dual pairs (Figure 2).

(Figure 2: Dual managed objects)

In Visual Studio. NET, there are no wizards for adding managed C + + class objects, so you can add a Component object based on managed C + + (Figure 3).

(Figure 3. Add Class Wizard: Adding managed C + + component objects

After the Testdocobject managed Component object is added, the object's base class is changed to object, and some code is removed to get a minimal managed class:

namespace test
{
　　__gc public class testDocObject
　　　　: public Object
　　{
　　public:
　　　　testDocObject(void)
　　　　{
　　　　}
　　};
}

Following these steps, the code generated by Visual Studio.NET is loaded into the MFC program, and of course you can manually create. h files and. cpp files, enter the appropriate code, and then add them to the current project. Since the above steps are often encountered in Managed Extensions programming, it is necessary to automate the above process, and for this reason we have provided a complete addition on the attached CD. NET object is Wizard.