Default value of tagged value not retrieved in c#

[utkarsh]

I have added a tagged value of type enumeration having values("New","Changed","None") and default value = "New". When I add a new element in EA; default value ("New") of the tagged value is correctly displayed in the textbox. But when I try to retrieve this value in my addin using c# the default value is not getting retrieved.
However if the user changes the default value in EA it is correctly retrieved in the code.
The code I am using for retrieving the tagged value of an element is:

(element.TaggedValues.GetByName("Change in Release") as TaggedValue).Value.

Am I doing something wrong or is it a bug in EA?
Please guide.
Thanks.

[Eve]

I haven't looked into this, but at least one other user is having the same problem.

See http://www.sparxsystems.com/cgi-bin/yabb/YaBB.cgi?num=1214403338

[utkarsh]

Default value of the tagged value of enumeration type is not retrieved using API. However it is correctly retrieved if we set default value of the tagged value by setting the “default value” attribute in stereotype definition.

This is a workaround but the original problem still exists.

Thanks.

[«Midnight»]

Please submit a bug report directly to Sparx on this, with an example project if you can.

Use the Registered Users page to find the link to the bug report page - it's very near the top of the page. That version of the bug report allows you to attach a file (I don't think the other one does).

This way the issue will get directly to the Sparx support people, who should be able to put things right. This sounds like something that could be easily rectified between builds, so the sooner you get the report in the sooner we'll see the correction.

Thanks,
David

[Eve]

Okay, let me say what I know about this issue without having actually looked at it.

Despite being displayed to a user, the default value of tagged values does not appear to automatically set when a tagged value is created.  (You can see this behavior showing the tagged values on a diagram too.)  It acts more as a default value to show when no existing value is set.

That makes this a specific case of having a different display value to the background value.  Another example of this would be the RefGUID tagged value type.  Displayed to the user as the element name (and stereotype) but stored as a guid.  This suggests that the API problem is actually that we need an extra (readonly) property for the display value.  This extra property would then need to be added to the various tagged value classes in the API.

This is all under my above disclaimer that I haven't actually looked at it.

[«Midnight»]

So far so good Simon,

But we still need to resolve the issue of the displayed value not matching the actual value. Regardless of whether this is UI, API or both something appears to be wrong.

I still think this is growing pains of some kind. With luck it should be an easy problem to address.

David