final check-in (for sample)

mtx48109 · mtx48109 · commit 0c2d4a84969b · 2018-06-20T11:55:08.000-07:00
diff --git a/docs/mfc/a-portrait-of-the-document-view-architecture.md b/docs/mfc/a-portrait-of-the-document-view-architecture.md
@@ -17,7 +17,7 @@ Documents and views are paired in a typical MFC application. Data is stored in t
 ## Gaining Access to Document Data from the View  
  The view accesses its document's data either with the [GetDocument](../mfc/reference/cview-class.md#getdocument) function, which returns a pointer to the document, or by making the view class a C++ `friend` of the document class. The view then uses its access to the data to obtain the data when it is ready to draw or otherwise manipulate it.  
   
- For example, from the view's [OnDraw](../mfc/reference/cview-class.md#ondraw) member function, the view uses **GetDocument** to obtain a document pointer. Then it uses that pointer to access a `CString` data member in the document. The view passes the string to the `TextOut` function. To see the code for this example, see [Drawing in a View](../mfc/drawing-in-a-view.md).  
+ For example, from the view's [OnDraw](../mfc/reference/cview-class.md#ondraw) member function, the view uses `GetDocument` to obtain a document pointer. Then it uses that pointer to access a `CString` data member in the document. The view passes the string to the `TextOut` function. To see the code for this example, see [Drawing in a View](../mfc/drawing-in-a-view.md).  
   
 ## User Input to the View  
  The view might also interpret a mouse click within itself as either selection or editing of data. Similarly it might interpret keystrokes as data entry or editing. Suppose the user types a string in a view that manages text. The view obtains a pointer to the document and uses the pointer to pass the new data to the document, which stores it in some data structure.  
diff --git a/docs/mfc/activex-control-containers-handling-events-from-an-activex-control.md b/docs/mfc/activex-control-containers-handling-events-from-an-activex-control.md
@@ -29,7 +29,7 @@ This article discusses using the Properties window to install event handlers for
   
  As you use the Properties window to add events, an event map entry (`ON_EVENT`) is added to the event sink map and an event handler function is added to the container's implementation (.CPP) file.  
   
- The following example declares an event handler, called `OnClickInCircCtrl`, for the Circ control's **ClickIn** event:  
+ The following example declares an event handler, called `OnClickInCircCtrl`, for the Circ control's `ClickIn` event:  
   
  [!code-cpp[NVC_MFC_AxCont#10](../mfc/codesnippet/cpp/activex-control-containers-handling-events-from-an-activex-control_3.cpp)]  
   
diff --git a/docs/mfc/activex-control-containers-using-controls-in-a-non-dialog-container.md b/docs/mfc/activex-control-containers-using-controls-in-a-non-dialog-container.md
@@ -33,7 +33,7 @@ In some applications, such as an SDI or MDI application, you will want to embed
   
  One example of using this function to dynamically create an ActiveX control would be in a form view of an SDI application. You could then create an instance of the control in the `WM_CREATE` handler of the application.  
   
- For this example, `CMyView` is the main view class, `CCirc` is the wrapper class, and CIRC.H is the header (.H) file of the wrapper class.  
+ For this example, `CMyView` is the main view class, `CCirc` is the wrapper class, and *CIRC.H* is the header (.H) file of the wrapper class.  
   
  Implementing this feature is a four-step process.  
   
diff --git a/docs/mfc/activex-controls-on-the-internet.md b/docs/mfc/activex-controls-on-the-internet.md
@@ -24,7 +24,7 @@ ActiveX controls are the updated version of the OLE control specification. Contr
   
  **In order to be an ActiveX control, a control must:**  
   
--   Support the **IUnknown** interface.  
+-   Support the `IUnknown` interface.  
   
 -   Be a COM object.  
   
@@ -70,7 +70,7 @@ ActiveX controls are the updated version of the OLE control specification. Contr
   
 #### To create your project using the MFC ActiveX Control Wizard  
   
-1.  Click `New` on the **File** menu.  
+1.  Click **New** on the **File** menu.  
   
 2.  Select **MFC ActiveX Control Wizard** from the Visual C++ projects and name your project.  
   
@@ -114,7 +114,7 @@ ActiveX controls are the updated version of the OLE control specification. Contr
   
      [!code-cpp[NVC_MFCActiveXControl#3](../mfc/codesnippet/cpp/activex-controls-on-the-internet_3.h)]  
   
-5.  Implement the **Get/Set** methods. For **Get**, return the string. For `Set`, load the property and call `SetModifiedFlag`.  
+5.  Implement the `Get/Set` methods. For `Get`, return the string. For `Set`, load the property and call `SetModifiedFlag`.  
   
      [!code-cpp[NVC_MFCActiveXControl#4](../mfc/codesnippet/cpp/activex-controls-on-the-internet_4.cpp)]  
   
diff --git a/docs/mfc/adding-controls-by-hand.md b/docs/mfc/adding-controls-by-hand.md
@@ -16,11 +16,11 @@ You can either [add controls to a dialog box with the dialog editor](../mfc/usin
   
  To create a control object yourself, you will usually embed the C++ control object in a C++ dialog or frame-window object. Like many other objects in the framework, controls require two-stage construction. You should call the control's **Create** member function as part of creating the parent dialog box or frame window. For dialog boxes, this is usually done in [OnInitDialog](../mfc/reference/cdialog-class.md#oninitdialog), and for frame windows, in [OnCreate](../mfc/reference/cwnd-class.md#oncreate).  
   
- The following example shows how you might declare a `CEdit` object in the class declaration of a derived dialog class and then call the **Create** member function in `OnInitDialog`. Because the `CEdit` object is declared as an embedded object, it is automatically constructed when the dialog object is constructed, but it must still be initialized with its own **Create** member function.  
+ The following example shows how you might declare a `CEdit` object in the class declaration of a derived dialog class and then call the `Create` member function in `OnInitDialog`. Because the `CEdit` object is declared as an embedded object, it is automatically constructed when the dialog object is constructed, but it must still be initialized with its own `Create` member function.  
   
  [!code-cpp[NVC_MFCControlLadenDialog#1](../mfc/codesnippet/cpp/adding-controls-by-hand_1.h)]  
   
- The following `OnInitDialog` function sets up a rectangle, then calls **Create** to create the Windows edit control and attach it to the uninitialized `CEdit` object.  
+ The following `OnInitDialog` function sets up a rectangle, then calls `Create` to create the Windows edit control and attach it to the uninitialized `CEdit` object.  
   
  [!code-cpp[NVC_MFCControlLadenDialog#2](../mfc/codesnippet/cpp/adding-controls-by-hand_2.cpp)]  
   
diff --git a/docs/mfc/adding-multiple-views-to-a-single-document.md b/docs/mfc/adding-multiple-views-to-a-single-document.md
@@ -33,14 +33,14 @@ In a single-document interface (SDI) application created with the Microsoft Foun
   
  The remainder of this topic assumes the following:  
   
--   The name of the `CWinApp`-derived object is `CMyWinApp`, and `CMyWinApp` is declared and defined in MYWINAPP.H and MYWINAPP.CPP.  
+-   The name of the `CWinApp`-derived object is `CMyWinApp`, and `CMyWinApp` is declared and defined in *MYWINAPP.H* and *MYWINAPP.CPP*.  
   
--   `CNewView` is the name of the new `CView`-derived object, and `CNewView` is declared and defined in NEWVIEW.H and NEWVIEW.CPP.  
+-   `CNewView` is the name of the new `CView`-derived object, and `CNewView` is declared and defined in *NEWVIEW.H* and *NEWVIEW.CPP*.  
   
 ##  <a name="vcconmodifyexistingapplicationa1"></a> Modify the Existing Application Class  
  For the application to switch between views, you need to modify the application class by adding member variables to store the views and a method to switch them.  
   
- Add the following code to the declaration of `CMyWinApp` in MYWINAPP.H:  
+ Add the following code to the declaration of `CMyWinApp` in *MYWINAPP.H*:  
   
  [!code-cpp[NVC_MFCDocViewSDI#1](../mfc/codesnippet/cpp/adding-multiple-views-to-a-single-document_1.h)]  
   
@@ -59,7 +59,7 @@ In a single-document interface (SDI) application created with the Microsoft Foun
   
  Once you have added the class to the project, you need to change the accessibility of some view class members.  
   
- Modify NEWVIEW.H by changing the access specifier from `protected` to **public** for the constructor and destructor. This allows the class to be created and destroyed dynamically and to modify the view appearance before it is visible.  
+ Modify *NEWVIEW.H* by changing the access specifier from **protected** to **public** for the constructor and destructor. This allows the class to be created and destroyed dynamically and to modify the view appearance before it is visible.  
   
  Save your changes and continue to the next step.  
   
@@ -77,7 +77,7 @@ In a single-document interface (SDI) application created with the Microsoft Foun
 ##  <a name="vcconswitchingfunctiona4"></a> Implement the Switching Function  
  In the previous step, you added code that created and initialized a new view object. The last major piece is to implement the switching method, `SwitchView`.  
   
- At the end of the implementation file for your application class (MYWINAPP.CPP), add the following method definition:  
+ At the end of the implementation file for your application class (*MYWINAPP.CPP*), add the following method definition:  
   
  [!code-cpp[NVC_MFCDocViewSDI#4](../mfc/codesnippet/cpp/adding-multiple-views-to-a-single-document_4.cpp)]  
   
diff --git a/docs/mfc/alternatives-to-the-document-view-architecture.md b/docs/mfc/alternatives-to-the-document-view-architecture.md
@@ -29,21 +29,21 @@ MFC applications normally use the document/view architecture to manage informati
   
  The Visual C++ wizards, as well as the source and dialog editors, work with the generated application just as they would with any other Wizard-generated application. The application can support toolbars, scrollbars, and a status bar, and has an **About** box. Your application will not register any document templates, and it will not contain a document class.  
   
- Note that your generated application has a view class, **CChildView**, derived from `CWnd`. MFC creates and positions one instance of the view class within the frame windows created by your application. MFC still enforces using a view window, because it simplifies positioning and managing the application's content. You can add painting code to the `OnPaint` member of this class. Your code should add scrollbars to the view rather than to the frame.  
+ Note that your generated application has a view class, `CChildView`, derived from `CWnd`. MFC creates and positions one instance of the view class within the frame windows created by your application. MFC still enforces using a view window, because it simplifies positioning and managing the application's content. You can add painting code to the `OnPaint` member of this class. Your code should add scrollbars to the view rather than to the frame.  
   
  Because the document/view architecture provided by MFC is responsible for implementing many of an application's basic features, its absence in your project means that you are responsible for implementing many important features of your application:  
   
--   As provided by the MFC Application Wizard, the menu for your application contains only `New` and `Exit` commands on the **File** menu. (The `New` command is supported only for MDI applications, not SDI applications without Document/View support.) The generated menu resource will not support an MRU (most recently used) list.  
+-   As provided by the MFC Application Wizard, the menu for your application contains only **New** and **Exit** commands on the **File** menu. (The **New** command is supported only for MDI applications, not SDI applications without Document/View support.) The generated menu resource will not support an MRU (most recently used) list.  
   
 -   You must add handler functions and implementations for any commands that your application will support, including **Open** and **Save** on the **File** menu. MFC normally provides code to support these features, but that support is tightly bound to the document/view architecture.  
   
 -   The toolbar for your application, if you requested one, will be minimal.  
   
  It is strongly recommended that you use the MFC Application Wizard to create applications without the document/view architecture, because the wizard guarantees a correct MFC architecture. However, if you must avoid using the wizard, here are several approaches for bypassing the document/view architecture in your code:  
   
--   Treat the document as an unused appendage and implement your data management code in the view class, as suggested above. Overhead for the document is relatively low. A single [CDocument](../mfc/reference/cdocument-class.md) object incurs a small amount of overhead by itself, plus the small overhead of **CDocument**'s base classes, [CCmdTarget](../mfc/reference/ccmdtarget-class.md) and [CObject](../mfc/reference/cobject-class.md). Both of the latter classes are small.  
+-   Treat the document as an unused appendage and implement your data management code in the view class, as suggested above. Overhead for the document is relatively low. A single [CDocument](../mfc/reference/cdocument-class.md) object incurs a small amount of overhead by itself, plus the small overhead of `CDocument`'s base classes, [CCmdTarget](../mfc/reference/ccmdtarget-class.md) and [CObject](../mfc/reference/cobject-class.md). Both of the latter classes are small.  
   
-     Declared in **CDocument**:  
+     Declared in `CDocument`:  
   
     -   Two `CString` objects.  
   
diff --git a/docs/mfc/automation-clients.md b/docs/mfc/automation-clients.md
@@ -25,7 +25,7 @@ Automation makes it possible for your application to manipulate objects implemen
   
  Static bound clients use a proxy class that is statically linked with the client application. This class provides a type-safe C++ encapsulation of the server application's properties and operations.  
   
- The class `COleDispatchDriver` provides the principal support for the client side of Automation. Using the `Add New Item` dialog box, you create a class derived from `COleDispatchDriver`.  
+ The class `COleDispatchDriver` provides the principal support for the client side of Automation. Using the **Add New Item** dialog box, you create a class derived from `COleDispatchDriver`.  
   
  You then specify the type-library file describing the properties and functions of the server application's object. The Add Item dialog box reads this file and creates the `COleDispatchDriver`-derived class, with member functions that your application can call to access the server application's objects in C++ in a type-safe manner. Additional functionality inherited from `COleDispatchDriver` simplifies the process of calling the proper Automation server.  
   
diff --git a/docs/mfc/automation.md b/docs/mfc/automation.md
@@ -31,7 +31,7 @@ Automation (formerly known as OLE Automation) makes it possible for one applicat
  Many commercial applications, such as Microsoft Excel and Microsoft Visual C++, allow you to automate much of their functionality. For example, in Visual C++, you can write VBScript macros to automate builds, aspects of code editing, or debugging tasks.  
   
 ##  <a name="_core_passing_parameters_in_automation"></a> Passing Parameters in Automation  
- One difficulty in creating Automation methods is helping to provide a uniform "safe" mechanism to pass data between automation servers and clients. Automation uses the **VARIANT** type to pass data. The **VARIANT** type is a tagged union. It has a data member for the value (this is an anonymous C++ union) and a data member indicating the type of information stored in the union. The **VARIANT** type supports a number of standard data types: 2- and 4-byte integers, 4- and 8-byte floating-point numbers, strings, and Boolean values. In addition, it supports the `HRESULT` (OLE error codes), **CURRENCY** (a fixed-point numeric type), and **DATE** (absolute date and time) types, as well as pointers to **IUnknown** and `IDispatch` interfaces.  
+ One difficulty in creating Automation methods is helping to provide a uniform "safe" mechanism to pass data between automation servers and clients. Automation uses the **VARIANT** type to pass data. The **VARIANT** type is a tagged union. It has a data member for the value (this is an anonymous C++ union) and a data member indicating the type of information stored in the union. The **VARIANT** type supports a number of standard data types: 2- and 4-byte integers, 4- and 8-byte floating-point numbers, strings, and Boolean values. In addition, it supports the **HRESULT** (OLE error codes), **CURRENCY** (a fixed-point numeric type), and **DATE** (absolute date and time) types, as well as pointers to `IUnknown` and `IDispatch` interfaces.  
   
  The **VARIANT** type is encapsulated in the [COleVariant](../mfc/reference/colevariant-class.md) class. The supporting **CURRENCY** and **DATE** classes are encapsulated in the [COleCurrency](../mfc/reference/colecurrency-class.md) and [COleDateTime](../atl-mfc-shared/reference/coledatetime-class.md) classes.  
   
