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

</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>