Frédéric Delanoy : winedev: Use 'methodname' tags for class methods.

[Alexandre Julliard]

Module: docs
Branch: master
Commit: c1e27ba7c13f994d0fbf8e1d1cf894c59b6b7ff1
URL:    http://source.winehq.org/git/docs.git/?a=commit;h=c1e27ba7c13f994d0fbf8e1d1c...

Author: Frédéric Delanoy 
Date:   Thu Sep  5 00:15:49 2013 +0200

winedev: Use 'methodname' tags for class methods.

---

en/winedev-ddraw.sgml |   28 ++++++++++++++--------------
 en/winedev-ole.sgml   |   27 ++++++++++++++-------------
 2 files changed, 28 insertions(+), 27 deletions(-)

diff --git a/en/winedev-ddraw.sgml b/en/winedev-ddraw.sgml
index fb99df2..4fc3614 100644
--- a/en/winedev-ddraw.sgml
+++ b/en/winedev-ddraw.sgml
@@ -18,9 +18,9 @@
       <para>
         Most of the DirectDraw functionality is implemented in a common base
         class. Derived classes are responsible for providing display
-        mode functions (<function>EnumDisplayModes</function>, <function>SetDisplayMode</function>,
-        <function>RestoreDisplayMode</function>), <function>GetCaps</function>,
-        <function>GetDeviceIdentifier</function>
+        mode methods (<methodname>EnumDisplayModes</methodname>,
+        <methodname>SetDisplayMode</methodname>, <methodname>RestoreDisplayMode</methodname>),
+        <methodname>GetCaps</methodname>, <methodname>GetDeviceIdentifier</methodname>
         and internal functions called to create primary and backbuffer
         surfaces.
       </para>
@@ -31,7 +31,7 @@
       </para>
       <para>
         <classname>XVidMode</classname> attempt to use the XFree86 VidMode extension to set the
-        display resolution to match the parameters to <function>SetDisplayMode</function>.
+        display resolution to match the parameters to <methodname>SetDisplayMode</methodname>.
       </para>
       <para>
         <classname>DGA2</classname> attempt to use the XFree86 DGA 2.x extension to set the
@@ -150,23 +150,23 @@
     <sect1 id="creatingobject">
     <title>Creating Objects</title>
       <para>
-        Classes have two functions relevant to object creation, <function>Create</function> and
-        <function>Construct</function>. To create a new object, the <function>Create</function>
-        function of the class is called. It allocates enough memory for
-        <classname>IDirectDrawImpl</classname> or <classname>IDirectDrawSurfaceImpl</classname>
+        Classes have two methods relevant to object creation, <methodname>Create</methodname>
+        and <methodname>Construct</methodname>. To create a new object, the
+        <methodname>Create</methodname> method of the class is called. It allocates enough memory
+        for <classname>IDirectDrawImpl</classname> or <classname>IDirectDrawSurfaceImpl</classname>
         as well as the private data for derived classes and then calls
         <filename>Construct</filename>.
       </para>
       <para>
-        Each class <function>Construct</function> function calls the base class
-        <function>Construct</function>, then does the necessary initialization.
+        Each class <methodname>Construct</methodname> method calls the base class
+        <methodname>Construct</methodname>, then does the necessary initialization.
       </para>
       <para>
         For example, creating a primary surface with the user ddraw driver
-        calls <function>User_DirectDrawSurface_Create</function> which allocates memory for the
-        object and calls <function>User_DirectDrawSurface_Construct</function> to initialize it.
-        This calls <function>DIB_DirectDrawSurface_Construct</function> which calls
-        <function>Main_DirectDrawSurface_Construct</function>.
+        calls <methodname>User_DirectDrawSurface_Create</methodname> which allocates memory for the
+        object and calls <methodname>User_DirectDrawSurface_Construct</methodname> to initialize it.
+        This calls <methodname>DIB_DirectDrawSurface_Construct</methodname> which calls
+        <methodname>Main_DirectDrawSurface_Construct</methodname>.
       </para>
     </sect1>
   </chapter>
diff --git a/en/winedev-ole.sgml b/en/winedev-ole.sgml
index 235a04b..4343ddf 100644
--- a/en/winedev-ole.sgml
+++ b/en/winedev-ole.sgml
@@ -273,7 +273,7 @@ struct IDirect3DVtbl {
           <structfield>t.lpVtbl</structfield> defined in <interfacename>IUnknown</interfacename>,
           must be interpreted as the jump table pointer if we interpret the structure as the
           interface class, and as the function pointer to the
-          <function>QueryInterface</function> method,
+          <methodname>QueryInterface</methodname> method,
           <structfield>t.fnQueryInterface</structfield>, if we interpret the structure as the jump
           table.  Fortunately this gymnastic
           is entirely taken care of in the header of <interfacename>IUnknown</interfacename>.
@@ -659,9 +659,9 @@ static ICOM_VTABLE(IDirect3D) d3dvt = {
               implements <interfacename>IPSFactoryBuffer</interfacename>. </para> </listitem>

<listitem> <para> <interfacename>IPSFactoryBuffer</interfacename> has only two methods,
-                <function>CreateProxy</function> and <function>CreateStub</function>. COM
-                calls whichever is appropriate: <function>CreateStub</function> for the server,
-                <function>CreateProxy</function>
+                <methodname>CreateProxy</methodname> and <methodname>CreateStub</methodname>. COM
+                calls whichever is appropriate: <methodname>CreateStub</methodname> for the server,
+                <methodname>CreateProxy</methodname>
                 for the client. MIDL will normally provide an implementation of this
                 object for you in the code it generates. </para></listitem>
           </itemizedlist>
@@ -669,19 +669,20 @@ static ICOM_VTABLE(IDirect3D) d3dvt = {
         </para>

<para>
-          Once <function>CreateProxy</function> has been called, the resultant object is
-          <function>QueryInterface</function>d to <interfacename>IRpcProxyBuffer</interfacename>,
-          which only has one method, <function>IRpcProxyBuffer::Connect</function>.
+          Once <methodname>CreateProxy</methodname> has been called, the resultant object is
+          <methodname>QueryInterface</methodname>d to
+          <interfacename>IRpcProxyBuffer</interfacename>, which only has one method,
+          <methodname>IRpcProxyBuffer::Connect</methodname>.
           This method only takes one parameter, the <interfacename>IRpcChannelBuffer</interfacename>
           object which encapsulates the <quote>RPC Channel</quote> between the client and server.
         </para>

<para>
           On the server side, a similar process is performed: the
-          <classname>PSFactoryBuffer</classname> is created, <function>CreateStub</function> is
-          called, result is <function>QueryInterface</function>d to
+          <classname>PSFactoryBuffer</classname> is created, <methodname>CreateStub</methodname> is
+          called, result is <methodname>QueryInterface</methodname>d to
           <interfacename>IRpcStubBuffer</interfacename>, and
-          <function>IRpcStubBuffer::Connect</function> is used to link it to the RPC channel.
+          <methodname>IRpcStubBuffer::Connect</methodname> is used to link it to the RPC channel.
         </para>

</sect2>
@@ -743,7 +744,7 @@ static ICOM_VTABLE(IDirect3D) d3dvt = {
           <type>_StubMgrThread</type> thread is started. I haven't gone into the stub manager
           here. The important thing is that eventually a <type>_StubReaderThread</type> is
           started which accepts marshalled DCOM RPCs, and then passes them to
-          <function>IRpcStubBuffer::Invoke</function> on the correct stub object which in turn
+          <methodname>IRpcStubBuffer::Invoke</methodname> on the correct stub object which in turn
           demarshalls the packet and performs the call. The threads started by our
           implementation of DCOM are never terminated, they just hang around until
           the process dies.
@@ -963,7 +964,7 @@ static ICOM_VTABLE(IDirect3D) d3dvt = {
           Then <function>RpcBindingFromStringBinding</function> is used
           to convert this remote string binding into an RPC binding handle
           which can be passed to the local 
-          <function>IOXIDResolver::ResolveOxid</function> implementation
+          <methodname>IOXIDResolver::ResolveOxid</methodname> implementation
           along with the OXID. The local OXID resolver consults its list
           of same-machine OXIDs, then its cache of remote OXIDs, and if
           not found does an RPC to the remote OXID resolver using the
@@ -1002,7 +1003,7 @@ static ICOM_VTABLE(IDirect3D) d3dvt = {
           <interfacename>IRemUnknown</interfacename> is used for lifecycle management, and for
           marshaling new interfaces on an object back to the client. Its definition can
           be seen in <filename>dcom.idl</filename> - basically the
-          <function>IRemUnknown::RemQueryInterface</function> method takes an IPID and a list of
+          <methodname>IRemUnknown::RemQueryInterface</methodname> method takes an IPID and a list of
           IIDs, then returns <structname>STDOBJREF</structname>s of each new marshaled interface
           pointer.
         </para>