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