Mintguy
June 14th, 2001, 10:11 AM
Hi.
I just got a beta of Visual Studio.Net from MS the other day and decided to try to compile the project I'm currently working on in this environment. I got it to compile without out too much modification.
I think there may be a bug in the latest version of MFC related to CRuntimeClass. I have an Extension Dll with about 30 MFC classes which use DECLARE_SERIAL (actually a custom version to ensure that the operator>> (CArchive& ar, class_name* &pOb) function is exported). When the dll is loaded the CRuntimeClass for each of these C++ classes adds itself to the module's registered class list in alphabetical order so that the m_pNextClass member of each CRuntimeClass points to the previously registed class. For some reason this chain of CRuntimeClass's is being broken. If I break the program execution on the call in MFC to AfxClassInit, I can see as the m_pNextClass member is updated, and I can follow all of the chained classes by looking in the watch window at this member for each class in the list. However at one particular instance if I try to follow thru the chain I can see that one of the m_pNextClass members has been reset to NULL. There is no obvious reason why this should happen. It occurs on one particular class, but if I remove the DECLARE_SERIAL & IMPLEMENT_SERIAL macros from that class I just get the same problem on another class which was behaving fine before. This behaviour doesn't occur if I compile the same code on with VC6. The result of this chain being broken is that when I try to serialize in a file saved from a VC6 build, the program cannot find some of the classes in the list of registed classes for the application (& dlls) and an error of file format invalid is generated.
Can anyone confirm whether this is a bug in VC.Net?
It may of course be a bug in my code but I don't think it is because there is nothing significantly different about the classes which break the chain, the CRuntimeClass code is mainly generated from macros and the bug doesn't manifest itself in VC6.
Any help much appreciated.
I will have to limit my evaluation of VC.Net to test projects and samples.
Eugene Gill
I just got a beta of Visual Studio.Net from MS the other day and decided to try to compile the project I'm currently working on in this environment. I got it to compile without out too much modification.
I think there may be a bug in the latest version of MFC related to CRuntimeClass. I have an Extension Dll with about 30 MFC classes which use DECLARE_SERIAL (actually a custom version to ensure that the operator>> (CArchive& ar, class_name* &pOb) function is exported). When the dll is loaded the CRuntimeClass for each of these C++ classes adds itself to the module's registered class list in alphabetical order so that the m_pNextClass member of each CRuntimeClass points to the previously registed class. For some reason this chain of CRuntimeClass's is being broken. If I break the program execution on the call in MFC to AfxClassInit, I can see as the m_pNextClass member is updated, and I can follow all of the chained classes by looking in the watch window at this member for each class in the list. However at one particular instance if I try to follow thru the chain I can see that one of the m_pNextClass members has been reset to NULL. There is no obvious reason why this should happen. It occurs on one particular class, but if I remove the DECLARE_SERIAL & IMPLEMENT_SERIAL macros from that class I just get the same problem on another class which was behaving fine before. This behaviour doesn't occur if I compile the same code on with VC6. The result of this chain being broken is that when I try to serialize in a file saved from a VC6 build, the program cannot find some of the classes in the list of registed classes for the application (& dlls) and an error of file format invalid is generated.
Can anyone confirm whether this is a bug in VC.Net?
It may of course be a bug in my code but I don't think it is because there is nothing significantly different about the classes which break the chain, the CRuntimeClass code is mainly generated from macros and the bug doesn't manifest itself in VC6.
Any help much appreciated.
I will have to limit my evaluation of VC.Net to test projects and samples.
Eugene Gill