diff -r 51a74ef9ed63 -r ae94777fff8f Symbian3/SDK/Source/GUID-6CEAFE12-EB30-5231-94F4-2D097E79BFE0-GENID-1-8-1-6-1-1-4-1-8-1-4-1-4-1.dita --- a/Symbian3/SDK/Source/GUID-6CEAFE12-EB30-5231-94F4-2D097E79BFE0-GENID-1-8-1-6-1-1-4-1-8-1-4-1-4-1.dita Wed Mar 31 11:11:55 2010 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,141 +0,0 @@ - - - - - -Implementing -the FEP APIThis topic describes various implementations of FEP. -
Post-platform -security – the ECom plugin interface

In the secure platform, FEPs -must be implemented as ECom plug-ins. ECom provides a secure environment for -loading FEPs that cannot be achieved using standard, non-ECom polymorphic -DLLs. The main tasks that are specific to implementing a FEP as an ECom plug-in -are described in this section. Note that the differences between pre- and -post-platform security FEPs are imposed by the change from old-style, standard -polymorphic DLLs to ECom plugins. The C++ APIs involved in FEP creation, which -are defined in fepbase.h, are unchanged.

-
Define a class -that implements the CCoeFepPlugIn interface

This class must implement -the NewFepL() and SynchronouslyExecuteSettingsDialogL() functions -that were, pre-platform security, the first and second exports from the DLL. -Note that these functions have been redefined and no longer take the const TDesC& -aFullFileNameOfDll argument: the ECom plugin implementation is identified -by a UID rather than a filename. This means that the implementation of SynchronouslyExecuteSettingsDialogL() is -now responsible for locating the resource file needed to execute the settings -dialog itself.

class CCoeFepPlugIn : public CBase - { -public: - inline static CCoeFepPlugIn* NewL(TUid aFepUid); - virtual ~CCoeFepPlugIn(); -public: - virtual CCoeFep* NewFepL(CCoeEnv& aConeEnvironment, const CCoeFepParameters& aFepParameters) = 0; - virtual void SynchronouslyExecuteSettingsDialogL(CCoeEnv& aConeEnvironment) = 0; - }; -
-
Provide the -factory code required to instantiate the derived class

FEPs must -provide the standard factory code required by every ECom plugin. For more -information, see “Using ECom” in the Symbian Developer Library. For example, -(the following code is taken from TFEP1PlugIn.cpp):

const TInt KTstFepPlugInImplementationValue = 0x102024D0; -const TImplementationProxy ImplementationTable[] = - { - IMPLEMENTATION_PROXY_ENTRY(KTstFepPlugInImplementationValue, CTstFepPlugIn::NewL ) - }; -EXPORT_C const TImplementationProxy* ImplementationGroupProxy(TInt& aTableCount) - { - aTableCount = sizeof(ImplementationTable) / sizeof(TImplementationProxy); - return ImplementationTable; - } -CTstFepPlugIn* CTstFepPlugIn::NewL() - { // static - return new(ELeave) CTstFepPlugIn; - } -
-
Create an ECom -resource file

Each FEP must have an ECom resource file. Its interface -UID must be 0x1020233f, or CONE will not be able to find the FEP. For example,

#include <RegistryInfo.rh> - -RESOURCE REGISTRY_INFO theInfo - { - dll_uid = 0x102024D0; // UID3 of the DLL - interfaces = - { - INTERFACE_INFO - { - interface_uid = 0x1020233F; // Same for every FEP - implementations = - { - IMPLEMENTATION_INFO - { - implementation_uid = 0x102024D0; - version_no = 1; - display_name = "FEPNAME"; - default_data = ""; - opaque_data = ""; - } - }; - } - }; - }
-
The CCoeFep -class

The parts of CCoeFep relevant to classes -deriving from it are shown below:

class CCoeFep : public CBase, protected MFepAttributeStorer, public MCoeForegroundObserver, public MCoeFocusObserver -{ -public: - enum TEventResponse - { - EEventWasNotConsumed, - EEventWasConsumed - }; - class MDeferredFunctionCall - { - public: - virtual void ExecuteFunctionL()=0; - }; - class MModifiedCharacter - { - public: - virtual TUint CharacterCode() const=0; - virtual TUint ModifierMask() const=0; - virtual TUint ModifierValues() const=0; - }; -public: - IMPORT_C virtual ~CCoeFep(); - virtual void CancelTransaction()=0; -protected: - IMPORT_C CCoeFep(CCoeEnv& aConeEnvironment); - IMPORT_C void BaseConstructL(const CCoeFepParameters& aFepParameters); - IMPORT_C void ReadAllAttributesL(); - IMPORT_C void MakeDeferredFunctionCall(MDeferredFunctionCall& aDeferredFunctionCall); - IMPORT_C void SimulateKeyEventsL(const TArray<TUint>& aArrayOfCharacters); - IMPORT_C void SimulateKeyEventsL(const TArray<MModifiedCharacter>& aArrayOfModifiedCharacters); - IMPORT_C void WriteAttributeDataAndBroadcastL(TUid aAttributeUid); - IMPORT_C void WriteAttributeDataAndBroadcastL(const TArray<TUid>& aAttributeUids); - IMPORT_C TBool IsOn() const; -private: - virtual void IsOnHasChangedState()=0; - virtual void OfferKeyEventL(TEventResponse& aEventResponse, const TKeyEvent& aKeyEvent, TEventCode aEventCode)=0; - virtual void OfferPointerEventL(TEventResponse& aEventResponse, const TPointerEvent& aPointerEvent, const CCoeControl* aWindowOwningControl)=0; - virtual void OfferPointerBufferReadyEventL(TEventResponse& aEventResponse, const CCoeControl* aWindowOwningControl)=0; - }; -

Note that CCoeFep inherits, but does not -override, some pure virtual functions from its base classes MFepAttributeStorer, MCoeForegroundObserver and MCoeFocusObserver. These therefore need to be overridden in addition -to CCoeFep ’s own pure virtual member functions. The details -of the member functions of CCoeFep and its base classes -are explained in various sections of this document.

-
The CCoeControl -class

The CCoeControl class (defined in epoc32\include\COECNTRL.H) -provides many useful features for implementing a FEP, such as functions for -handling window server events. In fact, for FEPs wishing to intercept key -events, writing a class that derives from CCoeControl is -a necessity because of the need to use the control stack (see Intercepting key events, below). Thus although deriving from CCoeControl is -not explicitly demanded by the FEP architecture, it is assumed throughout -this document that the object of the CCoeFep derived -class owns an object of a CCoeControl derived class.

-
\ No newline at end of file