epoc32/include/mw/mtclbase.h
branchSymbian2
changeset 3 e1b950c65cb4
parent 2 2fe1408b6811
child 4 837f303aceeb
     1.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     1.2 +++ b/epoc32/include/mw/mtclbase.h	Wed Mar 31 12:27:01 2010 +0100
     1.3 @@ -0,0 +1,550 @@
     1.4 +// Copyright (c) 1998-2009 Nokia Corporation and/or its subsidiary(-ies).
     1.5 +// All rights reserved.
     1.6 +// This component and the accompanying materials are made available
     1.7 +// under the terms of the License "Symbian Foundation License v1.0" to Symbian Foundation members and "Symbian Foundation End User License Agreement v1.0" to non-members
     1.8 +// which accompanies this distribution, and is available
     1.9 +// at the URL "http://www.symbianfoundation.org/legal/licencesv10.html".
    1.10 +//
    1.11 +// Initial Contributors:
    1.12 +// Nokia Corporation - initial contribution.
    1.13 +//
    1.14 +// Contributors:
    1.15 +//
    1.16 +// Description:
    1.17 +//
    1.18 +
    1.19 +
    1.20 +#ifndef __MTCLBASE_H__
    1.21 +#define __MTCLBASE_H__
    1.22 +
    1.23 +#include <e32base.h>		
    1.24 +#include <badesca.h>
    1.25 +#include <msvapi.h>
    1.26 +
    1.27 +#include <cmsvattachment.h>
    1.28 +#include <msvstd.hrh>
    1.29 +#include <cmsvrecipientlist.h>
    1.30 +
    1.31 +/**
    1.32 +UId for 8-bit/16-bit Character set mechanism.
    1.33 +@internalTechnology
    1.34 +@prototype
    1.35 +*/
    1.36 +const TInt KUIDCharacterSet = 999; 
    1.37 +
    1.38 +class CMsvAttachmentWaiter;
    1.39 +
    1.40 +
    1.41 +/** Specifies one or more parts of a message in message-forwarding, message-reply, 
    1.42 +and message-validation functions.
    1.43 +
    1.44 +Standard message parts are defined by the constants that can be added (or 
    1.45 +bitwise-or'ed) together to specify multiple parts. Some message parts may 
    1.46 +not be meaningful for some MTMs.
    1.47 +
    1.48 +Specifies find attributes which modify the behaviour of the search text utility 
    1.49 +provided by the Global Find API. This does not apply to v5.1 nor to v5. */
    1.50 +typedef TUint TMsvPartList;
    1.51 +
    1.52 +class CParaFormatLayer;
    1.53 +class CCharFormatLayer;
    1.54 +
    1.55 +
    1.56 +/** Specifies function IDs for standard MTM functions.
    1.57 +
    1.58 +The function IDs are specified such that they do not coincide
    1.59 +with the free area defined for MTM commands.
    1.60 +
    1.61 +If MTMs also offer their own equivalents of these functions,
    1.62 +they may implement these function IDs by considering the
    1.63 +two IDs to be the same in their client MTM.
    1.64 +
    1.65 +MTMs that support SendAs must support SendMessage.
    1.66 +*/
    1.67 +enum TMtmStandardAsyncCommands
    1.68 +	{
    1.69 +	KMTMStandardFunctionsSendMessage = KMtmFirstFreeStandardMtmFunctionId
    1.70 +	};
    1.71 +
    1.72 +
    1.73 +////////////////////////////////////////////////////////
    1.74 +// Prototype of expected factory function
    1.75 +
    1.76 +typedef CBaseMtm* MtmFactoryFunctionL(CRegisteredMtmDll&, CMsvSession&);
    1.77 +
    1.78 +
    1.79 +/***********************************************
    1.80 +***********************************************/
    1.81 +class CBaseMtm : public CBase, public MMsvEntryObserver
    1.82 +/** Provides a high-level interface for accessing and manipulating a Message Server 
    1.83 +entry. 
    1.84 +
    1.85 +Message client applications use the class to access such functionality polymorphically. 
    1.86 +MTM implementers implement a derived class to provide such functionality for 
    1.87 +their message protocol. 
    1.88 +
    1.89 +The following are some significant groups of functions:
    1.90 +
    1.91 +Context functions: the SetCurrentEntryL() and SwitchCurrentEntryL() functions 
    1.92 +change the context - the entry on which later actions are performed. After 
    1.93 +creating a new Client-side MTM object, a message client application should 
    1.94 +set an initial context before using other functions. Note that: any changes 
    1.95 +made to an existing context are not automatically saved: the message client 
    1.96 +application should ensure this itself by calling SaveMessageL(); no message 
    1.97 +data for the new context is retrieved from the Message Server, to retrieve 
    1.98 +entry data, call LoadMessageL() after setting the context; calling Body() 
    1.99 +immediately after setting the context returns an empty CRichText object: this 
   1.100 +is because the private cache of context body text that the base class maintains 
   1.101 +is re-initialised to an empty value. MTM implementers should note that the 
   1.102 +virtual ContextEntrySwitched() is called from these functions to allow derived 
   1.103 +classes to also clear any caches of MTM-specific entry data.
   1.104 +
   1.105 +Store and restore entry data functions: the changes that a message client 
   1.106 +application makes to a message context through Client-side MTM functions, 
   1.107 +such as altering the body text obtained through Body(), are, for efficiency, 
   1.108 +cached in memory by a Client-side MTM. The message store and restore functions 
   1.109 +are concerned with transferring data between that cache and committed storage. 
   1.110 +Note that, unlike message contexts, message client applications are not expected 
   1.111 +to manipulate directly service contexts. Instead, the corresponding User Interface 
   1.112 +MTM will provide dialogs to allow the user to alter service settings, and 
   1.113 +call Client-side MTM functions to handle their retrieval and storage. Symbian 
   1.114 +OS v5 expects the base class functions to handle storage and retrieval for 
   1.115 +both message and service contexts, and their implementations must detect what 
   1.116 +the context is, and act accordingly. Post-v5, the API is clarified by restricting 
   1.117 +the base class functions to handle message contexts only. To handle service 
   1.118 +contexts, a Client-side MTM must define its own functions for the User Interface 
   1.119 +MTM to call.
   1.120 +
   1.121 +Store and restore body text functions: the base class maintains a private 
   1.122 +CRichText object cache to store the body text for the current context. This 
   1.123 +can be accessed for reading and writing by message client applications through 
   1.124 +Body(). StoreBodyL() and RestoreBodyL() encapsulate for implementers of derived 
   1.125 +classes the retrieval and storage of this CRichText object to a CMsvStore.
   1.126 +
   1.127 +Address list functions: the format and storage of message addresses is MTM-specific. 
   1.128 +AddresseeList(), AddAddresseeL(), and RemoveAddressee() are designed to allow 
   1.129 +clients with no MTM-specific knowledge to access address information in a 
   1.130 +generic way. The base class has a protected data member iAddresseeList, an 
   1.131 +array of descriptors, which these functions manipulate. Implementations should 
   1.132 +save the address information to the appropriate place in the message store 
   1.133 +when the message is stored.
   1.134 +
   1.135 +MTM-specific functionality: MTM components can offer protocol-specific functionality 
   1.136 +not provided by base class interface functions. MTM components define IDs 
   1.137 +that correspond to each protocol-specific operation offered, and implement 
   1.138 +the InvokeSyncFunctionL() and InvokeAsyncFunctionL() functions to allow clients 
   1.139 +to access these operations by passing in the appropriate ID. Two functions 
   1.140 +are provided to allow the MTM component to offer both synchronous and asynchronous 
   1.141 +functionality. Message client applications can dynamically add user-interface 
   1.142 +features for these operations using CBaseMtmUiData::MtmSpecificFunctions(). 
   1.143 +MTM developers should document the IDs if they wish to make the operations 
   1.144 +available to clients. 
   1.145 +@publishedAll
   1.146 +@released
   1.147 +*/
   1.148 +	{
   1.149 +public:
   1.150 +	IMPORT_C ~CBaseMtm();
   1.151 +	IMPORT_C TUid Type() const;
   1.152 +	//
   1.153 +	// context related
   1.154 +	IMPORT_C void SetCurrentEntryL(CMsvEntry* aEntry);
   1.155 +	IMPORT_C void SwitchCurrentEntryL(TMsvId aId);
   1.156 +	IMPORT_C CMsvEntry& Entry() const;
   1.157 +	IMPORT_C TBool HasContext() const;
   1.158 +	//
   1.159 +	//
   1.160 +	/** Commits cached changes to the storage controlled by the Message Server.
   1.161 +	
   1.162 +	It can only be called on message contexts. It should be called in the following circumstances:
   1.163 +	
   1.164 +	1. to preserve changes when the context is changed, or when the Client-side MTM 
   1.165 +	object is deleted 
   1.166 +	
   1.167 +	2. to enable other parts of the Messaging to access the updated entry, as required, 
   1.168 +	for example, before sending a message 
   1.169 +	
   1.170 +	Requirements:
   1.171 +	
   1.172 +	An implementation must update the store and index entry relating to the message 
   1.173 +	context. Typically, the message store should be opened for editing with CMsvEntry::EditStoreL(). 
   1.174 +	It should be updated as follows:
   1.175 +	
   1.176 +	1. body text: call StoreBodyL() to update the store's body text stream
   1.177 +	
   1.178 +	2. address list: update the appropriate MTM-specific area of the store from the 
   1.179 +	data in iAddresseeList
   1.180 +	
   1.181 +	3. subject: if supported, update the appropriate MTM-specific area of the store 
   1.182 +	from the private cache set by SetSubjectL()
   1.183 +	
   1.184 +	Changes can then be committed to the store with CMsvStore::CommitL().
   1.185 +	
   1.186 +	The index entry should also be updated to reflect changes. Possible fields 
   1.187 +	that may need updating include: Description (for subject changes); Details 
   1.188 +	and Multiple Recipients (for recipient changes); and Size. Index entry changes 
   1.189 +	are committed using CMsvEntry::ChangeL().
   1.190 +	
   1.191 +	The function should panic for non-message contexts. */
   1.192 +	virtual void SaveMessageL()=0; 
   1.193 +	/** Loads the cache with the message data for the current context.
   1.194 +	
   1.195 +	It can only be called on message contexts. 
   1.196 +	
   1.197 +	It is typically used after the context has been set with SetCurrentEntryL() 
   1.198 +	or SwitchCurrentEntryL(). CBaseMtm functions to manipulate the entry can only 
   1.199 +	be called after this function has been called.
   1.200 +	
   1.201 +	Requirements:
   1.202 +	
   1.203 +	An implementation must restore the store and index entry relating to the message 
   1.204 +	context. Typically, the message store should be opened for reading with CMsvEntry::ReadStoreL(). 
   1.205 +	It should be then be read to set the following:
   1.206 +	
   1.207 +	1. body text: call RestoreBodyL() to update the cached body text
   1.208 +	
   1.209 +	2. address list: read the appropriate MTM-specific area of the store to update 
   1.210 +	iAddresseeList
   1.211 +	
   1.212 +	3. subject: if supported, read the appropriate MTM-specific area of the store 
   1.213 +	and update the cache with SetSubjectL()
   1.214 +	
   1.215 +	The function should panic for non-message contexts. */
   1.216 +	virtual void LoadMessageL()=0;
   1.217 +	/** Validates the current message context. 
   1.218 +	
   1.219 +	The precise validation performed is specific to the MTM, but, typically, checks 
   1.220 +	that the specified message parts are well-formed. 
   1.221 +	
   1.222 +	Requirements:
   1.223 +	
   1.224 +	Implementation of this function is highly protocol-specific. A minimum step 
   1.225 +	is to check that the current context is a message.
   1.226 +	
   1.227 +	@param aPartList Indicates the message parts for which validation is requested 
   1.228 +	
   1.229 +	@return If valid, KErrNone If invalid, identifies the invalid part(s). The 
   1.230 +	error value is the bitmask of the TMsvPartList IDs for each invalid part */
   1.231 +	virtual TMsvPartList ValidateMessage(TMsvPartList aPartList)=0;
   1.232 +	/** Searches the specified message part(s) for the plain-text version of the text 
   1.233 +	to be found. 
   1.234 +	
   1.235 +	If the specified part list indicates a part that is not supported, or is not 
   1.236 +	present in the current message, the function behaves as if the specified part 
   1.237 +	exists but does not contain the required text.
   1.238 +	
   1.239 +	Requirements:
   1.240 +	
   1.241 +	The parts of the entry for which searching is allowed is implementation specific. 
   1.242 +	If no searching is supported, always return 0.
   1.243 +	
   1.244 +	@param aTextToFind The plain-text version of the text to be found. 
   1.245 +	@param aPartList Indicates the message parts which should be searched. 
   1.246 +	@return If the text was not found, or searching is unsupported, 0. If the text 
   1.247 +	was found, a bitmask of the TMsvPartList IDs for each part in which the text 
   1.248 +	was present. */
   1.249 +	virtual TMsvPartList Find(const TDesC& aTextToFind, TMsvPartList aPartList)=0;
   1.250 +	//
   1.251 +	//
   1.252 +	/** Creates a reply message to the current message context. 
   1.253 +	
   1.254 +	Some MTMs may support inclusion of elements, specified by aPartlist, from 
   1.255 +	the original message in the reply. The parent for the new entry is specified 
   1.256 +	in aDestination. 
   1.257 +	
   1.258 +	The returned CMsvOperation object completes when creating the reply is complete. 
   1.259 +	On completion, the context is set to the reply message.
   1.260 +	
   1.261 +	Requirements:
   1.262 +	
   1.263 +	A typical implementation for this function would include the following steps: 
   1.264 +	
   1.265 +	1. create a new message in the specified destination by calling CMsvEntry::CreateL()
   1.266 +	
   1.267 +	2. set the entry index values as appropriate
   1.268 +	
   1.269 +	3. set the properties of the message as required. The normal minimum is to set 
   1.270 +	the address to the sender of the original message. An implementation may also 
   1.271 +	follow the options specified in aPartlist to set other properties, for example, 
   1.272 +	to include the original message text.
   1.273 +	
   1.274 +	4. set the context to the reply 
   1.275 +	
   1.276 +	5. return a CMsvOperation-derived object to provide asynchronous control and 
   1.277 +	monitoring of the operation
   1.278 +	
   1.279 +	If message replies are not supported, implementations should leave with KErrNotSupported.
   1.280 +	
   1.281 +	The implementation of this function may be similar to that of ForwardL(), 
   1.282 +	allowing opportunities for code sharing.
   1.283 +	
   1.284 +	@param aDestination The entry to which to assign the reply 
   1.285 +	@param aPartlist Defines the parts that are to be copied from the original 
   1.286 +	message into the reply 
   1.287 +	@param aCompletionStatus The request status to be completed when the operation 
   1.288 +	has finished 
   1.289 +	@leave KErrNotSupported The Client-side MTM does not support reply operations 
   1.290 +	@leave Other leave codes Dependent on implementation 
   1.291 +	@return If successful, this is an asynchronously completing reply operation. 
   1.292 +	If failed, this is a completed operation, with status set to the relevant 
   1.293 +	error code. */
   1.294 +	virtual CMsvOperation* ReplyL(TMsvId aDestination, TMsvPartList aPartlist, TRequestStatus& aCompletionStatus)=0;
   1.295 +	/** Creates a forwarded message from the current message context. 
   1.296 +	
   1.297 +	Some MTMs may 
   1.298 +	support inclusion of elements, specified by aPartlist, from the original message 
   1.299 +	in the forwarded message. The parent for the new entry is specified in aDestination. 
   1.300 +	The returned CMsvOperation object completes when editing the forwarded message 
   1.301 +	is complete. On completion, the context is set to the forwarded message.
   1.302 +	
   1.303 +	Requirements:
   1.304 +	
   1.305 +	A typical implementation for this function would include the following steps: 
   1.306 +	
   1.307 +	1. create a new message in the specified destination by calling CMsvEntry::CreateL()
   1.308 +	
   1.309 +	2. set the entry index values as appropriate
   1.310 +	
   1.311 +	3. set message content as required. The normal minimum is to include the text 
   1.312 +	of the original message. An implementation may also follow the options specified 
   1.313 +	in aPartlist to include other properties of the original message.
   1.314 +	
   1.315 +	4. set the context to the reply 
   1.316 +	
   1.317 +	5. return a CMsvOperation-derived object to provide asynchronous control and 
   1.318 +	monitoring of the operation
   1.319 +	
   1.320 +	If forwarded messages are not supported, implementations should leave with 
   1.321 +	KErrNotSupported.
   1.322 +	
   1.323 +	The implementation of this function may be similar to that of ReplyL(), allowing 
   1.324 +	opportunities for code sharing.
   1.325 +	
   1.326 +	@param aDestination The entry to which to assign the forwarded message 
   1.327 +	@param aPartList Defines the parts that are to be copied from the original 
   1.328 +	message into the forwarded message 
   1.329 +	@param aCompletionStatus The request status to be completed when the operation 
   1.330 +	has finished 
   1.331 +	@leave KErrNotSupported The Client-side MTM does not support creation of forwarded 
   1.332 +	messages 
   1.333 +	@leave Other leave codes Dependent on implementation 
   1.334 +	@return If successful, this is an asynchronously completing forward message 
   1.335 +	operation. If failed, this is a completed operation, with status set to the 
   1.336 +	relevant error code. */
   1.337 +	virtual CMsvOperation* ForwardL(TMsvId aDestination, TMsvPartList aPartList, TRequestStatus& aCompletionStatus)=0;
   1.338 +	//
   1.339 +	// addresssee list (used by objects with no MTM knowledge)
   1.340 +	IMPORT_C const CMsvRecipientList& AddresseeList() const;
   1.341 +
   1.342 +	/** Adds an addressee for the current context.
   1.343 +	
   1.344 +	Addresses are not validated by checking their format by this function. Usually 
   1.345 +	that is performed by calling ValidateMessage().
   1.346 +	
   1.347 +	Requirements:
   1.348 +	
   1.349 +	Implementations should append the address to the object's address cache 
   1.350 +	in the protected iAddresseeList data member. Some implementations may also 
   1.351 +	wish to store addresses in an internal data structure appropriate for the 
   1.352 +	protocol, for example, a class holding message header information. 
   1.353 +	
   1.354 +	@param aRealAddress String representing an address to be added to the list 
   1.355 +	for the current message 
   1.356 +	@leave KErrNotSupported The message already has the maximum number of addressees 
   1.357 +	
   1.358 +	@leave Other leave codes Dependent on implementation */
   1.359 +	virtual void AddAddresseeL(const TDesC& aRealAddress)=0;
   1.360 +	/** Adds an addressee for the current context, and enables the client to specify 
   1.361 +	an alias, which may be useful for some protocols. For example, for fax, if 
   1.362 +	the address is the fax number, the alias could supply the recipient's name. 
   1.363 +	
   1.364 +	Addresses are not validated by checking their format by this function. Usually 
   1.365 +	that is performed by calling ValidateMessage().
   1.366 +	
   1.367 +	Requirements:
   1.368 +	
   1.369 +	Implementations should append the address to the object's address cache 
   1.370 +	in the protected iAddresseeList data member. Some implementations may also 
   1.371 +	wish to store addresses in an internal data structure appropriate for the 
   1.372 +	protocol, for example, a class holding message header information. 
   1.373 +	
   1.374 +	@param aRealAddress String representing an address to be added to the list 
   1.375 +	for the current message 
   1.376 +	@param aAlias Alias information 
   1.377 +	@leave KErrNotSupported The message already has the maximum number of addressees 
   1.378 +	
   1.379 +	@leave Other leave codes Dependent on implementation */
   1.380 +	virtual void AddAddresseeL(const TDesC& aRealAddress, const TDesC& aAlias)=0;
   1.381 +	
   1.382 +	IMPORT_C virtual void AddAddresseeL(TMsvRecipientType aType, const TDesC& aRealAddress);
   1.383 +	IMPORT_C virtual void AddAddresseeL(TMsvRecipientType aType, const TDesC& aRealAddress, const TDesC& aAlias);
   1.384 +	
   1.385 +	/** Removes an address from the current address list. The address is specified 
   1.386 +	by a zero-based index into the address list. If the index is not known, applications 
   1.387 +	can use AddresseeList() to retrieve the entire list to find the item.
   1.388 +	
   1.389 +	Requirements:
   1.390 +	
   1.391 +	Implementations should call iAddresseeList->Delete(aIndex) to remove the address 
   1.392 +	from in the address list protected data member.
   1.393 +	
   1.394 +	@param aIndex Index of address to be removed */
   1.395 +	virtual void RemoveAddressee(TInt aIndex)=0;
   1.396 +	//
   1.397 +	// standard data accessor/mutators
   1.398 +	IMPORT_C CRichText& Body();
   1.399 +	IMPORT_C const CRichText& Body() const;
   1.400 +	IMPORT_C virtual void SetSubjectL(const TDesC& aSubject); // default leaves with KErrNotSupported
   1.401 +	IMPORT_C virtual const TPtrC SubjectL() const; // default leaves with KErrNotSupported
   1.402 +	//
   1.403 +	// RTTI functions
   1.404 +	IMPORT_C virtual TInt QueryCapability(TUid aCapability, TInt& aResponse); // default returns KErrNotSupported
   1.405 +	/** Invokes synchronous protocol-specific operations. For asynchronous operations, 
   1.406 +	a similar function, InvokeAsyncFunctionL(), is available.
   1.407 +	
   1.408 +	aSelection and aParameter allow data to be passed to the operation. 
   1.409 +	
   1.410 +	Requirements:
   1.411 +	
   1.412 +	For functionality that requires message transport access, such as making a 
   1.413 +	connection, the implementation should pass the request onto the corresponding 
   1.414 +	Server-side MTM. This is done through calling CMsvSession::TransferCommandL(). 
   1.415 +	Implementations may also provide protocol-specific functions themselves if 
   1.416 +	this is useful.
   1.417 +	
   1.418 +	@param aFunctionId ID of the requested operation 
   1.419 +	@param aSelection Selection of message entries. This is used if the operation 
   1.420 +	requires message entries to work on. 
   1.421 +	@param aParameter Buffer containing input and output parameters. The format 
   1.422 +	of this is specific to the operation. 
   1.423 +	@leave KErrNotSupported aFunctionId is not a recognised operation ID 
   1.424 +	@leave Other leave codes Dependent on implementation */
   1.425 +	virtual void InvokeSyncFunctionL(TInt aFunctionId,const CMsvEntrySelection& aSelection, TDes8& aParameter)=0;
   1.426 +	/** Invokes asynchronous protocol-specific operations. For synchronous operations, 
   1.427 +	a similar function, InvokeSyncFunctionL(), is available.
   1.428 +	
   1.429 +	aSelection and aParameter allow data to be passed to the operation. The TRequestStatus 
   1.430 +	and CMsvOperation objects are used as normal to control and monitor the operation.
   1.431 +	
   1.432 +	Requirements:
   1.433 +	
   1.434 +	For functionality that requires message transport access, such as making a 
   1.435 +	connection, the implementation should pass the request onto the corresponding 
   1.436 +	Server-side MTM. This is done through calling CMsvSession::TransferCommandL(). 
   1.437 +	Implementations may also provide protocol-specific functions themselves if 
   1.438 +	this is useful.
   1.439 +	
   1.440 +	InvokeAsyncFunctionL() should return a CMsvOperation-derived object to provide 
   1.441 +	asynchronous control and monitoring of the operation. If CMsvSession::TransferCommandL() 
   1.442 +	is called, this should be the CMsvOperation object returned by that function.
   1.443 +	
   1.444 +	@param aFunctionId ID of the requested operation 
   1.445 +	@param aSelection Selection of message entries. This is used if the operation 
   1.446 +	requires message entries to work on. 
   1.447 +	@param aParameter Buffer containing input and output parameters. The format 
   1.448 +	of this is specific to the operation. 
   1.449 +	@param aCompletionStatus The request status to be completed when the operation 
   1.450 +	has finished 
   1.451 +	@leave KErrNotSupported aFunctionId is not a recognised operation ID 
   1.452 +	@leave Other leave codes Dependent on implementation 
   1.453 +	@return If successful, this is an asynchronously completing operation. If failed, 
   1.454 +	this is a completed operation, with status set to the relevant error code. */
   1.455 +	virtual CMsvOperation* InvokeAsyncFunctionL(TInt aFunctionId,const CMsvEntrySelection& aSelection, TDes8& aParameter, TRequestStatus& aCompletionStatus)=0;
   1.456 +	//
   1.457 +	IMPORT_C CMsvSession& Session();
   1.458 +
   1.459 +	// Attachment functions to support the SendAs API
   1.460 +	virtual inline void Filler1() {};
   1.461 +	virtual inline void Filler2() {};
   1.462 +	IMPORT_C virtual void AddAttachmentL(const TDesC& aFilePath, const TDesC8& aMimeType, TUint aCharset, TRequestStatus& aStatus);
   1.463 +	IMPORT_C virtual void AddAttachmentL(RFile& aFile, const TDesC8& aMimeType, TUint aCharset, TRequestStatus& aStatus);
   1.464 +	IMPORT_C virtual void AddLinkedAttachmentL(const TDesC& aFilePath, const TDesC8& aMimeType, TUint aCharset, TRequestStatus& aStatus);
   1.465 +	IMPORT_C virtual void AddEntryAsAttachmentL(TMsvId aAttachmentId, TRequestStatus& aStatus);
   1.466 +	IMPORT_C virtual void CreateAttachmentL(const TDesC& aFileName, RFile& aAttachmentFile, const TDesC8& aMimeType, TUint aCharset, TRequestStatus& aStatus);
   1.467 +	IMPORT_C virtual void CancelAttachmentOperation();
   1.468 +
   1.469 +	IMPORT_C virtual void CreateMessageL(TMsvId aServiceId);
   1.470 +
   1.471 +	// BIO functions to support the SendAs API
   1.472 +	// Entry().Entry().iBioType will be set by SendAs if this function does not leave.
   1.473 +	// The default implementation in CBaseMtm is to do nothing.
   1.474 +	IMPORT_C virtual void BioTypeChangedL(TUid aBioTypeUid);
   1.475 +	
   1.476 + 	IMPORT_C virtual TMsvId DefaultServiceL() const;
   1.477 + 	IMPORT_C virtual void RemoveDefaultServiceL();
   1.478 + 	IMPORT_C virtual void ChangeDefaultServiceL(const TMsvId& aService);
   1.479 + 	
   1.480 + 	//For setting the character encoding value, options are 7-bit, 8-bit and 16-bit Unicode.
   1.481 + 	IMPORT_C TInt SetMessageCharacterSet(TUint aCharSet);
   1.482 +
   1.483 +protected:
   1.484 +	IMPORT_C CBaseMtm(CRegisteredMtmDll& aRegisteredMtmDll, CMsvSession& aSession);
   1.485 +	//
   1.486 +	IMPORT_C void StoreBodyL(CMsvStore& aStore);
   1.487 +	IMPORT_C void RestoreBodyL(CMsvStore& aStore);
   1.488 +	//
   1.489 +	/** Called by the base class functions SwitchCurrentEntryL() and SetCurrentEntryL() 
   1.490 +	when the context is changed to another entry. 
   1.491 +	
   1.492 +	Client applications do not use this function. It is relevant only to implementers 
   1.493 +	of derived classes.
   1.494 +	
   1.495 +	Requirements: 
   1.496 +	
   1.497 +	An implementation should clear:
   1.498 +	
   1.499 +	1. address data stored in iAddresseeList
   1.500 +	
   1.501 +	2. any caches of MTM-specific entry data relating to a previous context. For 
   1.502 +	example, if the implementation has a private buffer storing a message subject, 
   1.503 +	for access through Subject(), this buffer should be cleared. */
   1.504 +	virtual void ContextEntrySwitched()=0; // called after the context of this instance has been changed to another entry
   1.505 +	//
   1.506 +	IMPORT_C void HandleEntryEventL(TMsvEntryEvent aEvent, TAny* aArg1, TAny* aArg2, TAny* aArg3);
   1.507 +
   1.508 +	// Method used for extension: called by non virtual methods that need 
   1.509 +	// to have a polymorphic behaviour.
   1.510 +	IMPORT_C virtual TAny* GetInterface(TUid aUid);
   1.511 +	
   1.512 +	// From CBase
   1.513 +	IMPORT_C virtual TInt Extension_(TUint aExtensionId, TAny*& a0, TAny* a1);
   1.514 +
   1.515 +
   1.516 +private:
   1.517 +	void DeleteEntry();
   1.518 +	
   1.519 +	void AddFilePathAttachmentL(const TDesC& aFilePath, const TDesC8& aMimeType, TUint aCharset, CMsvAttachment::TMsvAttachmentType aType, TRequestStatus& aStatus);
   1.520 +
   1.521 +protected:
   1.522 +	/** The current context. */
   1.523 +	CMsvEntry*		iMsvEntry;
   1.524 +	/** The address list for the current context. */
   1.525 +	CMsvRecipientList* iAddresseeList;
   1.526 +
   1.527 +	/** Paragraph formatting applied to the CRichText object for the body text, as 
   1.528 +	returned by Body(). This is set to an empty CParaFormatLayer instance whenever 
   1.529 +	the context is set.
   1.530 +	
   1.531 +	Implementations can modify this if they wish to apply particular formatting 
   1.532 +	to body text. */
   1.533 +	CParaFormatLayer* iParaFormatLayer;
   1.534 +	/** Character formatting applied to the CRichText object for the body text, as 
   1.535 +	returned by Body().
   1.536 +	
   1.537 +	Implementations can modify this if they wish to apply particular formatting 
   1.538 +	to body text. */
   1.539 +	CCharFormatLayer* iCharFormatLayer;
   1.540 +	
   1.541 +private:
   1.542 +	TMsvId	iEntryId;
   1.543 +	CRichText* iRichTextBody;
   1.544 +	CRegisteredMtmDll& iRegisteredMtmDll;
   1.545 +	CMsvSession& iSession;
   1.546 +	CMsvAttachmentWaiter* iAttachmentWaiter;
   1.547 +
   1.548 +	// Extra data member to allow for future extensions
   1.549 +	TAny* iExtensionData;
   1.550 +	};
   1.551 +
   1.552 +
   1.553 +#endif // __MTCLBASE_H__