Sparx Systems Forum
Enterprise Architect => Bugs and Issues => Topic started by: Geert Bellekens on April 22, 2020, 06:33:14 pm
-
In some cases the tagged values of an element are not visible in the docked window and can only be seen in the popup dialog.
This seems to happen when the assigned stereotype is not fully qualified.
Example: element stereotype set to «model document», not EAUML::model document
The tagged values corresponding to the EAUML::model document are not shown in either the properties or the tags section of the docked properties window.
I can understand that the new method requires a fully qualified stereotype before showing tags in the properties section, but if tagged values are present they should be shown in in the properties section (fully qualified stereotype), or in the tags section (not fully qualified)
Reported
Geert
-
Are the tags actually present? A stereotype from the global list can't define any tagged values.
-
Are the tags actually present? A stereotype from the global list can't define any tagged values.
Yes the tagged values are there, I can see them in the popup dialog. (and in the database)
I just can't see them in the docked window.
Geert
-
What I suspect is happening is that the tagged values are being identified as belonging to that stereotype, but because it isn't applied there is nowhere to display them.
It's likely that you're in that situation because older versions of EA weren't as strict about it.
The easiest solution is to remove the bad stereotype and apply the EAUML stereotype.
Just to be clear, I'm not saying that the current behavior is correct (in either place.)
-
What I suspect is happening is that the tagged values are being identified as belonging to that stereotype, but because it isn't applied there is nowhere to display them.
It's likely that you're in that situation because older versions of EA weren't as strict about it.
The easiest solution is to remove the bad stereotype and apply the EAUML stereotype.
Just to be clear, I'm not saying that the current behavior is correct (in either place.)
I tried that, but if I do that EA creates new tagged values, instead of assuming the existing tagged values belong to the (now fully qualified) stereotype and I have no way of accessing the (already filled in) old tagged values.
What worked was replacing updating the t_xref.description with the fully qualified version.
Then EA was able to show the tagged values in the properties section.
I don't have a problem with the more strict handling of stereotypes (I even applaud it) but I think all tagged values should always be visible, and the behavior should be consistent between docked properties window and popup dialog.
Geert
-
What I suspect is happening is that the tagged values are being identified as belonging to that stereotype, but because it isn't applied there is nowhere to display them.
It's likely that you're in that situation because older versions of EA weren't as strict about it.
The easiest solution is to remove the bad stereotype and apply the EAUML stereotype.
Just to be clear, I'm not saying that the current behavior is correct (in either place.)
I tried that, but if I do that EA creates new tagged values, instead of assuming the existing tagged values belong to the (now fully qualified) stereotype and I have no way of accessing the (already filled in) old tagged values.
What worked was replacing updating the t_xref.description with the fully qualified version.
Then EA was able to show the tagged values in the properties section.
I don't have a problem with the more strict handling of stereotypes (I even applaud it) but I think all tagged values should always be visible, and the behavior should be consistent between docked properties window and popup dialog.
Geert
Yes, we found similar in our experiments.
I refer again to Best practices for Tag/Property in profiles? (https://www.sparxsystems.com/forums/smf/index.php/topic,44274.msg260979.html#msg260979)
I think as we bring forward legacy repositories, we have to be prepared for some work. What frustrates me is that the targets are, often, self inconsistent - as shown in my thread above.
Paolo