<?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_d0e46981_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>