If it's not an MFC App Wizard generated project you shouldn't have any MFC. The only thing I can see in your code is that you use delete cable instead of delete[] cable in the destructor, but from your previous post I guess that's a typo (you said earlier that the debugger highlighted delete[] cable in the destructor). How is CABLE used in your code? Which methods are called? That may give some clues. Cheers Steen

I think you made a memory overwrite somewhere in your code. MFC new puts guard bytes around your allocated block and checks if something has screwed up your block everytime you call new or delete - that's why you get the message in the destructor, as that's probably the first time after the error occurred that new or delete gets called. Alas, it has nothing to do with the destructor or the delete[] call as such. See this[^] MSDN article for more info. Recheck your code for places where you use strcpy or similar function without checking the length of the arguments, especially your cable variable. Use strncpy instead. Cheers Steen

Set the lpstrInitialDir field of the m_ofn member of CFileDialog prior to calling CFileDialog::DoModal. If you want the dialog that is shown when the user uses the Open item on the File menu in a standard MFC program you have to dig into the doc/view architechture. There was a post about this earlier, that was about the Save dialog buts it's the same story. cheers Steen

You have to customize the OpenFile Dialog template, not a trivial task. Look it up in MSDN. Cheers Steen

bool CLASS_NAME::operator==(CLASS_NAME rhs) const may also work, but I don't think there's anything wrong with your version. There's a nice explanation of operator overloading at http://www.parashift.com/c++-faq-lite/operator-overloading.html#faq-13.5[^] Cheers Steen

Excellent example of an assignment operator overload. Unfortunately this was not what the OP wanted, he asked for a equality operator overload! :rolleyes:

Of course I didn't mean to imply that you would make such an elementary error :-D, but there's no question (at least in my mind :)) that the linker can't find the implementation of CABLE::~CABLE, so something's gotta be wrong. You could try to put {} after the declaration in header file to make ~CABLE inline, that way you're sure it's defined: class CABLE { public: virtual ~CABLE() {}; } If that gets rid of the linker error then recheck the definition of ~CABLE in your code. Regarding calling of the constructor, it's called when temporary CABLE objects are constructed and destructed, for example during an assignment. Furthermore, the second linker error indicates that the destructor is called from a structured exception handler (the "_unwindfunclet" part sounds like stack unwinding to me) Perhaps you could post some code to show the declaration and implemenations, or is it too large chunks? cheers Steen (from my home computer)