Replace occurrences of ..' by ..` (backtick+text+quote replaced by backtick+text+backtick).

git-svn-id: https://svn.eiffel.com/eiffel-org/trunk@1597 abb3cda0-5349-4a8f-a601-0c33ac3a8c38

documentation/trunk/solutions/platform-specifics/microsoft-windows/net/eiffel-net-language/eiffel-net-integration.wiki

@@ -47,7 +47,7 @@ Using the <code>metadata</code> tag is the most general way of applying a custom
 
 The CLR (Common Language Runtime) does not support [[ET: Inheritance#Covariance and anchored declarations|covariance]] due to a type safety issue that full covariance implies (known as a polymorphic [[ET: Inheritance#Catcalls|catcall]] in Eiffel). Although very rare, catcalls are not suitable to .NET where safety is one of the primary goals. 
 
-Eiffel for .NET implements a safe variant of covariance that will always perform a check on the types to avoid a catcall. So when a catcall is going to be performed a `Invalid Cast Exception' will be raised by the CLR instead of an unexpected behavior as is the default behavior in classic Eiffel (i.e., the behavior without catcall detection explicitly enabled). 
+Eiffel for .NET implements a safe variant of covariance that will always perform a check on the types to avoid a catcall. So when a catcall is going to be performed a `Invalid Cast Exception` will be raised by the CLR instead of an unexpected behavior as is the default behavior in classic Eiffel (i.e., the behavior without catcall detection explicitly enabled). 
 
 Another advantage of Eiffel for .NET's implementation of covariance is that it can be easily understood by CLS compliant consumer tools. These tools will actually benefit from the Eiffel for .NET covariance. 
 
@@ -69,7 +69,7 @@ Eiffel for .NET supports .NET enum types implicitly. From the point of view of E
 
 ===ByRef===
 
-Eiffel does not have the notion of `byref' argument passing. At the moment, Eiffel for .NET cannot call nor can it redefine a feature that has a byref argument. 
+Eiffel does not have the notion of `byref` argument passing. At the moment, Eiffel for .NET cannot call nor can it redefine a feature that has a byref argument. 
 
 
 

documentation/trunk/solutions/platform-specifics/microsoft-windows/wel/wel-common-concepts/common-message-hooks.wiki

@@ -1,7 +1,7 @@
 [[Property:title|Common message hooks]]
 [[Property:weight|4]]
 [[Property:uuid|356b5211-f710-6509-3609-8d717ff425f7]]
-Each WEL library component implements a set of routines for processing the most common messages that a component receives. For example, looking at [[ref:libraries/wel/reference/wel_frame_window_chart|WEL_FRAME_WINDOW]] , you will see that there are many features which begin `on_'. Each of these features enable the user to know when a specific event has occurred, and to perform the appropriate processing as a result of this event. Most of the time, you will only be interested in a small subset of these, necessary to your program. For example, below is the code for on_paint:
+Each WEL library component implements a set of routines for processing the most common messages that a component receives. For example, looking at [[ref:libraries/wel/reference/wel_frame_window_chart|WEL_FRAME_WINDOW]] , you will see that there are many features which begin `on_`. Each of these features enable the user to know when a specific event has occurred, and to perform the appropriate processing as a result of this event. Most of the time, you will only be interested in a small subset of these, necessary to your program. For example, below is the code for on_paint:
 <code>
     on_paint (paint_dc: WEL_PAINT_DC; invalid_rect: WEL_RECT)
             --Draw a centered text

documentation/trunk/solutions/platform-specifics/microsoft-windows/wel/wel-samples/header-control.wiki

@@ -20,7 +20,7 @@ After launching the program, a window will be displayed as shown above. By manip
 
 ==Under the Hood==
 
-<code>HEADER_CONTROL</code> inherits [[ref:libraries/wel/reference/wel_header_control_chart|WEL_HEADER_CONTROL]]  and redefines many of the `on_' notification features to display the output. 
+<code>HEADER_CONTROL</code> inherits [[ref:libraries/wel/reference/wel_header_control_chart|WEL_HEADER_CONTROL]]  and redefines many of the `on_` notification features to display the output. 
 
 This sample contains the following classes: 
 * <code>APPLICATION_IDS</code>

documentation/trunk/solutions/platform-specifics/microsoft-windows/wel/wel-samples/list-view.wiki

@@ -20,7 +20,7 @@ After launching the program, a window will be displayed containing a pair of [[r
 
 <code>LISTVIEW_DEMO</code> redefines <code>init_application</code> in order to load the [[ref:libraries/wel/reference/wel_common_controls_dll_chart|WEL_COMMON_CONTROLS_DLL]]  and the [[ref:libraries/wel/reference/wel_rich_edit_dll_chart|WEL_RICH_EDIT_DLL]] .
 
-<code>LISTVIEW</code> redefines many of the `on_' features inherited from [[ref:libraries/wel/reference/wel_list_view_chart|WEL_LIST_VIEW]]  in order to generate output for the user.
+<code>LISTVIEW</code> redefines many of the `on_` features inherited from [[ref:libraries/wel/reference/wel_list_view_chart|WEL_LIST_VIEW]]  in order to generate output for the user.
 
 The style of the <code>LISTVIEW_DEMO</code> is changed by calling <code>set_style</code> with the required new style.
 

documentation/trunk/solutions/platform-specifics/microsoft-windows/wel/wel-samples/split-area.wiki

@@ -18,7 +18,7 @@ To compile the example:
 After launching the program, a window will be displayed containing a pair of [[ref:libraries/wel/reference/wel_rich_edit_chart|WEL_RICH_EDIT]]  in a split area. Clicking the mouse on the split area (between the two rich edits) and dragging the mouse, will adjust the split area and its content accordingly. 
 ==Under the Hood==
 
-There is no split area class provided with WEL, but <code>WEL_SPLIT_AREA</code> was created for this sample to illustrate how new controls can be built when required. Redefining some of the `on_' features inherited from [[ref:libraries/wel/reference/wel_window_chart|WEL_WINDOW]]  in <code>WEL_SPLIT_AREA</code> shows how the control over the contents of the split area is achieved.
+There is no split area class provided with WEL, but <code>WEL_SPLIT_AREA</code> was created for this sample to illustrate how new controls can be built when required. Redefining some of the `on_` features inherited from [[ref:libraries/wel/reference/wel_window_chart|WEL_WINDOW]]  in <code>WEL_SPLIT_AREA</code> shows how the control over the contents of the split area is achieved.
 
 This sample contains the following classes: 
 * <code>APPLICATION</code>