|
||
A message client application typically performs the following steps in a set-up function, such as the ConstructL()
function of the application UI class:
create a CMsvSession
session to the Message Server
create registry classes, so that MTM components can later be instantiated
from the session, obtain the root entry of the index, from which other entries can later be obtained
A message client application can then discover the immediate children of the root entry. To display entries to the user in a typical message/folder view format, the application can query the MTM type of each entry, and load icon resources from the appropriate User Interface MTMs.
After an initial message view display, it is up to the message client application to handle user input events and access User Interface MTMs if required. For example, if the user selects an entry and then chooses an Edit command, the application should:
identify the selected entry and set the context to this entry (so it has instances of the generic message header class TMsvEntry
and of the message encapsulation class CMsvEntry
for the entry)
use the data from the TMsvEntry
object to discover the MTM type that handles the entry
request instances of the relevant Client-side MTM and User Interface MTM objects from the registries
inform the Client-side MTM of the current context
calls the EditL()
function provided by the User Interface MTM. This returns a CMsvOperation
operation object to manage the asynchronous operation.
that operation object completes, e.g. when the user finishes editing, and signals an active object implemented by the client program that this has occurred
that active object handles any action, such as cleanup, that is required
This is the most simple presentation of the steps involved for this single command. Applications with rich user interfaces will define handler functions for many such commands. They will also declare classes to generalise handling of issues such as:
handling multiple operation active objects
caching MTM objects