diff -r 48780e181b38 -r 578be2adaf3e Symbian3/PDK/Source/GUID-E10A3336-9C4C-59A5-B94F-6CECA92FFB9F.dita --- a/Symbian3/PDK/Source/GUID-E10A3336-9C4C-59A5-B94F-6CECA92FFB9F.dita Tue Jul 20 12:00:49 2010 +0100 +++ b/Symbian3/PDK/Source/GUID-E10A3336-9C4C-59A5-B94F-6CECA92FFB9F.dita Fri Aug 13 16:47:46 2010 +0100 @@ -1,89 +1,89 @@ - - - - - -Providing -a Custom Resolver The plug-in framework has a default resolver that selects an appropriate -implementation to suit the client requests. If the algorithm used by the custom -resolver is inappropriate, an interface definition can provide its own custom -resolver. -

Custom resolvers are interface implementations that implement -the CResolver interface. They are instantiated by the framework -in response to the REComSession::CreateImplementationL() calls -that specify to use a particular custom resolver. Custom resolvers must confirm -to other aspects of interface implementations, including providing registration -resource information, and publishing its UID and factory function in an implementation -proxy table.

Additionally, in order to be trusted by ECom, the -plug-in must have the ProtServ capability set in the project file.

A -custom resolver class must derive from CResolver. -The derived class must implement the following inherited functions:

- - -Implement a factory function that takes an MPublicRegistry object -as input. MPublicRegistry provides the resolver with the -list of the implementations registered with the plug-in framework that meet -the requirements of the specified interface. - - -Implement the CResolver::IdentifyImplementationL() function -that takes the UID of the interface for which an implementation is requested. -The resolver uses the resolution parameters and returns the UID of the best-fit -implementation. The best-fit algorithm is specific to each custom resolver. - CResolver::IdentifyImplementationL() returns a list -of all matching implementations. - - -Implement the CResolver::ListAllL() function. - - -Custom resolver -example

The following code depicts a sample customer resolver.

class CExampleResolver : public CResolver - { -public: - // Factory function: - static CExampleResolver* NewL(MPublicRegistry& aRegistry); - ~CExampleResolver(); - - // Implement IdentifyImplementationL() - TUid IdentifyImplementationL(TUid aInterfaceUid, - const TEComResolverParams& aParameters) const; - -// Implement ListAllL - - RImplInfoArray* ListAllL(TUid aInterfaceUid, - const TEComResolverParams& aParameters) const;

The -following code shows a sample standard registration resource required by a -custom resolver.

RESOURCE REGISTRY_INFO theInfo - { - dll_uid = 0x10009DB3; - interfaces = - { - INTERFACE_INFO - // interface_uid value is always 0x10009D90. - { - interface_uid = 0x10009D90; - implementations = - { - IMPLEMENTATION_INFO - { -// uid value is specific to individual resolvers - implementation_uid = 0x10009DB4; - - version_no = 1; -// unused fields - display_name = ""; - default_data = ""; - opaque_data = ""; - } - }; - } - }; - } + + + + + +Providing +a Custom Resolver The plug-in framework has a default resolver that selects an appropriate +implementation to suit the client requests. If the algorithm used by the custom +resolver is inappropriate, an interface definition can provide its own custom +resolver. +

Custom resolvers are interface implementations that implement +the CResolver interface. They are instantiated by the framework +in response to the REComSession::CreateImplementationL() calls +that specify to use a particular custom resolver. Custom resolvers must confirm +to other aspects of interface implementations, including providing registration +resource information, and publishing its UID and factory function in an implementation +proxy table.

Additionally, in order to be trusted by ECom, the +plug-in must have the ProtServ capability set in the project file.

A +custom resolver class must derive from CResolver. +The derived class must implement the following inherited functions:

+ + +Implement a factory function that takes an MPublicRegistry object +as input. MPublicRegistry provides the resolver with the +list of the implementations registered with the plug-in framework that meet +the requirements of the specified interface. + + +Implement the CResolver::IdentifyImplementationL() function +that takes the UID of the interface for which an implementation is requested. +The resolver uses the resolution parameters and returns the UID of the best-fit +implementation. The best-fit algorithm is specific to each custom resolver. + CResolver::IdentifyImplementationL() returns a list +of all matching implementations. + + +Implement the CResolver::ListAllL() function. + + +Custom resolver +example

The following code depicts a sample customer resolver.

class CExampleResolver : public CResolver + { +public: + // Factory function: + static CExampleResolver* NewL(MPublicRegistry& aRegistry); + ~CExampleResolver(); + + // Implement IdentifyImplementationL() + TUid IdentifyImplementationL(TUid aInterfaceUid, + const TEComResolverParams& aParameters) const; + +// Implement ListAllL + + RImplInfoArray* ListAllL(TUid aInterfaceUid, + const TEComResolverParams& aParameters) const;

The +following code shows a sample standard registration resource required by a +custom resolver.

RESOURCE REGISTRY_INFO theInfo + { + dll_uid = 0x10009DB3; + interfaces = + { + INTERFACE_INFO + // interface_uid value is always 0x10009D90. + { + interface_uid = 0x10009D90; + implementations = + { + IMPLEMENTATION_INFO + { +// uid value is specific to individual resolvers + implementation_uid = 0x10009DB4; + + version_no = 1; +// unused fields + display_name = ""; + default_data = ""; + opaque_data = ""; + } + }; + } + }; + } \ No newline at end of file