changes per comment

mtx48109 · mtx48109 · commit 24e40a5074f3 · 2018-06-20T11:09:56.000-07:00
diff --git a/docs/mfc/active-document-containers.md b/docs/mfc/active-document-containers.md
@@ -37,15 +37,15 @@ An active document container, such as Microsoft Office Binder or Internet Explor
   
  An active document container that integrates active documents must:  
   
--   Be capable of handling object storage through the **IPersistStorage** interface, that is, it must provide an **IStorage** instance to each active document.  
+-   Be capable of handling object storage through the `IPersistStorage` interface, that is, it must provide an `IStorage` instance to each active document.  
   
--   Support the basic embedding features of OLE documents, necessitating "site" objects (one per document or embedding) that implement **IOleClientSite** and **IAdviseSink**.  
+-   Support the basic embedding features of OLE documents, necessitating "site" objects (one per document or embedding) that implement `IOleClientSite` and `IAdviseSink`.  
   
--   Support in-place activation of embedded objects or active documents. The container's site objects must implement **IOleInPlaceSite** and the container's frame object must provide **IOleInPlaceFrame**.  
+-   Support in-place activation of embedded objects or active documents. The container's site objects must implement `IOleInPlaceSite` and the container's frame object must provide `IOleInPlaceFrame`.  
   
--   Support the active documents' extensions by implementing **IOleDocumentSite** to provide the mechanism for the container to talk to the document. Optionally, the container can implement the active document interfaces **IOleCommandTarget** and **IContinueCallback** to pick up simple commands such as printing or saving.  
+-   Support the active documents' extensions by implementing `IOleDocumentSite` to provide the mechanism for the container to talk to the document. Optionally, the container can implement the active document interfaces `IOleCommandTarget` and `IContinueCallback` to pick up simple commands such as printing or saving.  
   
- The frame object, the view objects, and the container object can optionally implement **IOleCommandTarget** to support the dispatch of certain commands, as discussed in [Command Targets](../mfc/message-handling-and-command-targets.md). View and container objects can also optionally implement **IPrint** and **IContinueCallback**, to support programmatic printing, as discussed in [Programmatic Printing](../mfc/programmatic-printing.md).  
+ The frame object, the view objects, and the container object can optionally implement `IOleCommandTarget` to support the dispatch of certain commands, as discussed in [Command Targets](../mfc/message-handling-and-command-targets.md). View and container objects can also optionally implement `IPrint` and `IContinueCallback`, to support programmatic printing, as discussed in [Programmatic Printing](../mfc/programmatic-printing.md).  
   
  The following figure shows the conceptual relationships between a container and its components (at left), and the active document and its views (at right). The active document manages storage and data, and the view displays or optionally prints that data. Interfaces in bold are those required for active document participation; those bold and italic are optional. All other interfaces are required.  
   
@@ -67,14 +67,14 @@ An active document container, such as Microsoft Office Binder or Internet Explor
  The document site is conceptually the container for one or more "view site" objects. Each view site object is associated with individual view objects of the document managed by the document site. If the container only supports a single view per document site, then it can implement the document site and the view site with a single concrete class.  
   
 ##  <a name="view_site_objects"></a> View Site Objects  
- A container's view site object manages the display space for a particular view of a document. In addition to supporting the standard **IOleInPlaceSite** interface, a view site also generally implements **IContinueCallback** for programmatic printing control. (Note that the view object never queries for **IContinueCallback** so it can actually be implemented on any object the container desires.)  
+ A container's view site object manages the display space for a particular view of a document. In addition to supporting the standard `IOleInPlaceSite` interface, a view site also generally implements **IContinueCallback** for programmatic printing control. (Note that the view object never queries for `IContinueCallback` so it can actually be implemented on any object the container desires.)  
   
- A container that supports multiple views must be able to create multiple view site objects within the document site. This provides each view with separate activation and deactivation services as provided through **IOleInPlaceSite**.  
+ A container that supports multiple views must be able to create multiple view site objects within the document site. This provides each view with separate activation and deactivation services as provided through `IOleInPlaceSite`.  
   
 ##  <a name="frame_object"></a> Frame Object  
- The container's frame object is, for the most part, the same frame that is used for in-place activation in OLE Documents, that is, the one that handles menu and toolbar negotiation. A view object has access to this frame object through **IOleInPlaceSite::GetWindowContext**, which also provides access to the container object representing the container document (which can handle pane-level toolbar negotiation and contained object enumeration).  
+ The container's frame object is, for the most part, the same frame that is used for in-place activation in OLE Documents, that is, the one that handles menu and toolbar negotiation. A view object has access to this frame object through `IOleInPlaceSite::GetWindowContext`, which also provides access to the container object representing the container document (which can handle pane-level toolbar negotiation and contained object enumeration).  
   
- An active document container can augment the frame by adding **IOleCommandTarget**. This allows it to receive commands that originate in the active document's user interface in the same way that this interface can allow a container to send the same commands (such as **File New**, **Open**, **Save As**, **Print**; **Edit Copy**, **Paste**, **Undo**, and others) to an active document. For more information, see [Command Targets](../mfc/message-handling-and-command-targets.md).  
+ An active document container can augment the frame by adding `IOleCommandTarget`. This allows it to receive commands that originate in the active document's user interface in the same way that this interface can allow a container to send the same commands (such as **File New**, **Open**, **Save As**, **Print**; **Edit Copy**, **Paste**, **Undo**, and others) to an active document. For more information, see [Command Targets](../mfc/message-handling-and-command-targets.md).  
   
 ## See Also  
  [Active Document Containment](../mfc/active-document-containment.md)
diff --git a/docs/mfc/active-documents.md b/docs/mfc/active-documents.md
@@ -14,9 +14,9 @@ ms.workload: ["cplusplus"]
 # Active Documents
 Active documents extend the compound document technology of OLE. These extensions are provided in the form of additional interfaces that manage views, so that objects can function within containers and yet retain control over their display and printing functions. This process makes it possible to display documents both in foreign frames (such as the Microsoft Office Binder or Microsoft Internet Explorer) and in native frames (such as the product's own view ports).  
   
- This section describes the functional [requirements for active documents](#requirements_for_active_documents). The active document owns a set of data and has access to storage where the data can be saved and retrieved. It can create and manage one or more views on its data. In addition to supporting the usual embedding and in-place activation interfaces of OLE documents, the active document communicates its ability to create views through **IOleDocument**. Through this interface, the container can ask to create (and possibly enumerate) the views that the active document can display. Through this interface, the active document can also provide miscellaneous information about itself, such as whether it supports multiple views or complex rectangles.  
+ This section describes the functional [requirements for active documents](#requirements_for_active_documents). The active document owns a set of data and has access to storage where the data can be saved and retrieved. It can create and manage one or more views on its data. In addition to supporting the usual embedding and in-place activation interfaces of OLE documents, the active document communicates its ability to create views through `IOleDocument`. Through this interface, the container can ask to create (and possibly enumerate) the views that the active document can display. Through this interface, the active document can also provide miscellaneous information about itself, such as whether it supports multiple views or complex rectangles.  
   
- The following is the `IOleDocument` interface. Note that the **IEnumOleDocumentViews** interface is a standard OLE enumerator for **IOleDocumentView \*** types.  
+ The following is the `IOleDocument` interface. Note that the `IEnumOleDocumentViews` interface is a standard OLE enumerator for `IOleDocumentView \*` types.  
   
 ```  
 interface IOleDocument : IUnknown  
@@ -42,20 +42,20 @@ interface IOleDocument : IUnknown
 ##  <a name="requirements_for_active_documents"></a> Requirements for Active Documents  
  An active document that can be displayed in an active document container must:  
   
--   Use OLE's Compound Files as its storage mechanism by implementing **IPersistStorage**.  
+-   Use OLE's Compound Files as its storage mechanism by implementing `IPersistStorage`.  
   
--   Support the basic embedding features of OLE Documents, including **Create From File**. This necessitates the interfaces **IPersistFile**, **IOleObject**, and **IDataObject**.  
+-   Support the basic embedding features of OLE Documents, including **Create From File**. This necessitates the interfaces `IPersistFile`, `IOleObject`, and `IDataObject`.  
   
--   Support one or more views, each of which is capable of in-place activation. That is, the views must support the interface **IOleDocumentView** as well as the interfaces **IOleInPlaceObject** and **IOleInPlaceActiveObject** (using the container's **IOleInPlaceSite** and **IOleInPlaceFrame** interfaces).  
+-   Support one or more views, each of which is capable of in-place activation. That is, the views must support the interface `IOleDocumentView` as well as the interfaces `IOleInPlaceObject` and `IOleInPlaceActiveObject` (using the container's `IOleInPlaceSite` and `IOleInPlaceFrame` interfaces).  
   
--   Support the standard active document interfaces **IOleDocument**, **IOleCommandTarget**, and **IPrint**.  
+-   Support the standard active document interfaces `IOleDocument`, `IOleCommandTarget`, and `IPrint`.  
   
  Knowledge of when and how to use the container-side interfaces is implied in these requirements.  
   
 ##  <a name="requirements_for_view_objects"></a> Requirements for View Objects  
- An active document can create one or more views of its data. Functionally, these views are like ports onto a particular method for displaying the data. If an active document only supports a single view, the active document and that single view can be implemented using a single class. **IOleDocument::CreateView** returns the same object's **IOleDocumentView** interface pointer.  
+ An active document can create one or more views of its data. Functionally, these views are like ports onto a particular method for displaying the data. If an active document only supports a single view, the active document and that single view can be implemented using a single class. `IOleDocument::CreateView` returns the same object's `IOleDocumentView` interface pointer.  
   
- To be represented within an active document container, a view component must support **IOleInPlaceObject** and **IOleInPlaceActiveObject** in addition to `IOleDocumentView`:  
+ To be represented within an active document container, a view component must support `IOleInPlaceObject` and `IOleInPlaceActiveObject` in addition to `IOleDocumentView`:  
   
 ```  
 interface IOleDocumentView : IUnknown  
@@ -82,13 +82,13 @@ interface IOleDocumentView : IUnknown
     }  
 ```  
   
- Every view has an associated view site, which encapsulates the view frame and the view port (HWND and a rectangular area in that window). The site exposes this functionality though the standard **IOleInPlaceSite** interface. Note that it is possible to have more than one view port on a single HWND.  
+ Every view has an associated view site, which encapsulates the view frame and the view port (HWND and a rectangular area in that window). The site exposes this functionality though the standard `IOleInPlaceSite` interface. Note that it is possible to have more than one view port on a single HWND.  
   
- Typically, each type of view has a different printed representation. Hence views and the corresponding view sites should implement the printing interfaces if **IPrint** and **IContinueCallback**, respectively. The view frame must negotiate with the view provider through **IPrint** when printing begins, so that headers, footers, margins, and related elements are printed correctly. The view provider notifies the frame of printing-related events through **IContinueCallback**. For more information on the use of these interfaces, see [Programmatic Printing](../mfc/programmatic-printing.md).  
+ Typically, each type of view has a different printed representation. Hence views and the corresponding view sites should implement the printing interfaces if `IPrint` and `IContinueCallback`, respectively. The view frame must negotiate with the view provider through `IPrint` when printing begins, so that headers, footers, margins, and related elements are printed correctly. The view provider notifies the frame of printing-related events through `IContinueCallback`. For more information on the use of these interfaces, see [Programmatic Printing](../mfc/programmatic-printing.md).  
   
- Note that if an active document only supports a single view, then the active document and that single view can be implemented using a single concrete class. **IOleDocument::CreateView** simply returns the same object's **IOleDocumentView** interface pointer. In short, it is not necessary that there be two separate object instances when only one view is required.  
+ Note that if an active document only supports a single view, then the active document and that single view can be implemented using a single concrete class. `IOleDocument::CreateView` simply returns the same object's `IOleDocumentView` interface pointer. In short, it is not necessary that there be two separate object instances when only one view is required.  
   
- A view object can also be a command target. By implementing **IOleCommandTarget** a view can receive commands that originate in the container's user interface (such as **New**, **Open**, **Save As**, **Print** on the **File** menu; and **Copy**, **Paste**, **Undo** on the **Edit** menu). For more information, see [Message Handling and Command Targets](../mfc/message-handling-and-command-targets.md).  
+ A view object can also be a command target. By implementing `IOleCommandTarget` a view can receive commands that originate in the container's user interface (such as **New**, **Open**, **Save As**, **Print** on the **File** menu; and **Copy**, **Paste**, **Undo** on the **Edit** menu). For more information, see [Message Handling and Command Targets](../mfc/message-handling-and-command-targets.md).  
   
 ## See Also  
  [Active Document Containment](../mfc/active-document-containment.md)
