Stereotyped ActivityParameter: customize the Direction and Type

[Guillaume]

Hi,

I've defined a stereotype for ActivityParameters within a custom MDG, to be created on Activities.
I'm trying to integrate custom rules for 2 of its properties available under the "Parameter" tab:
- Type is by default set to Integer. I'd like to change its default value to None
I found that Type is set in t_object.Classifier_guid either with the guid of the selected element, starting with INT for Integer, BOOL for boolean, or empty for NONE. Is there a way to change it in the MDG? This would prevent a custom script to run once elements have been created.

- The Direction is a drop down list with in, out, inout, return ; I'd like to change the colour using a Shapescript. This is stored in the t_xref table (CustomProperties->direction), yet a simple script shows that it's not considered as a tagged value. The only workaround is to add a new Direction tagged value, unless there's something to access this property via the ShapeScript?

Thanks

[qwerty]

Have you tried HasProperty?

q.

[Guillaume]

It worked, thanks.

Note: I used HasProperty('direction','in')

Guillaume

[Modesto Vega]

Interesting, this means that you need to use a ShapeScript to change the colour, it cannot be done using a legend because the direction property is not one of the ActionPin properties exposed by Sparx EA.

[Guillaume]

In this instance, yes Direction is not a tagged value so I cannot use the legend. Note that I'm using Activity Parameters here (not action pins).

[vrieg]

It worked, thanks.

Note: I used HasProperty('direction','in')

Guillaume

I am facing the same issue. Could you please give a hint how you solved this at your side?
Additn a property to the MDG does not  affect the configuration in Properties--> Parameters--> Direction


Did you manage to adjust the direction of the action pins as well? this would solve all our problems here...

[qwerty]

You have to evaluate the in/out and also a 2nd property to tell where the pin is attached saying top/bottom/left/right (again offline but it's somewhere in the help).

Then you have to write a lengthy if-clause to make render the triangle. Lots of copy/paste since you do not have any control structures in shapescript.

q.

[vrieg]

ok, thanks. then it seems to better write a python script to evaluate the direction after creation I suppose...

[qwerty]

Well, not really. If you move it around on the diagram I don't think you get notice of that (at least I remember no according event being triggered). Also, there is noting to help rendering from outside. That's all done inside EA's rendering code. If you want the arrows you are doomed to write the shape script for it. It's not *that* complicated. Only some "why has it to be this way?" when coding....

q.

[vrieg]

I am just struggling in setting the direction of an activity parameter with the shape script to e.g. inout or in general to execute commands of EA Object model that I would like to execute in a script. Is there any reference that could be taken as a base?

[Geert Bellekens]

I am just struggling in setting the direction of an activity parameter with the shape script to e.g. inout or in general to execute commands of EA Object model that I would like to execute in a script. Is there any reference that could be taken as a base?

You can't set things in a shapescript. You can only tell EA how to render an element on a diagram based on the available info.

If you are looking for documentation on how to change your object, see https://sparxsystems.com/enterprise_architect_user_guide/16.0/add-ins___scripting/reference.html

Geert

[qwerty]

You set the direction in the tagged values where you have a Direction with in/out as value. When that is changed you can query that in the shapescript and render the triangle as shortly sketched above.

q.

[vrieg]

I got direction and type of activityparameters working. thanks .
Indeed sql helped to understand the relations required tagged values and metaclasses.

However: Is there a way to copy the direction of activity parameters to the action pins when instantiating the actions using MDG.
I know that action pins and activity parameters are related via the classifier relation. Therefore I assumed this might be possible and help in reducing complexity of activity diagram modeling.