Comments by krmed (Top 25 by date)

Why are you putting all the "control panel" stuff in your batch file? The only thing you need in the batch file should be the attrib +h c:\whateverdir\*.* /s command.

In the old "DOS" days, a Ctrl-Z marked the end of file (usually). However in today's world, there is normally no such thing as an end of file mark - either text or binary. The file only contains whatever the creator decided.

If you write a data structure from your software, you should know the format, and therefore know how much to read from the file. If you choose to use some kind of EOF indicator in files you create, you need to be aware that that "character" or "sequence" cannot appear anywhere else in the file, so you have to handle that. This is why most files don't contain any such mark.

Hope it helps.

Please show the DeleteContents method - what's being done in there? It should be resetting all doc variables to be as if you have not yet opened a file. You also don't show where you are calling the SetTitle() method of the doc.

Please post the code you have - maybe that will help see where your problem is.

I think you are sadly confused. If you compare INBuffer[2] with 0x02 like this

if (INBuffer[2] == 0x02)you are comparing only a single BYTE.

Each character of INBuffer can only contain ONE character. It's only one byte long. How that charcter is represented is a different matter. Let's say INBuffer[2] contains the letter A.

Here are some of the ways that can be represented:

Decimal representation 65
Hexadecimal representation 0x41

ASCII representation A
Octal representation 0101

Binary representation 1000001

So you see, 0x0A is really a decimal value of 10, which is stored in a single byte. However "0x0A" (as a string) is a character string that is 4 bytes long, plus one byte for the terminating null. To show this stored in INBuffer, you would have:

INBuffer[0] = '0' or 0x30 or 48, etcINBuffer[1] = 'x' or 0x78 or 120, etc

INBuffer[2] = '0' or 0x30 or 48, etcINBuffer[3] = 'A' or 0x41 or 65, etc

INBuffer[4] = 0 (the terminating NULL)

As you can see, each individual character contains a value between 0 and 255, and this can be stored in a single byte.

Hope this helps.

Yes, you set it to null in the constructor, but you don't show where you call the Init function. The first time you call it, it will be NULL (because of the contructor), but if you call it more than once it won't be NULL for the subsequent calls. (You'll notice in my response I said "let's assume it's not NULL").
Good luck.

Sorry - I posted that as a comment instead of a reply to your comment.

Good luck... remember to test the actual operation of the code (especially on Windows 7 as some things have changed).

If you have future problems, I'm sure you can post here and someone will help.
Good luck.

I've updated the answer. Be sure to test thoroughly - just because it compiles and links doesn't necessarily mean it will all work as you think.

Good luck.

Originally, you compiled the program with Visual Studio .NET V7 (2002) and it did not have the improvements that have been added. VS2010 is very compliant with the current C++ specification, and also includes a lot of "safe" functions to help protect agains buffer overruns.

Thanks - I appreciate it.

Thanks - I appreciate it.

Actually, the .c or .cpp isn't VS specific... the C language requires all variables to be defined before any code, but C++ does not. If you mean the unreachable code warning, I'm not sure if that VS specific or not.

memmove will not replicate the first byte throughout all of "data".

According to MSDN:
If some regions of the source area and the destination overlap, both functions ensure that the original source bytes in the overlapping region are copied before being overwritten.

I would think that if someone downvotes an answer they should at least add a comment as to why they feel that way. It's almost enough to discourage anyone from posting any answers.

I didn't say it was a good idea, just answered the OP's question. How can I avoid...
In my opinion (and what I've always done) the appropriate solution is to use strcpy_s (or _tcscpy_s).

strncpy isn't really equivalent since it doesn't append the null at the end of the string, whereas strcpy_s does append it, and makes sure there is room for the terminating null.

If your function is working on the entire array it needs the address of thefirst element. That's normally the case.
Glad I could help.

It won't change the "size" but if you notice, he's using GetCount() - and that WILL change after a delete. Since the initial value of nCount is set to the original GetCount() result, he we be attempting to get elements past the end of what's available.

In his example, he added three elements and thefore nCount is set to 3 and i is 0, and the elements are 0, 1, and 2. After the first delete, i becomes 1 but the valid elements are now 0 and 1. The next time through the loop, i becomes 2, but the only valid index is now 1 - thus the problem.

Yes, of course you can use ofstream (or anything else you want to). MFC provides the CArchive for your use - but you don't have to.