Messages

1

Automation Interface, Add-Ins and Tools / Re: Loss of information on Round-tripping

« on: December 13, 2007, 12:28:47 pm »

Hi,
Highlight off, Reference char = &,  and suffix.

We are generating C++

2

Automation Interface, Add-Ins and Tools / Loss of information on Round-tripping

« on: December 13, 2007, 06:36:51 am »

Hi all,

In another thread, I queried about the behavior of the code generator and the triggers to have it add the #include for each class referenced in a new class.

Well, after some playing around, we have noticed that if parameters and return values are always defined as the object classifier name, and the parameter name is defined as name, *name, or &name,  the code generator ALWAYS output the correct #include for the referenced object.

When the code is reversed, the parameter defintion returns to the way EA wants it defined:  ie name: &classifier and the #includes are no longer generated.

It appears that EA is using the 'default' reference character to parse out the object classifer when deciding to create #includes.... when set to & it will generate #includes for parameters that are references and none for parameters that use *.  ALSO, when forwarded engineered, EA does not put the reference character in the parameter of the generated code!!

I will modify the code generation template if necessary...but I do not think that that part of the template is 'exposed', at least, in my ignorance, I  have not been able to find it.

Any pointers?  (pardon the pun)

3

Automation Interface, Add-Ins and Tools / Re: C++ #include behaviors

« on: December 10, 2007, 12:17:54 pm »

Hmmm.
We had a look at the classifiers, and nothing is jumping out at us. Still not successful.  We have experimented further with the use of pointers to classes in general.

In one class definition, we added a forward class declaration of:


class AbstractComponentState;

namespace subsystemCommon
{
class SubsystemComponentStatePool
{
public:
SubsystemComponentStatePool();
virtual ~SubsystemComponentStatePool();
void setState (AbstractComponentState *state);
      };
}

We reversed this code back to our model, and the
forward declaration added a dependency connector in the
SubsystemComponentStatePool  class diagram to
AbstractComponentState ... which is good.  And, it compiles.
However, if SubsystemComponentStatePool  is Forwarded
again,  the forward declaration is removed ,and of course, the code no longer compiles.

In addition, if we manually add an unnamed directional dependency in our class diagram, it ALSO does not generate any kind of forward declaration.

Either the forward declaration, or, the addition of the include file when a pointer to a class is used as a parameter would be nice to have.

4

Automation Interface, Add-Ins and Tools / C++ #include behaviors

« on: December 07, 2007, 11:48:11 am »

Hi,
We are attempting to Forward Engineer the following:
namespace pkgA
{
classA:public otherBBpackage::classB
{

public:
 int methodA(otherXXClass *a);
 int methodB(otherYYClass &b);
};
}

where the parameters for methodA are defined as
a: otherXXClass [in]

and methodB parameter is
b: otherYYClass [inout]

The code generator generates

#include "otherBBPackage\classB.h"
#include "theXXpackagefoldername\otherXXClass.h"

but it does NOT generate
#include "theYYpackagefoldername\otherYYClass.h"

nor does it add
class otherYYClass;
before the class definition, or add
#include "theYYpackagefoldername\otherYYClass.h"
in the implementation cpp file.

What are we doing wrong here?  It seems that only [inout] parameter references stimulate the generation of an include file in the referencing class' definition.(or implementation)