[2/2] [docs] winedev: Use 'methodname' tags for class methods
Frédéric Delanoy
frederic.delanoy at gmail.com
Wed Sep 4 17:15:49 CDT 2013
---
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>
--
1.8.4
More information about the wine-patches
mailing list