diff -r 51a74ef9ed63 -r ae94777fff8f Symbian3/SDK/Source/GUID-ACC71D0D-32C4-5DAF-B4D9-66013A073FD4.dita --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Symbian3/SDK/Source/GUID-ACC71D0D-32C4-5DAF-B4D9-66013A073FD4.dita Fri Jun 11 12:39:03 2010 +0100 @@ -0,0 +1,50 @@ + + + + + +Synchronising +FEP InstantiationsThis topic describes how to synchronize settings across different +instances of the same FEP. +

As mentioned previously, the FEP architecture has been designed so that +each running application has its own instance of the current FEP. CCoeFep provides +support for synchronizing attributes across all of these instances, so that +when one instance changes the value of an attribute, the others are automatically +updated. In order for this to happen, the FEP has to do several things.

+ +

The purpose of the SynchronouslyExecuteSettingsDialogL() exported +function, which the FEP must provide, is to launch a dialog that allows the +user to change any settings specific to that FEP. As mentioned above, there +is no guarantee that any instance of that particular FEP exists when this +function is called. In order for the dialog launched by SynchronouslyExecuteSettingsDialogL() to +be able to edit settings that are required to be synchronized across all running +applications, the dialog class must derive from MFepAttributeStorer. +The dialog class’ implementation of MFepAttributeStorer ’s +virtual functions should be the same as the CCoeFep -derived +class’ implementation of them. For an example of this, see TFEP1Plugin. When +the dialog is launched it needs to call MFepAttributeStorer::ReadAllAttributesL() to +correctly initialize all the settings. Conversely, the settings in the dialog +are committed by calling MFepAttributeStorer::WriteAttributeDataAndBroadcastL().

+
\ No newline at end of file