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