Its not a question of having enough RAM, you need to have enough address space available in your process. I think you won't have this issue on a 64 bit OS and a 64 bit process. Even a 32 bit process on a 64 bit OS helps as long as the process is Large Address Aware.

Even better idea. Don't use VB! Ever!

Why are you returning anything? How about an item not found exception? If you expect the item to be there and it isn't then you have yourself an exception. If you don't care that it's not in there ignore the exception. Either way, the user of this code doesn't have to decide what you meant by returning true or false.

Yeah I saw it right away too. This code is pretty ugly. Does this use MFC doc/view architecture because the document has much better ways of asking its views if its OK to close.

I guess we could argue this back and forth. It comes down to avoiding mistakes and doing things as a matter of policy. E.g. I never do this: int* y, z; I always do this: int* y; int z; Why you ask. Too easy to read it wrong at a glance, too easy to miss something. Some logic as to why I never use goto's and why I don't put returns anywhere but at the very bottom or very top of a function. I believe this to be more than just a matter of style.

Goto's are really really bad and should be super rarely used. They are not needed for error handling. The only good use I've seen for goto's is machine generated code with tools like YACC and LEX. Generally speaking, break, continue, and multiple returns can cause problems too. Readability and maintainability are very important. Imagine if you will a "come from" statement. You put a label X somewhere then in a totally different part of the method you place a "come from" label X. Whenever control reaches the label you goto the "come from". Imagine how hard it would be to read that code. What's wrong with using exceptions for error handling?

Isn't anyone using Perforce? I've used it a lot a love it. It integrates with Visual Studio rather well. It's free for 2 developers but expensive for 3.

999! i.e. 999 factorial