FAQ-0742 How do I make sure that my Application works well with a FEP


FAQ-0742 How do I make sure that my Application works well with a FEP

» Symbian OS » Developer Knowledgebase » FAQ-0742

Classification:	General	Category:	Development
Created:	09/28/2001	Modified:	09/11/2002
Number:	FAQ-0742
Platform:	Not Applicable

Question:
Although, on the whole, applications should not have to care too much about FEPs there are a number of things a developer can do to improve the usability of their application if a FEP is present

Answer:
There are 2 methods in which an application developer can make his App integrate better with any available FEPs

1.Handling the Start of a transaction

The following is a fairly common scenario in an Application: The user presses a key and the application responds by doing two things: first, it moves focus to a previously non-focused text-editor control (usually but not exclusively a dialog), and second, it seeds that text-editor control with the character associated with that key. A typical example of this when you press a key in the Agenda Week view and a New Entry dialog appears. If a Fep is present the default behaviour would be to change focus only when the fep has outputted text to the control. However, some Feps, especially those written for Chinese and Japanese locales often require a large amount of text input within the FEP before passing the result to the application. A much better result would be achieved if the focus change happened at the point when the user starts composing their text in the FEP. To do this the application needs to be somewhat FEP-aware

The application which wants to support this functionality must therefore add a FEP observer which will handle these start of transaction events by using the API CCoeEnv::AddFepObserverL() and dealing appropriately when transactions start.

Of course for this to work the FEP must do the right thing and ensure that all observers are informed when starting transaction. This is done through the API CCoeEnv::ForEachFepObserverCall() .

2.Input Capabilities of Controls

It may be desirable for a FEP to change its behaviour depending on the target control underneath it. For example, if the focused control is a number editor, it makes little sense for a FEP to attempt to send anything but numbers to it. CONE provides support for a FEP to inquire the capabilities of the target control - it can then behave accordingly.

This class is well documented in SDK. Any control or application UI that receives key events should ensure that if the default behaviour (inherited from base classes) is not correct the correct settings are returned in overridden versions of following functions:

CCoeAppUi::InputCapabilities

The default implementation of this virtual function is to look at the top focused control on the control-stack and return its input-capabilities merged with the input-capabilities of all of that control's direct or indirect component-controls which are focused. In a similar way to CCoeControl::InputCapabilities, it should be overridden in CCoeAppUi-derived classes that also override HandleKeyEventL - the InputCapabilities function is basically intended to be a "description" of what the HandleKeyEventL does. However, unlike CCoeControl::InputCapabilities, there is no "automatic delegation" - if theHandleKeyEventL function offers its key event to members x, y, and z of the CCoeAppUi-derived class, then the InputCapabilities function should merge the input-capabilities of those of x, y and z that are currently focused and return that. Note that CCoeControl's RecursivelyMergedInputCapabilities rather than InputCapabilities should be called on x/y/z (assuming that they are all objects of CCoeControl-derived classes).

CCoeControl::InputCapabilities

The default implementation of this virtual function is to return TCoeInputCapabilities(TCoeInputCapabilities::ENone). It should be overridden in CCoeControl-derived classes that also override OfferKeyEventL - the InputCapabilities function is basically intended to be a "description" of what the OfferKeyEventL does. It is not necessary, however, in the implementation of InputCapabilities to call InputCapabilities on any component-controls as this is done automatically by CONE. Therefore, if a control's implementation of OfferKeyEventL does not actually phyically test aKeyEvent.iCode against any hard-coded character/key codes (e.g. EKeyEnter, '1', 'a', 0x20ac), then that class does not need to override the InputCapabilities virtual function. As an example, a class that directly handles - say - EKeyTab, EKeyEnter, EKeyLeftArrow, EKeyRightArrow and '0'...'9' in its OfferKeyEventL function should probably return TCoeInputCapabilities(TCoeInputCapabilities::EWesternNumericIntegerPositive|TCoeInputCapabilities::ENavigation) from its InputCapabilities function.

The choices for the reported input capabilities are defined in coeinput.h as follows

enum
{
ENone =0,
EWesternNumericIntegerPositive =0x00000001,
EWesternNumericIntegerNegative =0x00000002,
EWesternNumericReal =0x00000004,
EWesternAlphabetic =0x00000008,
EJapaneseHiragana =0x00000010,
EJapaneseKatakanaHalfWidth =0x00000020,
EJapaneseKatakanaFullWidth =0x00000040,
EDialableCharacters =0x00000080,
ESecretText =0x00000100,
EAllText =0x01000000,
ENavigation =0x02000000
};