CBufferedFile::Read - shorter version?...

[GoogleCodeExporter]

This is not a defect/problem...

I was trying to fix this method (because in the "trunk" version), Richesse 
doesn't seem to read the .html info files it generates...

So, after some strange tweaking, I started from scratch and managed to 
implement it as:

BOOL CBufferedFile::Read(LPVOID lpBuffer, DWORD nNumberOfBytesToRead, 
DWORD *nBytesRead/* = NULL*/) {
    BOOL ret;
    DWORD read;
    ret = ReadFile(File, lpBuffer, nNumberOfBytesToRead, &read, NULL);

    if (nBytesRead != NULL)
        *nBytesRead = read;

    return ret && (read > 0);
}

and I wonder if it isn't really what's needed... It seems to work 
correctly although I admit I haven't performed any extensive testing...

Original issue reported on code.google.com by theshade...@gmail.com on 23 Aug 2008 at 1:20

[GoogleCodeExporter]

of course, the above description's second paragraph should read:

"I was trying to fix this method (because in the "trunk" version, Richesse 
doesn't seem to read the .html info files it generates)...

Original comment by theshade...@gmail.com on 23 Aug 2008 at 7:01

[GoogleCodeExporter]

It was not a problem of CBufferedFile. The problem was how it was used.
Fixed by r31.

Original comment by and...@gmail.com on 29 Aug 2008 at 12:13

• Changed state: Fixed

[GoogleCodeExporter]

yeah, I know that there was a problem of the return value vs how the return 
value 
was used... I'm just curious what advantage is there to reading the file to the 
internal buffer (CBufferedFile::Buffer) first and then copying it to the 
external 
one (lpBuffer) instead of just using the external buffer directly with the 
ReadFile 
function... oh, and don't get me wrong, that's not some kind of sarcasm or 
anything, 
I'm really just asking out of curiosity :)...

Original comment by theshade...@gmail.com on 29 Aug 2008 at 1:15