Book a Demo

Author Topic: When is default NOT default?  (Read 3968 times)

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 8626
  • Karma: +259/-129
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
When is default NOT default?
« on: January 25, 2010, 07:15:48 pm »
I'm setting up an MDG technology for a client and we'd previously setup some stereotypes using the Settings|UML...|Stereotypes dialog.  We changed the Default Colours to our required values.

In the MDG Technology section of the Help file it says:
You can define the appearance of stereotyped elements and connectors as you create or edit the stereotypes, using the Override Appearance and Default Colors panels of the UML Types dialog. However, an easier way is to review your completed profile diagram and set the default appearance of the elements and connectors in place.
Now, I don't know about you, but, for me, the usual reading of the above bit of natural language is that the second use of the word default mirrors the first use.

Well, it turns out that isn't actually so...  When you follow the instructions, you do get the colours you set.  However, under the covers, EA does it by actually setting the colour values (in the same way as <Context Menu>|Appearance|Set Default [F4] in the element itself!  This means that if you change the rendering in the MDG, all existing elements retain their (now incorrect) rendering.  In our case, all the existing 600 elements which were previously correctly rendered by UML|Stereotypes, lost their rendering completely!

Before I send a (justifiably irritable) bug report (because I really need a fix for this).  Is there any way to create the same effect (specify the default colours once in the MDG technology - like the UML|Stereotypes dialog) so that all existing stereotyped elements get the appropriate rendering?

Thoughts?

Paolo
« Last Edit: January 25, 2010, 07:20:31 pm by PaoloFCantoni »
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

beginner

  • Guest
Re: When is default NOT default?
« Reply #1 on: January 25, 2010, 08:15:30 pm »
I would expect that Synch Stereotype would adjust these settings. I haven't tested that, but if it doesn't do so I would consider this a bug.

b.

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 8626
  • Karma: +259/-129
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: When is default NOT default?
« Reply #2 on: January 25, 2010, 09:00:32 pm »
Quote
I would expect that Synch Stereotype would adjust these settings. I haven't tested that, but if it doesn't do so I would consider this a bug.

b.
Thanks b.   But Synch Stereotype only synchronises Tagged Values and Constraints.

Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!

beginner

  • Guest
Re: When is default NOT default?
« Reply #3 on: January 26, 2010, 03:28:23 am »
I guessed so. But "Synch Stereotypes" does not read "Synch Tagged Values" as in some other context location (which exact position slipped my old brain). Actually the help talks about Tagged Values and Constraints. From my point of view this synch should also respect formats like color and shape script (which is in turn a hidden tagged value). You likely need to submit a feature request and SQL or Add-In a work-around :-(

b.

Paolo F Cantoni

  • EA Guru
  • *****
  • Posts: 8626
  • Karma: +259/-129
  • Inconsistently correct systems DON'T EXIST!
    • View Profile
Re: When is default NOT default?
« Reply #4 on: January 27, 2010, 01:58:49 pm »
Oh well,  since no one has shown how to do it using a specific EA technology to address this particular issue, I'll post my work around (which I'd tested when I posted the original topic entry).

I was hoping there would be a more direct solution - but as workarounds go it's quite acceptable.

The issue, though is still one of the inconsistency of the Help versus outcome.

I would have preferred a consistency of approach - since I can't really see much use for a Use Case that actually sets the item default appearance as described above.

The workaround is to create a simple shapescript along the lines of:
Code: [Select]
shape main{
      setfillcolor(<red>,<green>,<blue>);
      setpen(<red>,<green>,<blue>,<size>);
      drawnativeshape();
}

In principle, I don't even mind this being the official mechanism to achieve the end I was after.  Just amend the Help file to make the different Use Cases clearer.

Paolo
Inconsistently correct systems DON'T EXIST!
... Therefore, aim for consistency; in the expectation of achieving correctness....
-Semantica-
Helsinki Principle Rules!