RUNTIME_CLASS macro in MFC -- Good technical notes

keyword:visual C++ runtime_class macro

1. Accessing Run-Time Class Information

This article explains how to access information about the class of an object at run time...

Note::MFC does not use the Run-Time Type Information (RTTI) support introduced in Visual C++ 4.0.

If you have derived your class from CObject and used the DECLARE_DYNAMIC and IMPLEMENT_DYNAMIC, the DECLARE_DYNCREATE and IMPLEMENT_DYNCREATE, or the DECLARE_SERIAL and IMPLEMENT_SERIAL macros explained in the article Deriving a Class from CObject, the CObject class has the ability to determine the exact class of an object at run time.

This ability is most useful when extra type checking of function arguments is needed and when you must write special-purpose code based on the class of an object. However, this practice is not usually recommended because it duplicates the functionality of virtual functions.

The CObject member function IsKindOf can be used to determine if a particular object belongs to a specified class or if it is derived from a specific class. The argument to IsKindOf is a CRuntimeClass object, which you can get using the RUNTIME_CLASS macro with the name of the class.

2. Deriving a Class from CObject

This article describes the minimum steps necessary to derive a class from CObject. Other CObject class articles describe the steps needed to take advantage of specific CObject features, such as serialization and diagnostic debugging support..

3. Specifying Levels of Functionality

This article describes how to add the following levels of functionality to your CObject-derived class:

1. Run-time class information
2. Dynamic creation support
3. Serialization support
For a general description of CObject functionality, see the article Deriving a Class from CObject..
4. Dynamic Object Creation

This is a paragraph.

Technical Notes

5. TN017: Destroying Window Objects

This note describes the use of the CWnd::PostNcDestroy method. Use this method if you want to do customized allocation of CWnd-derived objects. This note also explains why you should use CWnd::DestroyWindow to destroy a C++ Windows object instead of the delete operator.

If you follow the guidelines in this topic, you will have few cleanup problems. These problems can result from issues such as forgetting to delete/free C++ memory, forgetting to free system resources like HWNDs, or freeing objects too many times.

6. TN021: Command and Message Routing

This note describes the command routing and dispatch architecture as well as advanced topics in general window message routing.

Please refer to Visual C++ for general details on the architectures described here, especially the distinction between Windows messages, control notifications, and commands. This note assumes you are very familiar with the issues described in the printed documentation and only addresses very advanced topics..

7. TN023: Standard MFC Resources

This note describes the standard resources provided with and needed by the MFC library.

Standard Resources MFC offers two categories of predefined resources that you can use in your application: clip-art resources and standard framework resources.

Clip-art resources are additional resources that the framework does not depend on, but which you might want to add to your application's user interface. The following clip-art resources are contained in the MFC General sample CLIPART:.

8. TN024: MFC-Defined Messages and Resources

This note describes the internal Windows messages and resource formats used by MFC. This information explains the implementation of the framework, and will assist you in debugging your application. For the adventurous, even though all this information is officially unsupported, you may use some of this information for advanced implementations..

9. TN025: Document, View, and Frame Creation

This note describes the creation and ownership issues for WinApps, DocTemplates, Documents, Frames and Views..

10. TN026: DDX and DDV Routines

This note describes the dialog data exchange (DDX) and dialog data validation (DDV) architecture. It also describes how you write a DDX_ or DDV_ procedure and how you can extend ClassWizard to use your routines.

11. TN028: Context-Sensitive Help Support

This note describes the rules for assigning Help contexts IDs and other help issues in MFC. Context-sensitive help support requires the help compiler that is available in Visual C++..

12. TN029: Splitter Windows

This note describes the MFC CSplitterWnd Class, which provides window splits and manages the resizing of other pane windows.

13. TN030: Customizing Printing and Print Preview

This note describes the process of customizing printing and print preview and describes the purposes of the callback routines used in CView and the callback routines and member functions of CPreviewView..

14. TN031: Control Bars

This note describes the control bar classes in MFC: the general CControlBar, CStatusBar, CToolBar, CDialogBar, and CDockBar..

15. TN035: Using Multiple Resource Files and Header Files with Visual C++

This note describes how the Visual C++ resource editor supports multiple resource files and header files shared in a single project or shared across multiple projects and how you can take advantage of that support. This note answers these questions:

1. When might you want to split a project into multiple resource files and/or header files, and how you do it
2. How do you share a common header .H file between two .RC files
3. How do you divide project resources into multiple .RC files
4. How do you (and the tools) manage build dependencies between .RC, .CPP, and .H files
You should be aware that if you add an additional resource file to your project, ClassWizard will not recognize the resources in the added file.
16. TN070: MFC Window Class Names

MFC windows use a dynamically created class name that reflects the features of the window. MFC generates class names dynamically for frame windows, views, and popup windows produced by the application. Dialog boxes and controls produced by an MFC application have the Windows-supplied name for the class of window in question.

You can replace the dynamically provided class name by registering your own window class and using it in an override of PreCreateWindow. Their MFC-supplied class names fit one of the two following forms:.