For local function variables, this scope transition happens when the function exits, but the scope of a frame variable can be smaller than a function if nested braces are used. This automatic deletion of frame variables is very important. In the case of simple primitive types (such as **int** or **byte**), arrays, or data structures, the automatic deletion simply reclaims the memory used by the variable. Since the variable has gone out of scope, it cannot be accessed anyway. In the case of C++ objects, however, the process of automatic deletion is a bit more complicated.

The heap is reserved for the memory allocation needs of the program. It is an area apart from the program code and the stack. Typical C programs use the functions **malloc** and **free** to allocate and deallocate heap memory. The Debug version of MFC provides modified versions of the C++ built-in operators **new** and **delete** to allocate and deallocate objects in heap memory.

When you use **new** and **delete** instead of **malloc** and **free**, you are able to take advantage of the class library's memory-management debugging enhancements, which can be useful in detecting memory leaks. When you build your program with the Release version of MFC, the standard versions of the **new** and **delete** operators provide an efficient way to allocate and deallocate memory (the Release version of MFC does not provide modified versions of these operators).

|ID_CANCEL_EDIT_CNTR|VK_ESCAPE|**VIRTKEY**|

The second change is to create a new accelerator table that corresponds to the new menu resource created for in-place activation. This table has entries for the File and Window menus in addition to the VK_ESCAPE entry above. The following example is the accelerator table created for in-place activation in the MFC sample [CONTAINER](../visual-cpp-samples.md):

|ID_FILE_NEW|CTRL+N|**VIRTKEY**|

|ID_FILE_OPEN|CTRL+O|**VIRTKEY**|

|ID_FILE_SAVE|CTRL+S|**VIRTKEY**|

|ID_FILE_PRINT|CTRL+P|**VIRTKEY**|

|ID_NEXT_PANE|VK_F6|**VIRTKEY**|

|ID_PREV_PANE|SHIFT+VK_F6|**VIRTKEY**|

|ID_CANCEL_EDIT_CNTR|VK_ESCAPE|**VIRTKEY**|

|IDP_OLE_INIT_FAILED|OLE initialization failed. Make sure that the OLE libraries are the correct version.|

|IDP_FAILED_TO_CREATE|Failed to create object. Make sure that the object is entered in the system registry.|

|IDR_MAINFRAME|Used in an MDI application if no file is open, or in an SDI application regardless of open files. This is the standard menu used in non-OLE applications.|

|IDR_\<project>TYPE|Used in an MDI application if files are open. Used when an application is running stand-alone. This is the standard menu used in non-OLE applications.|

|IDR_\<project>TYPE_SRVR_IP|Used by the server or container when an object is open in place.|

|IDR_\<project>TYPE_SRVR_EMB|Used by a server application if an object is opened without using in-place activation.|

For an example of these accelerator table changes, compare the IDR_HIERSVRTYPE_SRVR_IP and IDR_HIERSVRTYPE_SRVR_EMB accelerator tables with IDR_MAINFRAME in the HIERSVR.RC file included in the MFC OLE sample [HIERSVR](../visual-cpp-samples.md). The File and Window accelerators are missing from the in-place table and exact copies of them are in the embedded table.

|IDP_OLE_INIT_FAILED|OLE initialization failed. Make sure that the OLE libraries are the correct version.|

This includes primarily those messages beginning with the **WM_** prefix, except for WM_COMMAND. Windows messages are handled by windows and views. These messages often have parameters that are used in determining how to handle the message.

This includes WM_COMMAND notification messages from controls and other child windows to their parent windows. For example, an edit control sends its parent a WM_COMMAND message containing the EN_CHANGE control-notification code when the user has taken an action that may have altered text in the edit control. The window's handler for the message responds to the notification message in some appropriate way, such as retrieving the text in the control.

The framework routes control-notification messages like other **WM_** messages. One exception, however, is the BN_CLICKED control-notification message sent by buttons when the user clicks them. This message is treated specially as a command message and routed like other commands.

This includes WM_COMMAND notification messages from user-interface objects: menus, toolbar buttons, and accelerator keys. The framework processes commands differently from other messages, and they can be handled by more kinds of objects, as explained in [Command Targets](../mfc/command-targets.md).

- When an object is in-place activated, only the object's toolbars are typically displayed and the object's toolbars may have buttons for some of the container commands like **Print**, **Print Preview**, **Save**, **New**, **Zoom**, and others. (In-place activation standards recommend that objects remove such buttons from their toolbars, or at least disable them. This design allows those commands to be enabled and yet routed to the right handler.) Currently, there is no mechanism for the object to dispatch these commands to the container.

The `QueryStatus` method here tests whether a particular set of commands, the set being identified with a **GUID**, is supported. This call fills an array of **OLECMD** values (structures) with the supported list of commands as well as returning text describing the name of a command and/or status information. When the caller wishes to invoke a command, it can pass the command (and the set **GUID**) to `Exec` along with options and arguments, getting back a return value.

WM_COMMAND messages — usually generated by menus, toolbar buttons, or accelerators — also use the message-map mechanism. MFC defines a standard [routing](../mfc/command-routing.md) of command messages among the application, frame window, view, and Active documents in your program. You can override this routing if you need to.