Skip to main content
gamedev.net
🔒 Locked

Runtime Error

Started by extralongpants Jul 10, 2004 at 12:03 PM 4 replies 600+ views
Original Post
extralongpants
extralongpants
Upon saving a file, in my MFC document/view project, I recieve a Microsoft Visual C++ runtime error: "This application has requested the Runtime to terminate it in an unusual way [etc.]" This only happens in the release build. Using a series of message boxes, I found that the error occurs the first time I attempt to write data to the file. Now a lil' background: All my serialization functions are written with my own serializer class, using the std::ofstream class. Because of this, in the CDocument::OnFileSave() function, I simply set a global boolean to 'TRUE', causing my own save() function to be called during the CWinApp::OnIdle() function. This works perfectly in the Debug build, but when I try and save my file in the Release version, it gives me a runtime error. I don't know if my method for saving has anything to do with the error. I am using Microsoft Visual C++ 6 Every time I build an MFC project in release mode, strange things seem to happen. Any help or advice would be greatly appreciated. Thank you.
Deebo
Deebo
You said the error occurs when you first write to the file. See what is causing tat error. Check for bad pointers and stuff like that.
extralongpants
extralongpants
well, i can't really check for bad pointers, because I'm running in Release mode. And all I'm doing when I first write to the file is writing an int. There aren't really any pointers involved anyway, besides in the std::ofstream object itself. Like I said, this works perfectly in Debug mode. Here is what the relevant parts of my code look like:

MyDocument::OnFileSave(CArchive &ar){    if (ar.IsStoring())    {        gNeedToSave=TRUE;    }    else    {        //...    }}MyApp::OnIdle(LONG lcount){    //...    if(gNeedToSave)    {        save();        gNeedToSave=false;    }    //...}void save(){    Serializer s;    s.openFileForSaving(gFileName);    //here's where the error occurs:    mScene.save(s);    s.closeFile();}Serializer::openFileForSaving(const char *file){    mOut.open(file, ios::out | ios::trunc);}Scene::save(Serializer &s){    //here is the exact moment the error occurs:    s.mOut << myInt; //mOut is just an ofstream object    //...}


Thank you for your suggestion, but I don't think I can really do what you suggested in my situation. This problem really has me stumped.
Deebo
Deebo
Make sure that the file has actually been opened. Thats the only thing I can really think of that can be wrong. I just started using MFC a few days ago myself and I hate it. But right now I need it to to write an application that can test/monitor my library. Mabey you can help me :) click here
ApochPiQ
ApochPiQ
I notice you're not doing any kind of error checking at all; for example, what if the call to open() fails in your openFileForSaving() function? It's a good idea to always have error checking whenever you can, especially when you're looking for bugs in release mode. You might also try adding some logging or tracing code to the serialization class to see if you can get an idea of what is going wrong.

Also there is an outside chance that you're linking to the wrong runtime library when you compile in release mode; check your project settings and make sure that the release mode libraries are the same as the debug mode ones.
extralongpants
extralongpants
Well, the file is indeed open. I thought, when the problem first occured, that I had to be linking to bad libraries/dlls. The mfc project uses a DLL from another project in my workspace. I am rebuilding the DLL project in release mode, and linking MFC project to the lib, with a statement like this:

#ifdef _DEBUG#pragma comment(lib, "..\\Core\\Debug\\Core.lib")#else#prgama comment(lib, "..\\Core\\Release\\Core.lib")#endif


The DLL is always copied into my Windows\System32 directory, regardless of the build.

Is this the correct thing to do?
Under project settings, I also set the library links to be the same under both builds.
Anyway, I'm about ready to give up on assuming it has anything to do with file i/o and libraries. Maybe the problem lies some where else, nested deep in my code. Thanks for all the replies. I hope I can figure this all out.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.