asked on

CFile::Open returns FALSE

Hi,
I use the CFile class to read a file. This works fine! I can read the file. But: Open returns FALSE.
The TRACE macro prints "Can't open file filename, error = 0"!
fileException.m_cause = 0 means CFileException::none => No error occurred.
So whats wrong?

CFile *pcFile = new CFile();
CFileException fileException;

if ( !pcFile->Open( lpszFileName, CFile::modeReadWrite | CFile::typeBinary ), &fileException )
{
TRACE( "Can't open file %s, error = %u\n", lpszFileName, fileException.m_cause );
}

ASKER CERTIFIED SOLUTION

Blondie050798

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

piano_boxer

Have'nt you written the Open call wrong here ???

if ( !pcFile->Open( lpszFileName, CFile::modeReadWrite | CFile::typeBinary ), &fileException )

should proberly be:

if ( !pcFile->Open( lpszFileName, CFile::modeReadWrite | CFile::typeBinary, &fileException )

piano_boxer

ONE MORE TRY ()("¤#&)"¤:
Should proberly be:

if ( !pcFile->Open( lpszFileName, CFile::modeReadWrite | CFile::typeBinary, &fileException ))
{

}

RONSLOW

As piano points out (but didn't explain) you've put the ',' outside the list of function args. This is quite valid C/C++, but is NOT what you wanted. Instead of being a function arg separator the ',' is now treated as a comma operator. The commad operator evaluates and its left-hand-side, and then evaluates the right-hand-side and returns the right-hand-side value as the overall value. So your code, as you've written is equivalent to:

pcFile->Open( lpszFileName, CFile::modeReadWrite | CFile::typeBinary );
if (&fileException ) {
TRACE( "Can't open file %s, error = %u\n", lpszFileName, fileException.m_cause );
}

And as '&fileException' is non-null, the 'if' always does the TRACE statement.

I hope this clears up your problem and explains what piano_boxer was saying.

RONSLOW

Blondie's answer is INCORRECT .. it does NOT explain the problem.

The use of typeBinary with CFile is NOT a problem .. these flags are simple ignored. Indeed, the CFile::Open acutally masks out this flag.

piano_boxer's answer was correct.

Please ignore Blondie's answer when reading this PAQ

Blondie050798

CFile::typeBinary should not be in the code, but like you say it should not cause a 'problem'...

I pointed this out because it was in direct conflict with the documentation; I thought that the brackets were simply a typo, and hence didn't point that out.

piano_boxer's answer was correct....but don't bother with the binary flag! :-)

RONSLOW

Glad that's cleared up.

The documentation is a little misleading in this case. typeBinary and typeText are (primarily) used for CStdioFile (which is derived from CFile). That way you can open a CStdioFile in either binary or text. They are not invalid for a CFile, but just don't have any meaning as a CFile is ALWAYS opened binary .. the typeBinary is ignored.

You may want to use CStdioFile instead of CFile (and keep the typeBinary flag) .. there is very little difference between CStdioFile and CFile .. just the addition of string/line i/o and the option of text/binary mode.

Blondie050798

Also CStdioFile is buffered whilst CFile isn't.

RONSLOW

True .. hadn't mentioned that, I was thinking more of available member functions .. buffering can make a performance difference, so using CStdioFile instead of CFile may be the better solution anyway