This topic introduces miscellaneous guidelines to write a FEP.
Although applications do not need to be FEP-aware in order to work with FEPs, a situation can occur in some applications in which the user interface can be improved by the application making use of a FEPBASE API to communicate with the FEP above it, if there is one.
If
no FEP is present, the expected behaviour in some UIs when the user presses
a key is for the application to do two things: firstly, it moves focus to
a previously non-focused text editor control (possibly, although not necessarily,
by launching a dialog), and secondly, it 'seeds' that text editor control
with the character associated with that key. If there is a FEP, by default
(in other words, without the application being FEP-aware) the focus change
would only happen when the FEP outputs text to the application. However, if
the FEP is designed to allow the user to compose a fairly large block of text
to send to the application (as would be likely in a Japanese FEP), it would
be better if the focus change occurred when the user starts composing their
text in the FEP. In order for this to happen, the application needs to be
FEP-aware, albeit in a fairly trivial way. The way the FEP notifies the application
that it is starting a transaction is by calling CCoeEnv ’s
member function ForEachFepObserverCall() (CCoeEnv is
defined in epoc32\include\COEMAIN.H), passing in the
address of the non-member function FepObserverHandleStartOfTransactionL() (defined
in epoc32\include\FEPBASE.H). It is important to note
that this function should only be called as the last C++ statement executed
when handling an event. The reason for this that it may take a considerable
amount of time to return (for example, it may launch a dialog and only return
when the dialog has been exited).
If
a non-inline-editing FEP has a composition window into which the user types,
that window should not use a 'real' text cursor (in other words, a cursor
which is set and unset using RWindowGroup ’s SetTextCursor() and CancelTextCursor() member
functions). The reason is that the window server only allows a single text
cursor for the whole system at any one time. If the FEP’s target control is
a text editor, it should use the window server’s text cursor itself, so the
FEP should not use it. To solve this problem, the text cursor in the FEP’s
composition window can be simulated with a sprite. The class CTstInsertionPoint in
TFEP1 provides an example of this.
As FEPs get first refusal of all key events, there is a risk that FEPs can intercept shortcut keys (if the UI supports them) which are intended for the application to handle. To define a convention for FEP shortcut keys is non-trivial as different UIs use different modifier keys and have different policies on using them. Matters are simplified greatly if a product has a dedicated on/off key for FEPs as this may be used in combination with other keys to carry out different functions, as well as on its own to turn the FEP on and off. FEP authors should consult the documentation for their target UI.