|
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" 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"><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"><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"><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"> |
|
38 <image href="GUID-DF3ECD47-4A5B-5836-B5CA-ACCEE98412D4_d0e46823_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"><title>See also</title> <p><xref href="GUID-B84FA223-3DFD-58C5-8CEF-C5AA73AA6290.dita">How |
|
47 to write controls</xref> </p> </section> |
|
48 </conbody></concept> |