--- a/Symbian3/PDK/Source/GUID-F32E2F00-B68F-59B2-AABA-181E16354C86.dita	Thu Mar 11 15:24:26 2010 +0000
+++ b/Symbian3/PDK/Source/GUID-F32E2F00-B68F-59B2-AABA-181E16354C86.dita	Thu Mar 11 18:02:22 2010 +0000
@@ -1,48 +1,48 @@
-<?xml version="1.0" encoding="utf-8"?>
-<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->
-<!-- This component and the accompanying materials are made available under the terms of the License 
-"Eclipse Public License v1.0" which accompanies this distribution, 
-and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->
-<!-- Initial Contributors:
-    Nokia Corporation - initial contribution.
-Contributors: 
--->
-<!DOCTYPE concept
-  PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
-<concept id="GUID-F32E2F00-B68F-59B2-AABA-181E16354C86" xml:lang="en"><title>The
-object provider (MOP) mechanism</title><prolog><metadata><keywords/></metadata></prolog><conbody>
-<section id="GUID-07E61ABD-C57F-4E11-A32B-85DF6FAC4D61"><title>Purpose</title><p>The object provider mechanism
-exists to enable control types to be established at run time. It's a form
-of Run Time Type Identification (RTTI). More specifically it allows a caller
-to find a control in the run-time hierarchy that implements a particular interface,
-or mixin. From the caller's point of view it's pretty simple: all that's required
-is to ask a control, any control, to get an object that supports the specified
-interface, cast the pointer returned to the correct interface and then call
-the desired function. </p></section>
-<section id="GUID-96964B1B-297B-4196-961F-B574ACBF1811"><title>History</title><p>The Object Provider interface pre-dates
-the parent pointer in <xref href="GUID-B06F99BD-F032-3B87-AB26-5DD6EBE8C160.dita"><apiname>CCoeControl</apiname></xref>. Instead it uses a <codeph>MopParent</codeph> pointer
-which is normally the parent control but may be the AppUi or even the <codeph>CoeEnv</codeph> object.
-It was designed to meet Series 60 requirements for navigation of the run-time
-hierarchy. Internally it is now implemented by the framework using the parent
-pointer where possible which simplifies the control development process. </p></section>
-<section id="GUID-8A6CBDB0-343E-41F1-AC3A-876FA6968DB4"><title>Description</title><p>Interfaces are only identifiable by
-the Object Provider framework if they have an associated Interface UID. The
-Interface UID must be declared in the class definition. Fortunately the UID
-is invisible to the caller which simply uses the interface (mixin) name. </p><p>A
-class which implements an identifiable mixin, i.e. one with an Interface UID,
-can 'supply' a pointer to itself when the Object Provider framework requests
-it. If a control is not able to supply the mixin requested it passes the request
-on to the next control in the hierarchy. </p><p>The sequence diagram below
-illustrates the Object Provider process for supplying an interface pointer
-from the run-time hierarchy. </p><fig id="GUID-91496FA9-60F6-5DDA-899B-7E54A8A7E4CB">
-<image href="GUID-DF3ECD47-4A5B-5836-B5CA-ACCEE98412D4_d0e14226_href.png" placement="inline"/>
-</fig><p>Object1 wishes to call a function on <codeph>MInterface</codeph>.
-It calls <codeph>MopGetObject()</codeph> on the nearest control in the run-time
-hierarchy. The Object Provider Framework identifies the Uid for <codeph>Minterface</codeph> and
-then passes the request up the hierarchy until an object is found (Object4)
-that implements <codeph>Minterface</codeph>. </p><p>Calling <codeph>MopGetGetObjectNoChaining()</codeph> will
-call <codeph>MopSupplyObject()</codeph> but not <codeph>MopNext()</codeph>.
-It returns Null if the class does not implement the specified mixin. </p></section>
-<section id="GUID-33E336B0-98AD-45B0-80A8-5263D8D6167D"><title>See also</title> <p><xref href="GUID-B84FA223-3DFD-58C5-8CEF-C5AA73AA6290.dita">How
-to write controls</xref>  </p> </section>
+<?xml version="1.0" encoding="utf-8"?>
+<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->
+<!-- This component and the accompanying materials are made available under the terms of the License 
+"Eclipse Public License v1.0" which accompanies this distribution, 
+and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->
+<!-- Initial Contributors:
+    Nokia Corporation - initial contribution.
+Contributors: 
+-->
+<!DOCTYPE concept
+  PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
+<concept id="GUID-F32E2F00-B68F-59B2-AABA-181E16354C86" xml:lang="en"><title>The
+object provider (MOP) mechanism</title><prolog><metadata><keywords/></metadata></prolog><conbody>
+<section id="GUID-07E61ABD-C57F-4E11-A32B-85DF6FAC4D61"><title>Purpose</title><p>The object provider mechanism
+exists to enable control types to be established at run time. It's a form
+of Run Time Type Identification (RTTI). More specifically it allows a caller
+to find a control in the run-time hierarchy that implements a particular interface,
+or mixin. From the caller's point of view it's pretty simple: all that's required
+is to ask a control, any control, to get an object that supports the specified
+interface, cast the pointer returned to the correct interface and then call
+the desired function. </p></section>
+<section id="GUID-96964B1B-297B-4196-961F-B574ACBF1811"><title>History</title><p>The Object Provider interface pre-dates
+the parent pointer in <xref href="GUID-B06F99BD-F032-3B87-AB26-5DD6EBE8C160.dita"><apiname>CCoeControl</apiname></xref>. Instead it uses a <codeph>MopParent</codeph> pointer
+which is normally the parent control but may be the AppUi or even the <codeph>CoeEnv</codeph> object.
+It was designed to meet Series 60 requirements for navigation of the run-time
+hierarchy. Internally it is now implemented by the framework using the parent
+pointer where possible which simplifies the control development process. </p></section>
+<section id="GUID-8A6CBDB0-343E-41F1-AC3A-876FA6968DB4"><title>Description</title><p>Interfaces are only identifiable by
+the Object Provider framework if they have an associated Interface UID. The
+Interface UID must be declared in the class definition. Fortunately the UID
+is invisible to the caller which simply uses the interface (mixin) name. </p><p>A
+class which implements an identifiable mixin, i.e. one with an Interface UID,
+can 'supply' a pointer to itself when the Object Provider framework requests
+it. If a control is not able to supply the mixin requested it passes the request
+on to the next control in the hierarchy. </p><p>The sequence diagram below
+illustrates the Object Provider process for supplying an interface pointer
+from the run-time hierarchy. </p><fig id="GUID-91496FA9-60F6-5DDA-899B-7E54A8A7E4CB">
+<image href="GUID-DF3ECD47-4A5B-5836-B5CA-ACCEE98412D4_d0e14226_href.png" placement="inline"/>
+</fig><p>Object1 wishes to call a function on <codeph>MInterface</codeph>.
+It calls <codeph>MopGetObject()</codeph> on the nearest control in the run-time
+hierarchy. The Object Provider Framework identifies the Uid for <codeph>Minterface</codeph> and
+then passes the request up the hierarchy until an object is found (Object4)
+that implements <codeph>Minterface</codeph>. </p><p>Calling <codeph>MopGetGetObjectNoChaining()</codeph> will
+call <codeph>MopSupplyObject()</codeph> but not <codeph>MopNext()</codeph>.
+It returns Null if the class does not implement the specified mixin. </p></section>
+<section id="GUID-33E336B0-98AD-45B0-80A8-5263D8D6167D"><title>See also</title> <p><xref href="GUID-B84FA223-3DFD-58C5-8CEF-C5AA73AA6290.dita">How
+to write controls</xref>  </p> </section>
 </conbody></concept>
\ No newline at end of file