<?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_d0e78592_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>+
−