Problem importing C++ headers with DECLARE_MESSAGE

[Bernd Duerrer]

When importing C++ headers containing several classes and the DECLARE_MESSAGE_MAP() macro from Visual C++, EA produces strange output. Consider the following example:

class Test1
{
public:
     Test1();
     ~Test1();
     void DoSomething(void);
     DECLARE_MESSAGE_MAP()
protected:
     int DoSomethingProtected(double x) const;
};

class Test2: public Test1
{
public:
     Test2();
     ~Test2();
     bool DoSomethingElse(void);
private:
     void DoSomethingPrivate(bool b);
};

class Test3: public Test1
{
public:
     Test3();
     ~Test3();
     bool DoSomethingElse(void);
private:
     void DoSomethingPrivate(bool b);
};


EA will create class Test1, but omit everything after DECLARE_MESSAGE_MAP(), including class Test2. Class Test3 is created, but as an inner class, nested in class Test1. By just changing DECLARE_MESSAGE_MAP() to lowercase, everything gets imported okay:
class Test4
{
public:
     Test4();
     ~Test4();
     void DoSomething(void);
     declare_message_map()
protected:
     int DoSomethingProtected(double x) const;
};

class Test5: public Test4
{
public:
     Test5();
     ~Test5();
     bool DoSomethingElse(void);
private:
     void DoSomethingPrivate(bool b);
};

class Test6: public Test4
{
public:
     Test6();
     ~Test6();
     bool DoSomethingElse(void);
private:
     void DoSomethingPrivate(bool b);
};

I have a lot of legacy code which I want to document using EA, so redistributing class definitions (1 class per header) is not really an option. There seems to be some special handling of the DECLARE_MESSAGE_MAP() macro when importing: It would be nice if this could be corrected to avoid these problems.

Best regards,

Bernd

[ronnie]

Just a guess, but what about putting a semicolon at the end of the line?

VC++ allows you to have a blank statement line so even if a macro includes the last semicolon, it is normally ok to add another outside which will result in a blank statement line.

That might let EA assume that the line is a capitalised member function instead of a macro although it might then try to export a function body for it.

Hope this helps a little.

Ronnie

[gsparks]

Hi,

There is a place in EA to define C++ Macros such as DECLARE_MESSAGE_MAP(),  that are to be ignored during import.

Go to the Reference/Language Macros main menu item.
In the dialog, add any macro defenitions that you wish EA to totally ignore.

Re-run the import. EA should then correctly parse the content.

Im not sure why the lowercase version worked - that will require some further investigation!

Geoff Sparks

[Bernd Duerrer]

Thanks for your hint, Geoff: Adding DECLARE_MESSAGE_MAP() to the list of ignored macros solved my problem. However, I ran into another strange phenomenon: I have two header files, which obviously cause a deadlock in EA when importing (i.e. I have to kill EA via the task manager). However, when renaming these files or moving them to a different directory, they get imported without any problems  

It does not seem to be a problem of path length, as they get imported when I leave them in the same directory and just change the last letter of the filename (e.g. GripPosition.h to GripPositiox.h). As I have a workaround for this, this is not an urgent matter at all, but if you look into the import parser anyhow, maybe you find a solution for this, too.

Thanks a lot again for your quick help!

Bernd

[gsparks]

Hi Bernd,

Sounds like the problem will be in the .cpp file if it is in the same directory as the .h files. EA looks in these for implementation details, comments etc. The parser that works on the .cpp file is pretty basic as it does not have much to do - so should not be a problem.... but it sounds to me the likeliest cause.

If you have the .cpp files in the same directory, maybe you could spare me one example - .h and .cpp file to test.

Geoff Sparks

[Bernd Duerrer]

Hi Geoff,

you're absolutely marvellous: It IS a problem with the .cpp-parser. Here is an example:

Test.h
class Test : public CObject  
{
public:
     Test();
     Test(const Test &Source);
     virtual ~Test();
     Test& operator=(const Test &Source);
protected:
     void CopyFromSource(const Test &Source);
     bool m_bModified;
};

Test.cpp
Test::Test()
{
     m_bModified = true;
}

Test::Test(const Test &Source)
{
     CopyFromSource(Source);
}

Test::~Test()
{
}

Test& Test::operator=(const Test &Source)
{
     CopyFromSource(Source);
     return *this;
}

void Test::CopyFromSource(const Test &Source)
{
     m_bModified = true;
}


Importing these files will result in a non-responding application. However, by just moving operator=() in Test.cpp behind CopyFromSource(), it will import OK.

Best regards,

Bernd

[ronnie]

Can you explain this line to me please...

Test&am p; Test::operator=(const Test &Source)

What is the '&am p;' bit for?

Ronnie

[Bernd Duerrer]

Hi Ronnie,

it seems to be a bug in YaBB: It should be Test&. Look what happened to operator=:: in your post...

Regards,

Bernd