views:

51

answers:

1

If I switch my project from using MFC in a shared DLL to use MFC in a static library, the following code won't compile:

class Test : public CObject
{
public:
    //DECLARE_DYNCREATE(Test); // If I uncomment this line, it works
};

class Test2 : public Test
{
public:
    DECLARE_DYNCREATE(Test2);
};

IMPLEMENT_DYNCREATE(Test2, Test); // <-- error C2039: 'classTest' : is not a member of 'Test'

Though, if I uncomment DECLARE_DYNCREATE(Test), it works. I can't find anything in the docs saying the base class must use DECLARE_DYNCREATE, or that there is a difference between linking statically or shared.

The problem is I have some thirdparty code which doesn't use the DYNCREATE macros. Does anyone know why the requirements differs when linking statically, and if there is a way to get around this without declaring the base class with DECLARE_DYNCREATE?

Thanks.

A: 

If you use IMPLEMENT_DYNCREATE, you need it's companion DECLARE_DYNCREATE too. And you have to use the implement with class and base_class, in your example:

IMPLEMENT_DYNCREATE(Test,CObject);

But I wonder if you need dynamic creation for a CObject-derived class at all. Any reason for this?

dwo
So you always need to declare/implement dyncreate for base classes as well? How come it compiles/links fine without this when using "MFC in a shared DLL"? And regarding the reason, IMPLEMENT/DECLARE_DYNCREATE only works for CObject-derived classes: http://msdn.microsoft.com/en-us/library/5fsfk9dy(VS.80).aspx
Christian Genne
Why do you need the dyncreate at all?
dwo