How to make sure data is saved when application is closed - Programmer

This is a discussion on How to make sure data is saved when application is closed - Programmer ; Hi, I have built mysself the following application from 'Teach Yourself Visual C++ in 21 Days' chapter 'Day 14 - Retrieving Data from an ODBC Database' http://serghei.net/docs/programming/.../ch14/ch14.htm The application lets you edit and add records to a database (as well ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: How to make sure data is saved when application is closed

  1. How to make sure data is saved when application is closed

    Hi,

    I have built mysself the following application from 'Teach Yourself
    Visual C++ in 21 Days' chapter 'Day 14 - Retrieving Data from an ODBC
    Database'

    http://serghei.net/docs/programming/.../ch14/ch14.htm

    The application lets you edit and add records to a database (as well
    as just retreive them). The application uses recordset flags in code
    to make sure that data is saved if you edit one record and move to
    another. However, there is no code to make sure new or edited data is
    saved when the application is exited.

    After having poked about, I have found the ID_APP_EXIT event which I
    can capture for the MainFrame class (IE it works when I select 'exit'
    from the drop down menu), however, I haven't managed to find any way
    of preventing the application from closing in order to perform an 'is
    the data saved?' check when the 'cross' button at the top right hand
    corner of the application is clicked.

    I was hoping I could get some help here. I assume this is more of a
    Win API thing than an MFC thing.

  2. Re: How to make sure data is saved when application is closed

    I'm a newbie myself, but you might want to see about doing this is in
    destructor of the object being closed by the user, not necessarily the
    main class.


  3. Re: How to make sure data is saved when application is closed

    On Tue, 20 Dec 2005 08:24:22 GMT, "kizmet space adventures (remove
    'not.' for emailing)" wrote:

    >Hi,
    >
    >I have built mysself the following application from 'Teach Yourself
    >Visual C++ in 21 Days' chapter 'Day 14 - Retrieving Data from an ODBC
    >Database'
    >
    >http://serghei.net/docs/programming/.../ch14/ch14.htm
    >
    >The application lets you edit and add records to a database (as well
    >as just retreive them). The application uses recordset flags in code
    >to make sure that data is saved if you edit one record and move to
    >another. However, there is no code to make sure new or edited data is
    >saved when the application is exited.
    >
    >After having poked about, I have found the ID_APP_EXIT event which I
    >can capture for the MainFrame class (IE it works when I select 'exit'
    >from the drop down menu), however, I haven't managed to find any way
    >of preventing the application from closing in order to perform an 'is
    >the data saved?' check when the 'cross' button at the top right hand
    >corner of the application is clicked.
    >
    >I was hoping I could get some help here. I assume this is more of a
    >Win API thing than an MFC thing.


    I'm surprised you got so few responses. I didn't respond earlier
    because I thought someone with more specific knowledge would.

    You can trap any attempt to close your app nicely by handling
    WM_COMMAND messages sent from IDOK or IDCANCEL (check value of WPARAM
    arg). If you return FALSE in response to either of these messages,
    your application will remain open.

    You can trap attempts to close your app less nicely by handling
    WM_QUIT messages. I think returning FALSE will also keep your app
    alive.

    You can trap attempts to close your app even less nicely by handling
    WM_DESTROY messages. But I think trying to do much in response to this
    message is risky.

    (This is not so clear as I would like, but I think any attempt I make
    to clarify would instead muddy.)

    -----------------------------------------
    To reply to me, remove the underscores (_) from my email address (and please indicate which newsgroup and message).

    Robert E. Zaret, eMVP
    PenFact, Inc.
    20 Park Plaza, Suite 478
    Boston, MA 02116
    www.penfact.com

  4. Re: How to make sure data is saved when application is closed

    On Tue, 27 Dec 2005 17:49:35 -0500, r_z_aret@pen_fact.com wrote:

    >On Tue, 20 Dec 2005 08:24:22 GMT, "kizmet space adventures (remove
    >'not.' for emailing)" wrote:
    >
    >>Hi,
    >>
    >>I have built mysself the following application from 'Teach Yourself
    >>Visual C++ in 21 Days' chapter 'Day 14 - Retrieving Data from an ODBC
    >>Database'
    >>
    >>http://serghei.net/docs/programming/.../ch14/ch14.htm
    >>
    >>The application lets you edit and add records to a database (as well
    >>as just retreive them). The application uses recordset flags in code
    >>to make sure that data is saved if you edit one record and move to
    >>another. However, there is no code to make sure new or edited data is
    >>saved when the application is exited.
    >>
    >>After having poked about, I have found the ID_APP_EXIT event which I
    >>can capture for the MainFrame class (IE it works when I select 'exit'
    >>from the drop down menu), however, I haven't managed to find any way
    >>of preventing the application from closing in order to perform an 'is
    >>the data saved?' check when the 'cross' button at the top right hand
    >>corner of the application is clicked.
    >>
    >>I was hoping I could get some help here. I assume this is more of a
    >>Win API thing than an MFC thing.

    >
    >I'm surprised you got so few responses. I didn't respond earlier
    >because I thought someone with more specific knowledge would.
    >
    >You can trap any attempt to close your app nicely by handling
    >WM_COMMAND messages sent from IDOK or IDCANCEL (check value of WPARAM
    >arg). If you return FALSE in response to either of these messages,
    >your application will remain open.
    >
    >You can trap attempts to close your app less nicely by handling
    >WM_QUIT messages. I think returning FALSE will also keep your app
    >alive.
    >
    >You can trap attempts to close your app even less nicely by handling
    >WM_DESTROY messages. But I think trying to do much in response to this
    >message is risky.
    >
    >(This is not so clear as I would like, but I think any attempt I make
    >to clarify would instead muddy.)
    >
    >-----------------------------------------
    >To reply to me, remove the underscores (_) from my email address (and please indicate which newsgroup and message).
    >
    >Robert E. Zaret, eMVP
    >PenFact, Inc.
    >20 Park Plaza, Suite 478
    >Boston, MA 02116
    >www.penfact.com


    Thanks for your reply Robert. I'm sorry it took me so long to reply.
    I, too, was surprised at the lack of responses and took re-posted the
    message on microsoft.public.vc.mfc and got a few replies there. I have
    written up what I did in the end below, if you are interested.

    This is my (possibly rather convoluted, but it seems to work)
    solution:-

    1) Created function CRecordView::OnChange() to handle the control's
    EN_CHANGE events.

    void CRecordView::OnChange()
    {
    // TODO: If this is a RICHEDIT control, the control will not
    // send this notification unless you override the
    CRecordView::OnInitDialog()
    // function and call CRichEditCtrl().SetEventMask()
    // with the ENM_CHANGE flag ORed into the mask.

    // TODO: Add your control notification handler code here

    GetDocument()->SetModifiedFlag();

    }

    2) At this point I realized that I needed to call the UpDateData
    function in the view class from the CDoc::SaveModified() function. I
    couldn't work out how to access the view class so I did some searches
    on Google and found the following information at
    http://www.codeproject.com/docview/cviewaccess.asp...

    >>>>>>>>>>>>>


    MFC (Access to CView from Anywhere).

    This is the cheats way of getting access to CView from anywhere in
    your application.

    1. In you CWinApp, create two functions: a void function
    StoreMyView (CView* pView) and a CView* function GetMyView ().
    2. Declare a pointer of type CView in the CWinApp class.
    3. In CView constructor, get the application using the following
    lines:

    CWinApp* pApp = (CWinApp*) AfxGetApp ();
    pApp->StoreMyView (this);

    4. In CWinApp GetMyView (), return your declared pointer.
    5. In CWinApp StoreMyView, point your data member to the parameter
    value, i.e. say, data member is m_pView and parameter is pView; so
    m_pView = pView;
    6. Now you can access your view using the application object, i.e.,

    CWinApp * pApp = (CWinApp*) AfxGetApp ();
    CView * pView = pApp. GetMyView ();

    7. Don't forget to include View.h and Doc.h in CWinApp.h and the
    view.h is included in .cpp files automatically when you create your
    data member in VC++.

    That's all folks.

    Any comments, mail to: kings_oz@yahoo.com.

    <<<<<<<<<<<<<<<<<<<<

    I used this method and it seems to have done exactly what I wanted. I
    would love to know why the author says it is a cheat though.

    3) Using the above method, my CDoc::SaveModified() turned out as
    follows...

    BOOL CDoc::SaveModified()
    {
    // TODO: Add your specialized code here and/or call the base
    class

    if (IsModified()!=0){
    if (AfxMessageBox("There is unsaved data. Do you want
    to save it?",
    MB_OKCANCEL)==IDOK){

    // Save changes to the record
    if (m_dbOdbcSet.CanUpdate() &&
    !m_dbOdbcSet.IsDeleted())
    {
    m_dbOdbcSet.Edit();

    //These three lines make use of the
    'cheat' method
    // for making the view class
    accessible
    CApp * pApp = (CApp*) AfxGetApp ();
    CRecordView * pView = pApp-> GetMyView
    ();
    pView->UpdateData();

    m_dbOdbcSet.Update();
    }
    }
    else
    {
    return FALSE;
    }
    }

    //return CDocument::SaveModified();
    return TRUE;
    }

    Regards,

    Ben Aldhouse,



+ Reply to Thread