v15.2 - Synchroize Stereotypes - does it fix up the GUID prefixes?

[Paolo F Cantoni]

As mentioned elsewhere, we're successfully using Synchronize Stereotypes on vertices.  We have observed that under some circumstances, it seems the process rectifies the prefix part of the GUID on the relevant t_objectproperties entries.  For example, if we had previously a set of them created as non-MDG based properties, they would have GUIDs that did not have the common MDG-prefix.  After we had converted the tags into MDG properties and executed the "Synchronize Stereotypes" process, the GUIDs now "line up" correctly.

• Has anybody else noticed this phenomenon
• If so, is it part of the process?

TIA,
Paolo

[qwerty]

You mean EA will make exiting Tagged Values be swallowed by profiles claiming a stereotype property of the same name? That would be EAish in a way since one would expect a message to warn about overriding some property (like when you copy files to where others with the same name already exist). Otherwise I have not looked into that since our synch usually only is intended to add new properties. Also in most cases I synch with a script that can do a more detailed handling.

Alas, I'd like to hear a Sparx response as well.

q.

[qwerty]

I just ran a test and yes: EA highjacks existing tagged values to become stereotype properties.

q.

[Geert Bellekens]

I've had very random experiences with this.
Sometimes it works fine, sometimes it doesn't.

We did a big migration from Magicdraw a few years ago, and in v12 all seemed to have imported just right.
Only in v15 we noticed that only some of the stereotypes were correct (fully qualified, referring to an MDG), and other weren't

Fixing that all up was quite a challenge. I think there are still a few objects out there that don't want to show there MDG properties

Geert

[Paolo F Cantoni]

You mean EA will make exiting Tagged Values be swallowed by profiles claiming a stereotype property of the same name? That would be EAish in a way since one would expect a message to warn about overriding some property (like when you copy files to where others with the same name already exist). Otherwise, I have not looked into that since our synch usually only is intended to add new properties. Also in most cases, I synch with a script that can do more detailed handling.

Alas, I'd like to hear a Sparx response as well.

q.

I don't think it's quite that simple.  Certain conditions appear to have to be met.  But it does happen.  I'm happy enough with the concept, but I'd like more detail from Sparx as to the process and conditions.

Paolo

[Paolo F Cantoni]

I don't think it's quite that simple.  Certain conditions appear to have to be met.  But it does happen.  I'm happy enough with the concept, but I'd like more detail from Sparx as to the process and conditions.

Paolo

Please?

Paolo

[Eve]

I'm happy enough with the concept, but I'd like more detail from Sparx as to the process and conditions.

Please?

Magic, when we want to, if the tag isn't from another stereotype.

[qwerty]

What happens when it's from another stereotype? Will it create a "duplicate tagged value"?

q.