|
I'm not displaying any of the file information (as of yet). The files unknown to the user are used mainly for storing output, and reading for input.
Using other files for input/ouput works just fine if the user never "opens" a file. As soon as the user does this, it seems to not create any of the other files required for the output.
In my CMainFrame constructor I have:
CMainFrame::CMainFrame()
{
m_fileName = "inputParams.txt"; //used first for output, later as input
CFile m_filePtr(m_fileName, CFile::modeCreate);
}
Later on, a modeless dialog opens up which first attempts to open m_fileName for reading. It will successfully do this as long as the user has not "opened" a file:
BOOL CSetupModeless::OnInitDialog()
{
CDialog::OnInitDialog();
CFileException e;
CFile paramFilePtr = ((CMainFrame*)m_parent)->m_filePtr;
paramFileName = ((CMainFrame*)m_parent)->m_fileName;
//attempt to open inputParams.txt for reading only
if((paramFilePtr.Open(paramFileName, CFile::modeRead, &e )) == false )
{
//it will only come in here if user "opened" a file first
AfxMessageBox("error");
}
else
{
//it will come in here all the time, until
//the user "opens" a file... this is where it should go!
}
return TRUE;
}
Anyone know what would stop it from entering into the else when the user "opens" a file?
|
|
|
|
|
 I notice a couple of glaring problems with your code:
1. In your CMainFrame constructor you initialize the m_filePtr member, but in reality you're not! All you're doing is creating a local variable called m_filePtr, which then immediately gets destroyed when the constructor exits. You should do it this way instead:
CMainFrame::CMainFrame()
{
m_fileName = "inputParams.txt";
m_filePtr.Open(m_fileName, CFile::modeCreate);
}
OR even better,
CMainFrame::CMainFrame() :
m_fileName("inputParams.txt"),
m_filePtr(m_fileName, CFile::modeCreate)
{
}
2. Inside your OnInitDialog, you should retrive a reference to your m_filePtr member, not a copy (although I'm not sure what that does):
CFile& paramFilePtr = ((CMainFrame*)m_parent)->m_filePtr;
I hope this helps.
Regards,
Alvaro
Hey! It compiles! Ship it.
|
|
|
|
|
I'll try fixing that up a bit tomorrow... I see what you mean about what I had in my MainFrame constructor, although it confuses me as to why it would work every other time I ran my program (always works as long as the user never actually opens a file)...
Thanks a lot for your help... and hopefully I'll get this all straightened out!
|
|
|
|
|
The frame object should not have anything to do with files. It's for frame manipulation. Having a CFile object anywhere near it is a fundamentally bad idea.
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
So then where should I be attempting to create this file? I need this file to exist throughout the entire program execution, so I don't want to create it every time the modeless dialog that uses it opens up.
Is it best to maybe put that CFile object inside the Doc class?
|
|
|
|
|
b_girl wrote:
...so I don't want to create it every time the modeless dialog that uses it opens up.
If the file and the dialog are that closely related, why not let the dialog object open/close the file accordingly? Otherwise, leaving a file open for the duration of the application is an invitation for trouble.
b_girl wrote:
Is it best to maybe put that CFile object inside the Doc class?
It's certainly better than the frame's class. Whether it's "best" or not would depend on some other factors, which are unknown at this point.
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
DavidCrow wrote:
why not let the dialog object open/close the file accordingly?
the dialog object does open/close the file whenever it needs to. the file doesn't stay open the whole time. i'm talking about just creating the file (with mode::Create). as of right now, the mainframe class creates the file but that's all it does. the rest of the operations on the file are carried out by the dialog object.
|
|
|
|
|
b_girl wrote:
i'm talking about just creating the file (with mode::Create).
Let the dialog object create the file, too.
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
But the dialog object may be created/destroyed more than once... and i need that file to stay in-tact. the first time the dialog object is created, the file will be used for writing. the file needs to remain after the dialog object is destroyed, because every other time the dialog object is created the file will be used for reading.
|
|
|
|
|
b_girl wrote:
the file needs to remain after the dialog object is destroyed...
Files don't go away, unless they are explicitly deleted. The persistence of a disk file has nothing to do with whether an object (e.g., dialog) exists or not.
What is wrong with:
class CMyDialog : public CDialog
{
private:
CStdioFile file;
};
BOOL CMyDialog::OnInitDialog( void )
{
CDialog::OnInitDialog();
file.Open(_T("..."), CFile::modeCreate | CFile::modeNoTruncate | CFile::modeReadWrite);
or
int nMode = CFile::modeCreate | CFile::modeNoTruncate;
if (_access(_T("..."), 0) == 0)
nMode |= CFile::modeRead;
else
nMode |= CFile::modeWrite;
file.Open(_T("..."), nMode);
or
int nMode;
if (_access(_T("..."), 0) == 0)
nMode = CFile::modeRead;
else
nMode = CFile::modeCreate | CFile::modeWrite;
file.Open(_T("..."), nMode);
}
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
you know, maybe there's nothing wrong with that. i didn't realize you could combine modes like that.
i'm assuming this:
file.Open(_T("..."), CFile::modeCreate | CFile::modeNoTruncate | CFile::modeReadWrite);
will create the file if it hasn't been created, and allow it to be read/written...
like i said before (or i think i did at least), i'm somewhat new to programming for windows with vc++, so i don't completely know all the little tricks and such.
|
|
|
|
|
b_girl wrote:
...so i don't completely know all the little tricks and such.
For more "tricks," see these two links:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/_mfc_cfile.3a3a.cfile.asp
http://msdn.microsoft.com/library/en-us/vclib/html/_mfc_CFile.3a3a.Open.asp?frame=true
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
The file still doesn't contain any data after it's been written to. This is what I have:
class CMyDialog : public CDialog
{
private:
CStdioFile file;
};
BOOL CSetupModeless::OnInitDialog()
{
CDialog::OnInitDialog();
paramFileName = "inputParams.txt";
if((paramFile.Open(paramFileName, CFile::modeCreate | CFile::modeNoTruncate | CFile::modeReadWrite)) == 0)
AfxMessageBox("error opening paramFile");
}
void CSetupModeless::OnOK()
{
CString setupInput;
setupInput = setup->constructSetupInput();
AfxMessageBox(setupInput); //check to make sure string comes back with proper info
paramFile.WriteString(setupInput);
paramFile.Close();
}
Is there anything wrong with that??? constructSetupInput is just a function that returns the string that needs to be written to the file. The value of setupInput does come back correctly.
|
|
|
|
|
void CSetupModeless::OnOK()
{
CString setupInput = setup->constructSetupInput();
AfxMessageBox(setupInput);
if (NULL != paramFile.m_pStream && paramFile.m_hFile != CFile::hFileNull)
{
TRY
{
paramFile.WriteString(setupInput);
paramFile.Close();
}
CATCH(CFileException, *e)
{
e->ReportError();
}
}
}
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
well, the solution to my problem was a lot simpler than i was expecting.
i had:
paramFileName = "inputParams.txt";
if(paramFile.Open(paramFileName, CFile::modeCreate| CFile::modeNoTruncate | CFile::modeReadWrite) == 0)
AfxMessageBox("error opening paramFile");
when i should have just had:
if(paramFile.Open(_T("C:\\inputParams.txt"), CFile::modeCreate| CFile::modeNoTruncate | CFile::modeReadWrite) == 0)
AfxMessageBox("error opening paramFile");
What does the _T("..") mean?
Thank you sooo much for all your help!
|
|
|
|
|
The _T() macro is not what solved your problem. Using an absolute path is.
b_girl wrote:
What does the _T("..") mean?
It will eventually resolve to something familiar. Put your cursor on it and press F12.
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
Is there any way to find out the directory that the progam is running out of?
I have found out how to get the current working directory, but this is not what I want because if the user changes directories, the current working directory changes with it. I want to be able to have these extra files in the directory that my program is running out of.
I have done this:
BOOL CSetupModeless::OnInitDialog()
{
int drive, maxLength;
maxLength = 100;
drive = _getdrive();
static char path[100];
_getdcwd(drive,path,maxLength);
//...
}
but that doesn't give me the desired results.
|
|
|
|
|
GetModuleFileName[Ex]() will do it.
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
Ok, now it seems to recognize that the extra files are there... But, for example, after a user "opens" a file, no matter how much info I write into any of the extra files I have, they always end up remaining empty. The write operation seems to be doing what it's supposed to be doing, but I don't understand why the files are still empty after writing. If the user doesn't "open" a file, any information written to the extra files does, in fact, get written to the files (and remains in the files after program execution)
|
|
|
|
|
SDI = single document, which means only one file is open at any given time. As for other non-document files that the program needs, use as many as is necessary.
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
I have created a dialog that is rendered into by an OpenGL RC.
Now that I have that going I'd like to be able to add a few control variables.
What I'd like to do is set OpenGL to only render into a portion of the dialog..... I was wondering how I'd go about this, do I have to create another window in the dialog?
If so, what type is appropriate, I'm only getting started with MFC.
A quick aside, in my OnPaint() I call the base OnPaint() function and THEN render my scene, yet the OK and CANCEL buttons still get painted. Shouldn't they be painted over by RC?
|
|
|
|
|
I would create a picture control inside the dialog and assign a CStatic control variable to it, say m_cPic. Then in OnInitDialog you can get a DC for the picture control and assign this DC to the OpenGL rendering context. Something like
HDC hdc = m_cPic.GetDC()->GetSafeHdc();
wglMakeCurrent(hdc, hGLRC); // hGLRC is handle to the OpenGL rendering context
This approach worked for me before.
|
|
|
|
|
Thanks I'll give it a go.
Is any special cleanup necessary if you use this approach?
|
|
|
|
|
You should release the device context hdc using ::ReleaseDC API function
|
|
|
|
|
ComboController wrote:
A quick aside, in my OnPaint() I call the base OnPaint() function and THEN render my scene, yet the OK and CANCEL buttons still get painted. Shouldn't they be painted over by RC?
You window gets its OnPaint() first because its at the back of the TAB or window order. The OK/Cancel buttons gets theirs after the dialogs OnPaint(), so they would appear over your scene.
On a second not, when your added your own OnPaint() function for your dialog, you would have seen a comment such as:
<br />
This is a bad thing to do, as the CDC parameter passed through to the OnPaint() handler gets setup in some way by the system, so what your doing could crash/corrupt things. If you can, see if you can avoid calling the base class function in this way.
Roger Allen
Sonork 100.10016
Were you different as a kid? Did you ever say "Ooohhh, shiny red" even once? - Paul Watson 11-February-2003
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
