"Objects" don't respond to bordercolor default setting

[Paolo F Cantoni]

If the MDG has metatypes that use the <Apply type="Object">, they don't respond to the bordercolor value in the stereotype definition.  Interestingly, you can't set the border color with the Default Appearance dialog [F4] either!  In the latter case, the option is NOT disabled, so it must be a bug...

Changing the <Apply type="Class">, the functionality is fine.

Reported,

Paolo

[Paolo F Cantoni]

Turns out it takes two different criteria to create this bug...  (Yes it's a bug since it ONLY (seems to) affects "objects")

In the Main shape you need to be using darwnativeshape();

and in the (I believe LAST) decoration you need to have se the pen color to something other than getuserbordercolor();

In an object, it seems to draw the native shape border colour AFTER it's drawn the last decoration.  Thus, it uses the current setting of pen colour; whereas in the other types we've used to date, it seems to draw the native shape border colour BEFORE it draws the decoration (since there is no interference).

Oh well, another piece of EAUI.

Paolo

[Eve]

Just had a look. It actually appears that Class is in the minority with its behavior.

The others that behave like that are:

• Component (UML 2 notation only)
• ExpansionNode
• ObjectNode ie. ends of object flow
• Pseudo States
• Synchronization points
• Others when drawn in rectangle notation.

The good news is that you can "fix" your stereotypes by adding a SetPenColor before your DrawNativeShape.

Code: [Select]

shape main
{
SetPenColor(GetUserBorderColor());
drawnativeshape();
}

[Paolo F Cantoni]

Thanks Simon,

I had my suspicions that Object wasn't the only culprit.  And, yes, we'd managed to figure out the work around (I don't consider it a fix) ourselves... 

But it seems to me that Class should be the definitive indicator of what can be done with shapes and that to deviate from that requires a very good conceptually valid reason.

Concistency, konsistency, consistensy! ^TM_{Uffe - after Paolo}

In this case it's better to be consistent with Class (if possible) than to cripple Class.

Paolo