diff -r 43e37759235e -r 51a74ef9ed63 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 --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/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 Wed Mar 31 11:11:55 2010 +0100 @@ -0,0 +1,48 @@ + + + + + +The +object provider (MOP) mechanism +
Purpose

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.

+
History

The Object Provider interface pre-dates +the parent pointer in CCoeControl. Instead it uses a MopParent pointer +which is normally the parent control but may be the AppUi or even the CoeEnv 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.

+
Description

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.

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.

The sequence diagram below +illustrates the Object Provider process for supplying an interface pointer +from the run-time hierarchy.

+ +

Object1 wishes to call a function on MInterface. +It calls MopGetObject() on the nearest control in the run-time +hierarchy. The Object Provider Framework identifies the Uid for Minterface and +then passes the request up the hierarchy until an object is found (Object4) +that implements Minterface.

Calling MopGetGetObjectNoChaining() will +call MopSupplyObject() but not MopNext(). +It returns Null if the class does not implement the specified mixin.

+
See also

How +to write controls

+
\ No newline at end of file