Shapescript vs Local diagram rendering

[Paolo F Cantoni]

I'm not sure that this is a bug so, before I report it, I'd appreciate any feedback.

There seems to be an inconsistency in the application of local diagram rendering versus Shapescript rendering.  I thought that Shapescripts provided the "default" rendering (for example - border/line color), but on an individual diagram basis, you could override that.

That no longer (if ever) seems to be the case.  The Shapescript takes precedence.  Can anyone "confirm or deny" which should take precedence?

Paolo

[qwerty]

I would, if you describe the steps a bit more clearly.

q.

[Eve]

If you set a specific colour in a shape script and then call drawnativeshape(), then the local diagram appearance can override your assigned colour.

However, if you set a specific colour and then do your own drawing it won't be overridden. You can set the colours explicitly to the user defined colour if some part of the shape needs to obey the user settings.

If you want an overridable colour, set the colour on the stereotype itself.

[Paolo F Cantoni]

Sorry everybody, I obviously didn't explain myself well enough (excuse: I was on the bus and my stop was coming up )

What I meant was:  We have decided to use colours to indicate whether something is being commissioned/decommissioned/unchanged etc.  The intent is that one a particular diagram (a Transition diagram), we set the line to the commissioned colour (to indicate that flow will be created in that transition).  However, because of other properties (tag values), the shape script has changed the colour from the default set in the MDG to another colour.

I guess we were expecting that the local colour would override the shapescript colour, but the shape script takes precedence and although the properties of the line (using the Appearance menu item) says the colour should be (say) Blue), the line remains stubbornly Grey (shapescript).

Should it be blue or grey?

Is that clearer?

Paolo

[Eve]

I think that description was more confusing.

As I said,

The colours set by a shape script are only overridable if you call drawnativeshape.

As an example:

Code: [Select]

shape main
{
if(hasTag("red","true"))
SetPenColor(255,0,0);

// Will be drawn with a red border unless
// user has overridden it on the diagram
drawnativeshape();

// Will be drawn with a red border
setfixedregion(-16,0,0,16);
ellipse(-16,0,0,16);

// Will be drawn with the colour defined by
// the user for the diagram or object
SetPenColor(GetUserBorderColor());
setfixedregion(-16,16,0,32);
ellipse(-16,16,0,32);

// Will draw the border in the user defined
// fill color
SetFillColor(255,255,255);
SetPenColor(GetUserFillColor());
setfixedregion(-16,32,0,48);
ellipse(-16,32,0,48);

// Will ignore the user defined border colours
// and draw using global colours (including
// element grouping colours if applied)
SetPenColor(GetDefaultFillColor());
setfixedregion(-16,48,0,64);
ellipse(-16,48,0,64);

// Filled with status colour if set to be used
// for this element type. Otherwise element fill
// colour. Doesn't apply to pen colour
SetFillColor(GetStatusColor());
SetPenColor(GetStatusColor());
setfixedregion(-16,64,0,80);
ellipse(-16,64,0,80);
}

[KP]

Long story short, I think your shape script needs to check the diagram type and only set the colour if it isn't a transition diagram.

[qwerty]

I think, the shape script always takes precedence. That's what I always observe (when people tell "why doesn't it appear like..."). The shape script has queries for the local setting and must use it. Or not.

q.

[Paolo F Cantoni]

Long story short, I think your shape script needs to check the diagram type and only set the colour if it isn't a transition diagram.

That was just an example.  The problem is an arbitrary diagram can have the default colour (say) overridden.

Paolo

[Paolo F Cantoni]

I think that description was more confusing.

As I said,

The colours set by a shape script are only overridable if you call drawnativeshape.

As an example:

Code: [Select]

shape main
{
if(hasTag("red","true"))
SetPenColor(255,0,0);

// Will be drawn with a red border unless
// user has overridden it on the diagram
drawnativeshape();

// Will be drawn with a red border
setfixedregion(-16,0,0,16);
ellipse(-16,0,0,16);

// Will be drawn with the colour defined by
// the user for the diagram or object
SetPenColor(GetUserBorderColor());
setfixedregion(-16,16,0,32);
ellipse(-16,16,0,32);

// Will draw the border in the user defined
// fill color
SetFillColor(255,255,255);
SetPenColor(GetUserFillColor());
setfixedregion(-16,32,0,48);
ellipse(-16,32,0,48);

// Will ignore the user defined border colours
// and draw using global colours (including
// element grouping colours if applied)
SetPenColor(GetDefaultFillColor());
setfixedregion(-16,48,0,64);
ellipse(-16,48,0,64);

// Filled with status colour if set to be used
// for this element type. Otherwise element fill
// colour. Doesn't apply to pen colour
SetFillColor(GetStatusColor());
SetPenColor(GetStatusColor());
setfixedregion(-16,64,0,80);
ellipse(-16,64,0,80);
}

Arcs don't have drawnativeshap do they?

In any case, therefore, even with vertices, you can't override the shapescript in the non-rectangular mode where you've NOT drawn the native shape.  (confirmed)

The issue was first detected in arcs, we confirmed the same issue exists in vertices.

qwerty has the "solution".

Paolo

[Paolo F Cantoni]

I think, the shape script always takes precedence. That's what I always observe (when people tell "why doesn't it appear like..."). The shape script has queries for the local setting and must use it. Or not.

q.

That's the conclusion we've come to. 

The problem is that to do exactly what we are trying to achieve, the shape script needs to know if the user has changed from the default.  Now while there are two queries:
getUserBorderColor()
getDefaultLineColor()
there is no mechanism to compare the results and therefore determine if the user has changed the default.

We're trialling a less than optimal solution to the problem.

Paolo

[qwerty]

You could hard code the default, I guess.

But then again, shape script lacks any kind of comparison :-(

q.

[Paolo F Cantoni]

You could hard code the default, I guess.

But then again, shape script lacks any kind of comparison :-(

q.

That's the essential problem - very rudimentary comparison.   The default needs to be specified in the MDG - declarative programming.

Paolo

[Eve]

The problem is that to do exactly what we are trying to achieve, the shape script needs to know if the user has changed from the default.  Now while there are two queries:
getUserBorderColor()
getDefaultLineColor()
there is no mechanism to compare the results and therefore determine if the user has changed the default.

We're trialling a less than optimal solution to the problem.

Paolo

You want to explicitly draw something different based on if the user has changed colour? I can't imagine a reason for that, care to explain?

[Paolo F Cantoni]

You want to explicitly draw something different based on if the user has changed colour? I can't imagine a reason for that, care to explain?

Actually, I want User Defined Diagram Properties for  Arcs.  That's already been asked for.

So I want to be able to say: "This flow is to be commissioned" or "This access is to be changed" etc.  If the arc is derived, we colour it grey - so it's not as prominent as a canonical arc.

Since we don't have the property, per diagram, I can't detect the user wanted to say that.  However, if the User explicitly colours the arc then I can respond to it (as though they had set the property).  But since I can't compare the User Colour with the Default Colour, I can't tell they've done that.

I would prefer that any user update to the rendering (on a local diagram) override the shapescript - but that's not how it works.

Paolo

[WarrenKenyon]

My company tries to do things with color as well, no matter how much I tell them not to.

Color of model elements in a diagram is nice, but has no semantic value. It's not "part of the model".  You should always use stereotypes or tagged values when giving different elements different "meanings".   If you want to give color to stereotypes or tagged values for a visual effect, than that's fine, but never use color alone.

Your shape script is drawing based on stereotype or property (ie, tagged value), just as it should.  Use a tagged value to color your elements.