Click here to Skip to main content
Click here to Skip to main content

CDocument::DoSave revealed

, 18 Sep 2002 CPOL
Rate this:
Please Sign up or sign in to vote.
Explains how you can suppress the File-Save-As dialog in a Doc/View app, how to save files to multiple formats, and how DoSave is implemented.

Introduction

For one of my recent projects I had a rather strange requirement. It was an image conversion program basically, and it allowed you to open bitmap files. When the user clicked on the save icon in the toolbar or if he took the save-item from the File-menu, I was to save the image in a custom format using the same name as the original bitmap, but replacing the bmp extension with a custom extension. This meant that I should suppress the File-Save-As dialog. Initially I thought I simply had to override OnSaveDocument and refrain from calling the base class, but I quickly discovered that OnSaveDocument was too late to suppress the File-Save-As dialog.

DoSave revealed

I took a look at doccore.cpp and soon figured out the order in which methods got called inside the CDocument class. Essentially when the user tries to save a file, MFC command routing routes the message to CDocument::OnFileSave or CDocument::OnFileSaveAs depending on whether you clicked on Save or on Save-As. CDocument::OnFileSave calls CDocument::DoFileSave(). CDocument::DoFileSave() checks to see if the file exists and if it does, it proceeds to call CDocument::DoSave passing the full path of the file, else it calls CDocument::DoSave passing NULL for the file path. CDocument::OnFileSaveAs simply calls CDocument::DoSave passing NULL for the file path. Thus eventually we end up in CDocument::DoSave. So I decided that this was the method to override. CDocument::DoSave is declared thus :-

BOOL CDocument::DoSave(LPCTSTR lpszPathName, BOOL bReplace);
  • lpszPathName :- This is the full path of the file to save. If this is NULL the default implementation will prompt the user for a filename and path using the File-Save-As common dialog.
  • bReplace :- If TRUE it will replace an existing file, if FALSE it won't.

In my particular case I was least bothered with the working of the DoSave method. My intention was to get rid of this method totally. So this is what I did - I overrode this member function and did not call the base class implementation.

BOOL CBmpToXyzDoc::DoSave(LPCTSTR lpszPathName, BOOL bReplace)
{   
    //SrcPath is the full path of the current file
    CString DestPath = SrcPath;

    //I replace the extension with the custom one
    DestPath.Replace("bmp","xyz");

    //Now I simply call OnSaveDocument
    OnSaveDocument(DestPath);

    //File saved successfully
    return TRUE;
}

That was just what I had wanted to accomplish. The user never gets prompted and the file is saved using the same name as the original except for the change in extension.

Other plausible applications

While I did not specifically require it for my project, I figured that DoSave can be used for some other purposes too. At least one nifty usage came to my mind. Assume that I wanted to do different things based on some flag. For example assume that I want to show a Save-As dialog with JPG filter if the current file is a GIF and might want to show a Save-As dialog with GIF filter if the current file is a JPG. If so, I could show my own CFileDialog after setting the corresponding OPENFILENAME members.

BOOL CBmpToXyzDoc::DoSave(LPCTSTR lpszPathName, BOOL bReplace)
{   
    CFileDialog fd(false);

    if(m_bgif)
    {
        fd.m_ofn.lpstrFilter="JPG Files(*.jpg)\0*.jpg\0\0";
        fd.m_ofn.lpstrDefExt="jpg";
        fd.m_ofn.lpstrTitle ="Save as JPG";
    }
    else
    {
        fd.m_ofn.lpstrFilter="GIF Files(*.gif)\0*.gif\0\0";
        fd.m_ofn.lpstrDefExt="gif";
        fd.m_ofn.lpstrTitle ="Save as GIF";
    }

    if(fd.DoModal()==IDOK)
    {
        if(m_bgif)
            OnSaveJpgDocument(fd.GetPathName());
        else
            OnSaveGifDocument(fd.GetPathName());
    }

    return TRUE;    
}

Tech notes

The CDocument::DoSave implementation is very interesting. If lpszPathName is NULL, it calls CWinApp::DoPromptFileName :-

if (!AfxGetApp()->DoPromptFileName(newName,
    bReplace ? AFX_IDS_SAVEFILE : AFX_IDS_SAVEFILECOPY,
    OFN_HIDEREADONLY | OFN_PATHMUSTEXIST, FALSE, pTemplate))
{
    return FALSE;
}

CWinApp::DoPromptFileName itself calls CDocManager::DoPromptFileName.

BOOL CWinApp::DoPromptFileName(CString& fileName, 
                               UINT nIDSTitle, 
                               DWORD lFlags,
                               BOOL bOpenFileDialog, 
                               CDocTemplate* pTemplate)
{
    ASSERT(m_pDocManager != NULL);
    return m_pDocManager->DoPromptFileName(fileName, 
        nIDSTitle, lFlags,  bOpenFileDialog, pTemplate);
}

CDocManager::DoPromptFileName simply uses CFileDialog to prompt for a filename.

BOOL CDocManager::DoPromptFileName(CString& fileName, 
                                   UINT nIDSTitle, 
                                   DWORD lFlags, 
                                   BOOL bOpenFileDialog, 
                                   CDocTemplate* pTemplate)
{
    CFileDialog dlgFile(bOpenFileDialog, NULL, NULL, 
        OFN_HIDEREADONLY | OFN_OVERWRITEPROMPT, NULL, NULL, 0);

    CString title;
    VERIFY(title.LoadString(nIDSTitle));

    dlgFile.m_ofn.Flags |= lFlags;

    //...

    INT_PTR nResult = dlgFile.DoModal();

    //...

Of course it does a lot of stuff in addition to just showing the file dialog. For example it will append a *.* filter to your File dialogs, which is why in addition to your document filter, you'll also see a *.* filter in the file type drop-down combo-box. Knowing how the flow proceeds is handy in the sense that if you want to customize it without hooking the window, you might simply override CWinApp::DoPromptFileName and call your own CFileDialog there (remember that this will affect both Open and Save dialogs).

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author

Nish Sivakumar

United States United States
Nish is a real nice guy who has been writing code since 1990 when he first got his hands on an 8088 with 640 KB RAM. Originally from sunny Trivandrum in India, he has been living in various places over the past few years and often thinks it’s time he settled down somewhere.
 
Nish has been a Microsoft Visual C++ MVP since October, 2002 - awfully nice of Microsoft, he thinks. He maintains an MVP tips and tricks web site - www.voidnish.com where you can find a consolidated list of his articles, writings and ideas on VC++, MFC, .NET and C++/CLI. Oh, and you might want to check out his blog on C++/CLI, MFC, .NET and a lot of other stuff - blog.voidnish.com.
 
Nish loves reading Science Fiction, P G Wodehouse and Agatha Christie, and also fancies himself to be a decent writer of sorts. He has authored a romantic comedy Summer Love and Some more Cricket as well as a programming book – Extending MFC applications with the .NET Framework.
 
Nish's latest book C++/CLI in Action published by Manning Publications is now available for purchase. You can read more about the book on his blog.
 
Despite his wife's attempts to get him into cooking, his best effort so far has been a badly done omelette. Some day, he hopes to be a good cook, and to cook a tasty dinner for his wife.

Comments and Discussions

 
GeneralNice article PinmemberKannan Kalyanaraman20-Sep-02 6:21 
GeneralRe: Nice article PineditorNishant S20-Sep-02 15:25 
GeneralRe: Nice article PinmemberRosenkilde6-May-03 5:54 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Terms of Use | Mobile
Web04 | 2.8.141220.1 | Last Updated 19 Sep 2002
Article Copyright 2002 by Nish Sivakumar
Everything else Copyright © CodeProject, 1999-2014
Layout: fixed | fluid