epoc32/include/mw/mmsvattachmentmanagersync.h
author William Roberts <williamr@symbian.org>
Wed, 31 Mar 2010 12:33:34 +0100
branchSymbian3
changeset 4 837f303aceeb
parent 3 e1b950c65cb4
permissions -rw-r--r--
Current Symbian^3 public API header files (from PDK 3.0.h)
This is the epoc32/include tree with the "platform" subtrees removed, and
all but a selected few mbg and rsg files removed.
     1 // Copyright (c) 2004-2009 Nokia Corporation and/or its subsidiary(-ies).
     2 // All rights reserved.
     3 // This component and the accompanying materials are made available
     4 // under the terms of "Eclipse Public License v1.0"
     5 // which accompanies this distribution, and is available
     6 // at the URL "http://www.eclipse.org/legal/epl-v10.html".
     7 //
     8 // Initial Contributors:
     9 // Nokia Corporation - initial contribution.
    10 //
    11 // Contributors:
    12 //
    13 // Description:
    14 //
    15 
    16 #ifndef __MMSVATTACHMENTMANAGERSYNC_H__
    17 #define __MMSVATTACHMENTMANAGERSYNC_H__
    18 
    19 #include <e32base.h>
    20 #include <msvstd.h>
    21 #include <cmsvattachment.h>
    22 
    23 class MMsvAttachmentManagerSync
    24 /**
    25 Defines the attachment management extensions interface.
    26 
    27 This class is a pure virtual interface class that defines the APIs to be used for
    28 by MTMs and implementors of MMsvAttachmentManager.
    29 
    30 This API extends the MMsvAttachmentManager with synchronous calls for deleting
    31 and creating attachments. 
    32 
    33 @see CMsvAttachment
    34 @publishedAll
    35 @released
    36 */
    37 	{
    38 public:	
    39 	/**
    40 	Creates a new empty attachment file.
    41 	
    42 	The caller is returned an open writable file handle to an empty attachment file in the message
    43 	store. The caller must pass in an uninitialised file handle. If the request is sucessful the file handle
    44 	is open and must close by the caller once the data has been written to it.
    45 	
    46 	@param aFileName The filename to assign to the newly create attachment file.
    47 	@param aAttachmentFile An uninitialised file handle. This is opened and can be written to if the
    48 		   request is successful. The ownership is transferred . The caller must close the file handle.
    49 	@param aAttachmentInfo The attachment info associated with the file.
    50 	  If the routine does not leave, then ownership will be transferred to the
    51 	  attachment manager. If the routine does leave then ownership will not have
    52 	  been transfered and the caller is responsible for cleanup.
    53 	@leave KErrAccessDenied If attachment manager is in read-only mode.
    54 	*/
    55 	virtual void CreateAttachmentL(const TDesC& aFileName, RFile& aAttachmentFile, CMsvAttachment* aAttachmentInfo) = 0;
    56 
    57 
    58 
    59 	/**
    60 	Renames the physical filename of an attachment.
    61 	
    62 	@param aIndex The array index position of the attachment to be renamed.
    63 	@param aNewName The new name of the attachment.
    64 	@leave KErrAccessDenied If attachment manager is in read-only mode.
    65 	@leave KErrAlreadyExists If the supplied attachment filename already exists.
    66 	*/
    67 	virtual void RenameAttachmentL(TInt aIndex, const TDesC& aNewName) = 0;
    68 
    69 	
    70 	/**
    71 	Removes the attachment from the message entry.
    72 	
    73 	This changes the array index values of all the attachments after the removed one.
    74 	Attachment files stored in the message store are deleted. Linked files and message entry 
    75 	attachments are not deleted, this is left to the caller to do if required.
    76 	
    77 	@param aParam The array index position of the attachment to be removed.
    78 	@leave KErrAccessDenied If attachment manager is in read-only mode.
    79 	*/
    80 	virtual void RemoveAttachmentL(TInt aIndex) = 0;
    81 	
    82 	/**
    83 	Modify existing attachment
    84 	@param aAttachmentInfo The attachment info associated with the file.
    85 	  If the routine does not leave, then ownership will be transferred to the
    86 	  attachment manager. If the routine does leave then ownership will not have
    87 	  been transfered and the caller is responsible for cleanup.
    88 	@leave KErrAccessDenied If attachment manager is in read-only mode.
    89 	*/
    90 	virtual void ModifyAttachmentInfoL(CMsvAttachment* aAttachmentInfo) = 0;
    91 	
    92 	};
    93 
    94 #endif // __MMSVATTACHMENTMANAGERSYNC_H__