// Copyright (c) 1998-2009 Nokia Corporation and/or its subsidiary(-ies).+
−
// All rights reserved.+
−
// This component and the accompanying materials are made available+
−
// under the terms of "Eclipse Public License v1.0"+
−
// which accompanies this distribution, and is available+
−
// at the URL "http://www.eclipse.org/legal/epl-v10.html".+
−
//+
−
// Initial Contributors:+
−
// Nokia Corporation - initial contribution.+
−
//+
−
// Contributors:+
−
//+
−
// Description:+
−
// MTCLBASE.H+
−
//+
−
/**+
−
 * @file +
−
 * @publishedAll+
−
 * @released+
−
 */+
−
+
−
#ifndef __MTCLBASE_H__+
−
#define __MTCLBASE_H__+
−
+
−
#include <e32base.h>		+
−
#include <badesca.h>+
−
#include <msvapi.h>+
−
+
−
#include <cmsvattachment.h>+
−
#include <msvstd.hrh>+
−
#include <cmsvrecipientlist.h>+
−
+
−
class CMsvAttachmentWaiter;+
−
+
−
/** Specifies one or more parts of a message in message-forwarding, message-reply, +
−
and message-validation functions.+
−
+
−
Standard message parts are defined by the constants that can be added (or +
−
bitwise-or'ed) together to specify multiple parts. Some message parts may +
−
not be meaningful for some MTMs.+
−
+
−
Specifies find attributes which modify the behaviour of the search text utility +
−
provided by the Global Find API. This does not apply to v5.1 nor to v5. */+
−
typedef TUint TMsvPartList;+
−
+
−
class CParaFormatLayer;+
−
class CCharFormatLayer;+
−
+
−
+
−
//+
−
// Prototype of expected factory function+
−
+
−
typedef CBaseMtm* MtmFactoryFunctionL(CRegisteredMtmDll&, CMsvSession&);+
−
+
−
+
−
/** Specifies function IDs for standard MTM functions.+
−
+
−
The function IDs are specified such that they do not coincide+
−
with the free area defined for MTM commands.+
−
+
−
If MTMs also offer their own equivalents of these functions,+
−
they may implement these function IDs by considering the+
−
two IDs to be the same in their client MTM.+
−
+
−
MTMs that support SendAs must support SendMessage.+
−
*/+
−
enum TMtmStandardAsyncCommands+
−
	{+
−
	KMTMStandardFunctionsSendMessage = KMtmFirstFreeStandardMtmFunctionId+
−
	};+
−
+
−
+
−
/***********************************************+
−
***********************************************/+
−
class CBaseMtm : public CBase, public MMsvEntryObserver+
−
/** Provides a high-level interface for accessing and manipulating a Message Server +
−
entry. +
−
+
−
Message client applications use the class to access such functionality polymorphically. +
−
MTM implementers implement a derived class to provide such functionality for +
−
their message protocol. +
−
+
−
The following are some significant groups of functions:+
−
+
−
Context functions: the SetCurrentEntryL() and SwitchCurrentEntryL() functions +
−
change the context - the entry on which later actions are performed. After +
−
creating a new Client-side MTM object, a message client application should +
−
set an initial context before using other functions. Note that: any changes +
−
made to an existing context are not automatically saved: the message client +
−
application should ensure this itself by calling SaveMessageL(); no message +
−
data for the new context is retrieved from the Message Server, to retrieve +
−
entry data, call LoadMessageL() after setting the context; calling Body() +
−
immediately after setting the context returns an empty CRichText object: this +
−
is because the private cache of context body text that the base class maintains +
−
is re-initialised to an empty value. MTM implementers should note that the +
−
virtual ContextEntrySwitched() is called from these functions to allow derived +
−
classes to also clear any caches of MTM-specific entry data.+
−
+
−
Store and restore entry data functions: the changes that a message client +
−
application makes to a message context through Client-side MTM functions, +
−
such as altering the body text obtained through Body(), are, for efficiency, +
−
cached in memory by a Client-side MTM. The message store and restore functions +
−
are concerned with transferring data between that cache and committed storage. +
−
Note that, unlike message contexts, message client applications are not expected +
−
to manipulate directly service contexts. Instead, the corresponding User Interface +
−
MTM will provide dialogs to allow the user to alter service settings, and +
−
call Client-side MTM functions to handle their retrieval and storage. Symbian +
−
OS v5 expects the base class functions to handle storage and retrieval for +
−
both message and service contexts, and their implementations must detect what +
−
the context is, and act accordingly. Post-v5, the API is clarified by restricting +
−
the base class functions to handle message contexts only. To handle service +
−
contexts, a Client-side MTM must define its own functions for the User Interface +
−
MTM to call.+
−
+
−
Store and restore body text functions: the base class maintains a private +
−
CRichText object cache to store the body text for the current context. This +
−
can be accessed for reading and writing by message client applications through +
−
Body(). StoreBodyL() and RestoreBodyL() encapsulate for implementers of derived +
−
classes the retrieval and storage of this CRichText object to a CMsvStore.+
−
+
−
Address list functions: the format and storage of message addresses is MTM-specific. +
−
AddresseeList(), AddAddresseeL(), and RemoveAddressee() are designed to allow +
−
clients with no MTM-specific knowledge to access address information in a +
−
generic way. The base class has a protected data member iAddresseeList, an +
−
array of descriptors, which these functions manipulate. Implementations should +
−
save the address information to the appropriate place in the message store +
−
when the message is stored.+
−
+
−
MTM-specific functionality: MTM components can offer protocol-specific functionality +
−
not provided by base class interface functions. MTM components define IDs +
−
that correspond to each protocol-specific operation offered, and implement +
−
the InvokeSyncFunctionL() and InvokeAsyncFunctionL() functions to allow clients +
−
to access these operations by passing in the appropriate ID. Two functions +
−
are provided to allow the MTM component to offer both synchronous and asynchronous +
−
functionality. Message client applications can dynamically add user-interface +
−
features for these operations using CBaseMtmUiData::MtmSpecificFunctions(). +
−
MTM developers should document the IDs if they wish to make the operations +
−
available to clients. +
−
@publishedAll+
−
@released+
−
*/+
−
	{+
−
public:+
−
	IMPORT_C ~CBaseMtm();+
−
	IMPORT_C TUid Type() const;+
−
	//+
−
	// context related+
−
	IMPORT_C void SetCurrentEntryL(CMsvEntry* aEntry);+
−
	IMPORT_C void SwitchCurrentEntryL(TMsvId aId);+
−
	IMPORT_C CMsvEntry& Entry() const;+
−
	IMPORT_C TBool HasContext() const;+
−
	//+
−
	//+
−
	/** Commits cached changes to the storage controlled by the Message Server.+
−
	+
−
	It can only be called on message contexts. It should be called in the following circumstances:+
−
	+
−
	1. to preserve changes when the context is changed, or when the Client-side MTM +
−
	object is deleted +
−
	+
−
	2. to enable other parts of the Messaging to access the updated entry, as required, +
−
	for example, before sending a message +
−
	+
−
	Requirements:+
−
	+
−
	An implementation must update the store and index entry relating to the message +
−
	context. Typically, the message store should be opened for editing with CMsvEntry::EditStoreL(). +
−
	It should be updated as follows:+
−
	+
−
	1. body text: call StoreBodyL() to update the store's body text stream+
−
	+
−
	2. address list: update the appropriate MTM-specific area of the store from the +
−
	data in iAddresseeList+
−
	+
−
	3. subject: if supported, update the appropriate MTM-specific area of the store +
−
	from the private cache set by SetSubjectL()+
−
	+
−
	Changes can then be committed to the store with CMsvStore::CommitL().+
−
	+
−
	The index entry should also be updated to reflect changes. Possible fields +
−
	that may need updating include: Description (for subject changes); Details +
−
	and Multiple Recipients (for recipient changes); and Size. Index entry changes +
−
	are committed using CMsvEntry::ChangeL().+
−
	+
−
	The function should panic for non-message contexts. */+
−
	virtual void SaveMessageL()=0; +
−
	/** Loads the cache with the message data for the current context.+
−
	+
−
	It can only be called on message contexts. +
−
	+
−
	It is typically used after the context has been set with SetCurrentEntryL() +
−
	or SwitchCurrentEntryL(). CBaseMtm functions to manipulate the entry can only +
−
	be called after this function has been called.+
−
	+
−
	Requirements:+
−
	+
−
	An implementation must restore the store and index entry relating to the message +
−
	context. Typically, the message store should be opened for reading with CMsvEntry::ReadStoreL(). +
−
	It should be then be read to set the following:+
−
	+
−
	1. body text: call RestoreBodyL() to update the cached body text+
−
	+
−
	2. address list: read the appropriate MTM-specific area of the store to update +
−
	iAddresseeList+
−
	+
−
	3. subject: if supported, read the appropriate MTM-specific area of the store +
−
	and update the cache with SetSubjectL()+
−
	+
−
	The function should panic for non-message contexts. */+
−
	virtual void LoadMessageL()=0;+
−
	/** Validates the current message context. +
−
	+
−
	The precise validation performed is specific to the MTM, but, typically, checks +
−
	that the specified message parts are well-formed. +
−
	+
−
	Requirements:+
−
	+
−
	Implementation of this function is highly protocol-specific. A minimum step +
−
	is to check that the current context is a message.+
−
	+
−
	@param aPartList Indicates the message parts for which validation is requested +
−
	+
−
	@return If valid, KErrNone If invalid, identifies the invalid part(s). The +
−
	error value is the bitmask of the TMsvPartList IDs for each invalid part */+
−
	virtual TMsvPartList ValidateMessage(TMsvPartList aPartList)=0;+
−
	/** Searches the specified message part(s) for the plain-text version of the text +
−
	to be found. +
−
	+
−
	If the specified part list indicates a part that is not supported, or is not +
−
	present in the current message, the function behaves as if the specified part +
−
	exists but does not contain the required text.+
−
	+
−
	Requirements:+
−
	+
−
	The parts of the entry for which searching is allowed is implementation specific. +
−
	If no searching is supported, always return 0.+
−
	+
−
	@param aTextToFind The plain-text version of the text to be found. +
−
	@param aPartList Indicates the message parts which should be searched. +
−
	@return If the text was not found, or searching is unsupported, 0. If the text +
−
	was found, a bitmask of the TMsvPartList IDs for each part in which the text +
−
	was present. */+
−
	virtual TMsvPartList Find(const TDesC& aTextToFind, TMsvPartList aPartList)=0;+
−
	//+
−
	//+
−
	/** Creates a reply message to the current message context. +
−
	+
−
	Some MTMs may support inclusion of elements, specified by aPartlist, from +
−
	the original message in the reply. The parent for the new entry is specified +
−
	in aDestination. +
−
	+
−
	The returned CMsvOperation object completes when creating the reply is complete. +
−
	On completion, the context is set to the reply message.+
−
	+
−
	Requirements:+
−
	+
−
	A typical implementation for this function would include the following steps: +
−
	+
−
	1. create a new message in the specified destination by calling CMsvEntry::CreateL()+
−
	+
−
	2. set the entry index values as appropriate+
−
	+
−
	3. set the properties of the message as required. The normal minimum is to set +
−
	the address to the sender of the original message. An implementation may also +
−
	follow the options specified in aPartlist to set other properties, for example, +
−
	to include the original message text.+
−
	+
−
	4. set the context to the reply +
−
	+
−
	5. return a CMsvOperation-derived object to provide asynchronous control and +
−
	monitoring of the operation+
−
	+
−
	If message replies are not supported, implementations should leave with KErrNotSupported.+
−
	+
−
	The implementation of this function may be similar to that of ForwardL(), +
−
	allowing opportunities for code sharing.+
−
	+
−
	@param aDestination The entry to which to assign the reply +
−
	@param aPartlist Defines the parts that are to be copied from the original +
−
	message into the reply +
−
	@param aCompletionStatus The request status to be completed when the operation +
−
	has finished +
−
	@leave KErrNotSupported The Client-side MTM does not support reply operations +
−
	@leave Other leave codes Dependent on implementation +
−
	@return If successful, this is an asynchronously completing reply operation. +
−
	If failed, this is a completed operation, with status set to the relevant +
−
	error code. */+
−
	virtual CMsvOperation* ReplyL(TMsvId aDestination, TMsvPartList aPartlist, TRequestStatus& aCompletionStatus)=0;+
−
	/** Creates a forwarded message from the current message context. +
−
	+
−
	Some MTMs may +
−
	support inclusion of elements, specified by aPartlist, from the original message +
−
	in the forwarded message. The parent for the new entry is specified in aDestination. +
−
	The returned CMsvOperation object completes when editing the forwarded message +
−
	is complete. On completion, the context is set to the forwarded message.+
−
	+
−
	Requirements:+
−
	+
−
	A typical implementation for this function would include the following steps: +
−
	+
−
	1. create a new message in the specified destination by calling CMsvEntry::CreateL()+
−
	+
−
	2. set the entry index values as appropriate+
−
	+
−
	3. set message content as required. The normal minimum is to include the text +
−
	of the original message. An implementation may also follow the options specified +
−
	in aPartlist to include other properties of the original message.+
−
	+
−
	4. set the context to the reply +
−
	+
−
	5. return a CMsvOperation-derived object to provide asynchronous control and +
−
	monitoring of the operation+
−
	+
−
	If forwarded messages are not supported, implementations should leave with +
−
	KErrNotSupported.+
−
	+
−
	The implementation of this function may be similar to that of ReplyL(), allowing +
−
	opportunities for code sharing.+
−
	+
−
	@param aDestination The entry to which to assign the forwarded message +
−
	@param aPartList Defines the parts that are to be copied from the original +
−
	message into the forwarded message +
−
	@param aCompletionStatus The request status to be completed when the operation +
−
	has finished +
−
	@leave KErrNotSupported The Client-side MTM does not support creation of forwarded +
−
	messages +
−
	@leave Other leave codes Dependent on implementation +
−
	@return If successful, this is an asynchronously completing forward message +
−
	operation. If failed, this is a completed operation, with status set to the +
−
	relevant error code. */+
−
	virtual CMsvOperation* ForwardL(TMsvId aDestination, TMsvPartList aPartList, TRequestStatus& aCompletionStatus)=0;+
−
	//+
−
	// addresssee list (used by objects with no MTM knowledge)+
−
	IMPORT_C const CMsvRecipientList& AddresseeList() const;+
−
+
−
	/** Adds an addressee for the current context.+
−
	+
−
	Addresses are not validated by checking their format by this function. Usually +
−
	that is performed by calling ValidateMessage().+
−
	+
−
	Requirements:+
−
	+
−
	Implementations should append the address to the object's address cache +
−
	in the protected iAddresseeList data member. Some implementations may also +
−
	wish to store addresses in an internal data structure appropriate for the +
−
	protocol, for example, a class holding message header information. +
−
	+
−
	@param aRealAddress String representing an address to be added to the list +
−
	for the current message +
−
	@leave KErrNotSupported The message already has the maximum number of addressees +
−
	+
−
	@leave Other leave codes Dependent on implementation */+
−
	virtual void AddAddresseeL(const TDesC& aRealAddress)=0;+
−
	/** Adds an addressee for the current context, and enables the client to specify +
−
	an alias, which may be useful for some protocols. For example, for fax, if +
−
	the address is the fax number, the alias could supply the recipient's name. +
−
	+
−
	Addresses are not validated by checking their format by this function. Usually +
−
	that is performed by calling ValidateMessage().+
−
	+
−
	Requirements:+
−
	+
−
	Implementations should append the address to the object's address cache +
−
	in the protected iAddresseeList data member. Some implementations may also +
−
	wish to store addresses in an internal data structure appropriate for the +
−
	protocol, for example, a class holding message header information. +
−
	+
−
	@param aRealAddress String representing an address to be added to the list +
−
	for the current message +
−
	@param aAlias Alias information +
−
	@leave KErrNotSupported The message already has the maximum number of addressees +
−
	+
−
	@leave Other leave codes Dependent on implementation */+
−
	virtual void AddAddresseeL(const TDesC& aRealAddress, const TDesC& aAlias)=0;+
−
	+
−
	IMPORT_C virtual void AddAddresseeL(TMsvRecipientType aType, const TDesC& aRealAddress);+
−
	IMPORT_C virtual void AddAddresseeL(TMsvRecipientType aType, const TDesC& aRealAddress, const TDesC& aAlias);+
−
	+
−
	/** Removes an address from the current address list. The address is specified +
−
	by a zero-based index into the address list. If the index is not known, applications +
−
	can use AddresseeList() to retrieve the entire list to find the item.+
−
	+
−
	Requirements:+
−
	+
−
	Implementations should call iAddresseeList->Delete(aIndex) to remove the address +
−
	from in the address list protected data member.+
−
	+
−
	@param aIndex Index of address to be removed */+
−
	virtual void RemoveAddressee(TInt aIndex)=0;+
−
	//+
−
	// standard data accessor/mutators+
−
	IMPORT_C CRichText& Body();+
−
	IMPORT_C const CRichText& Body() const;+
−
	IMPORT_C virtual void SetSubjectL(const TDesC& aSubject); // default leaves with KErrNotSupported+
−
	IMPORT_C virtual const TPtrC SubjectL() const; // default leaves with KErrNotSupported+
−
	//+
−
	// RTTI functions+
−
	IMPORT_C virtual TInt QueryCapability(TUid aCapability, TInt& aResponse); // default returns KErrNotSupported+
−
	/** Invokes synchronous protocol-specific operations. For asynchronous operations, +
−
	a similar function, InvokeAsyncFunctionL(), is available.+
−
	+
−
	aSelection and aParameter allow data to be passed to the operation. +
−
	+
−
	Requirements:+
−
	+
−
	For functionality that requires message transport access, such as making a +
−
	connection, the implementation should pass the request onto the corresponding +
−
	Server-side MTM. This is done through calling CMsvSession::TransferCommandL(). +
−
	Implementations may also provide protocol-specific functions themselves if +
−
	this is useful.+
−
	+
−
	@param aFunctionId ID of the requested operation +
−
	@param aSelection Selection of message entries. This is used if the operation +
−
	requires message entries to work on. +
−
	@param aParameter Buffer containing input and output parameters. The format +
−
	of this is specific to the operation. +
−
	@leave KErrNotSupported aFunctionId is not a recognised operation ID +
−
	@leave Other leave codes Dependent on implementation */+
−
	virtual void InvokeSyncFunctionL(TInt aFunctionId,const CMsvEntrySelection& aSelection, TDes8& aParameter)=0;+
−
	/** Invokes asynchronous protocol-specific operations. For synchronous operations, +
−
	a similar function, InvokeSyncFunctionL(), is available.+
−
	+
−
	aSelection and aParameter allow data to be passed to the operation. The TRequestStatus +
−
	and CMsvOperation objects are used as normal to control and monitor the operation.+
−
	+
−
	Requirements:+
−
	+
−
	For functionality that requires message transport access, such as making a +
−
	connection, the implementation should pass the request onto the corresponding +
−
	Server-side MTM. This is done through calling CMsvSession::TransferCommandL(). +
−
	Implementations may also provide protocol-specific functions themselves if +
−
	this is useful.+
−
	+
−
	InvokeAsyncFunctionL() should return a CMsvOperation-derived object to provide +
−
	asynchronous control and monitoring of the operation. If CMsvSession::TransferCommandL() +
−
	is called, this should be the CMsvOperation object returned by that function.+
−
	+
−
	@param aFunctionId ID of the requested operation +
−
	@param aSelection Selection of message entries. This is used if the operation +
−
	requires message entries to work on. +
−
	@param aParameter Buffer containing input and output parameters. The format +
−
	of this is specific to the operation. +
−
	@param aCompletionStatus The request status to be completed when the operation +
−
	has finished +
−
	@leave KErrNotSupported aFunctionId is not a recognised operation ID +
−
	@leave Other leave codes Dependent on implementation +
−
	@return If successful, this is an asynchronously completing operation. If failed, +
−
	this is a completed operation, with status set to the relevant error code. */+
−
	virtual CMsvOperation* InvokeAsyncFunctionL(TInt aFunctionId,const CMsvEntrySelection& aSelection, TDes8& aParameter, TRequestStatus& aCompletionStatus)=0;+
−
	//+
−
	IMPORT_C CMsvSession& Session();+
−
+
−
	// Attachment functions to support the SendAs API+
−
	virtual inline void Filler1() {};+
−
	virtual inline void Filler2() {};+
−
	IMPORT_C virtual void AddAttachmentL(const TDesC& aFilePath, const TDesC8& aMimeType, TUint aCharset, TRequestStatus& aStatus);+
−
	IMPORT_C virtual void AddAttachmentL(RFile& aFile, const TDesC8& aMimeType, TUint aCharset, TRequestStatus& aStatus);+
−
	IMPORT_C virtual void AddLinkedAttachmentL(const TDesC& aFilePath, const TDesC8& aMimeType, TUint aCharset, TRequestStatus& aStatus);+
−
	IMPORT_C virtual void AddEntryAsAttachmentL(TMsvId aAttachmentId, TRequestStatus& aStatus);+
−
	IMPORT_C virtual void CreateAttachmentL(const TDesC& aFileName, RFile& aAttachmentFile, const TDesC8& aMimeType, TUint aCharset, TRequestStatus& aStatus);+
−
	IMPORT_C virtual void CancelAttachmentOperation();+
−
+
−
	IMPORT_C virtual void CreateMessageL(TMsvId aServiceId);+
−
+
−
	// BIO functions to support the SendAs API+
−
	// Entry().Entry().iBioType will be set by SendAs if this function does not leave.+
−
	// The default implementation in CBaseMtm is to do nothing.+
−
	IMPORT_C virtual void BioTypeChangedL(TUid aBioTypeUid);+
−
	+
−
 	IMPORT_C virtual TMsvId DefaultServiceL() const;+
−
 	IMPORT_C virtual void RemoveDefaultServiceL();+
−
 	IMPORT_C virtual void ChangeDefaultServiceL(const TMsvId& aService);+
−
 	+
−
 	//For setting the character encoding value, options are 7-bit, 8-bit and 16-bit Unicode.+
−
 	IMPORT_C TInt SetMessageCharacterSet(TUint aCharSet);+
−
	IMPORT_C void SetExtensionData(TAny* aSortData);+
−
	IMPORT_C TAny* GetExtensionData();+
−
	+
−
protected:+
−
	IMPORT_C CBaseMtm(CRegisteredMtmDll& aRegisteredMtmDll, CMsvSession& aSession);+
−
	//+
−
	IMPORT_C void StoreBodyL(CMsvStore& aStore);+
−
	IMPORT_C void RestoreBodyL(CMsvStore& aStore);+
−
	//+
−
	/** Called by the base class functions SwitchCurrentEntryL() and SetCurrentEntryL() +
−
	when the context is changed to another entry. +
−
	+
−
	Client applications do not use this function. It is relevant only to implementers +
−
	of derived classes.+
−
	+
−
	Requirements: +
−
	+
−
	An implementation should clear:+
−
	+
−
	1. address data stored in iAddresseeList+
−
	+
−
	2. any caches of MTM-specific entry data relating to a previous context. For +
−
	example, if the implementation has a private buffer storing a message subject, +
−
	for access through Subject(), this buffer should be cleared. */+
−
	virtual void ContextEntrySwitched()=0; // called after the context of this instance has been changed to another entry+
−
	//+
−
	IMPORT_C void HandleEntryEventL(TMsvEntryEvent aEvent, TAny* aArg1, TAny* aArg2, TAny* aArg3);+
−
+
−
	// Method used for extension: called by non virtual methods that need +
−
	// to have a polymorphic behaviour.+
−
	IMPORT_C virtual TAny* GetInterface(TUid aUid);+
−
	+
−
	// From CBase+
−
	IMPORT_C virtual TInt Extension_(TUint aExtensionId, TAny*& a0, TAny* a1);+
−
+
−
private:+
−
	void DeleteEntry();+
−
	+
−
	void AddFilePathAttachmentL(const TDesC& aFilePath, const TDesC8& aMimeType, TUint aCharset, CMsvAttachment::TMsvAttachmentType aType, TRequestStatus& aStatus);+
−
	+
−
+
−
+
−
protected:+
−
	/** The current context. */+
−
	CMsvEntry*		iMsvEntry;+
−
	/** The address list for the current context. */+
−
	CMsvRecipientList* iAddresseeList;+
−
+
−
	/** Paragraph formatting applied to the CRichText object for the body text, as +
−
	returned by Body(). This is set to an empty CParaFormatLayer instance whenever +
−
	the context is set.+
−
	+
−
	Implementations can modify this if they wish to apply particular formatting +
−
	to body text. */+
−
	CParaFormatLayer* iParaFormatLayer;+
−
	/** Character formatting applied to the CRichText object for the body text, as +
−
	returned by Body().+
−
	+
−
	Implementations can modify this if they wish to apply particular formatting +
−
	to body text. */+
−
	CCharFormatLayer* iCharFormatLayer;+
−
+
−
+
−
	+
−
private:+
−
	TMsvId	iEntryId;+
−
	CRichText* iRichTextBody;+
−
	CRegisteredMtmDll& iRegisteredMtmDll;+
−
	CMsvSession& iSession;+
−
	CMsvAttachmentWaiter* iAttachmentWaiter;+
−
+
−
	// Extra data member to allow for future extensions+
−
	TAny* iExtensionData;+
−
	};+
−
+
−
+
−
#endif // __MTCLBASE_H__+
−