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.

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

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,