v15 – Can’t show direction indicator for Association in MDG?

[Paolo F Cantoni]

With an unstereotyped Association, one can set the direction indicator on the (middle top) text label.  If we use a stereotyped Association from our MDG, the option isn't there.  If we set the stereotype to one from the <Null> technology (for example the subscribe stereotype) the direction indicator functionality is restored.  The setting survives setting and unsetting the stereotype to our MDG and back to none or subscribe.  What are we missing?  I'm sure we could do it in previous versions.

Can you do it for your MDG?

TIA (and reported),
Paolo

[Eve]

At a guess, you have shape scripted the name label. It's that label that draws the indicator.

[Paolo F Cantoni]

At a guess, you have shape scripted the name label. It's that label that draws the indicator.

Yes, that's my guess too, but can I do anything about it?

Are you saying I can't use:

Code: [Select]

shape middletoplabel //v1.0 16-Feb-2016
{ //overwrite label with name only
print("#name#");
}
(Since we only want to see the name and not the other stuff that may also appear in the middletoplabel)

Paolo

[Eve]

The fact that you've overwritten the label may be valuable information when you're reporting that the label is behaving differently for your stereotype...

The only way to do it with a shape scripted connector would be if there were fields that you can query to get the direction. Then you could draw it yourself. I don't know if there are.

Have you seen something other than the name show in that label for associations?

[Paolo F Cantoni]

The fact that you've overwritten the label may be valuable information when you're reporting that the label is behaving differently for your stereotype...

Are you agreeing that even though we've changed the content of the label, it should still allow the direction indicator?  I would have thought yes since they seem to be disjoint concepts.

The only way to do it with a shape scripted connector would be if there were fields that you can query to get the direction. Then you could draw it yourself. I don't know if there are.

I don't think so...  Least, not that I could see.

Have you seen something other than the name shown in that label for associations?

Yes - IIRC, but a long time ago.  As I recall, there used to be other properties appended to the name, but that may have changed over time. Some of these scripts are nearly a decade old.  We just standardised on script components - made life so much more consistent.

I'll report a defect.

Paolo

[Eve]

Are you agreeing that even though we've changed the content of the label, it should still allow the direction indicator?  I would have thought yes since they seem to be disjoint concepts.

No. You've changed the graphical representation of the label to do exactly what you wanted.

(Since we only want to see the name and not the other stuff that may also appear in the middletoplabel)

(Your emphasis)

[Paolo F Cantoni]

Are you agreeing that even though we've changed the content of the label, it should still allow the direction indicator?  I would have thought yes since they seem to be disjoint concepts.

No. You've changed the graphical representation of the label to do exactly what you wanted.

(Since we only want to see the name and not the other stuff that may also appear in the middletoplabel)

(Your emphasis)

No, I thought (and it was certainly my intent) I had changed the content of the label only. As I pointed out to support, NONE of the other functionalities (colour, thickness, etc.) changed.

Everything else about the label, I expected to remain the same.  So "all label functionalities are equal, but some are more equal than others". 

Paolo

[Eve]

You defined a shape to override the default shape of that label. In most cases that shape consists only of text, you're now complaining because the shape that you defined doesn't include drawing from the overridden shape.

Colour, thickness, etc. are properties that can be defined for a shape. Do you want a shape scripted class to fully draw when you apply a shape script to it?

[KP]

In summary...

Reading direction is a property of the label not the connector. So if the shape script is going to take over the drawing of the label then it should also take control of displaying the direction indicator. However the shape script will need two extra pieces of information to do that: direction ("To Source"|"To Destination"|"") and orientation ("up"|"down"|"left"|"right"|""). Feature request?

[Paolo F Cantoni]

In summary...

Reading direction is a property of the label, not the connector. So if the shape script is going to take over the drawing of the label then it should also take control of displaying the direction indicator. However the shape script will need two extra pieces of information to do that: direction ("To Source"|"To Destination"|"") and orientation ("up"|"down"|"left"|"right"|""). Feature request?

Yes, agreed that Reading Direction is a property of the shape.  Colour, thickness etc are NOT?  For the UI perspective, the shape direction indicator sure looks like a property.

I agree that having taken control, I should be able to set properties directly.  As you say, some property methods are missing; that's a bug, .  Further, where I haven't set the property, it's still available for me to set via the UI except for Direction, that's another bug, .

It's "Label Farm", the novel.  If you REALLY insist, I will put in a formal feature request, but to me, it's what's technically known as an "Aw Sh*t moment" - "We only did part of the job". 

I suspect that to us users, a feature request is - "here's something that Sparx could reasonably not have thought about before".  It's not - "It should have been obvious that when you allow the user access to some functionality, you should allow access to "the functionality, the whole functionality and nothing but the functionality".

Paolo