Label Rotation lost in shapescript

[Paolo F Cantoni]

If you have a relationship that displays labels, if there is no override in the shapescript (see below) then you will have the "Label Rotation>" menu item for the label.  However, if you use the label <label name> functionality, that menu item is no longer available.

Code: [Select]

label middlebottomlabel
{
print("");
}
/*
label middletoplabel
{
print("#Name#");
}
*/
shape source
{
}

shape target
{
}
Uncommenting the shape middletoplabel code above will indicate the problem.

We see no reason why there should be such a loss of functionality.

Reported,
Paolo

[Paolo F Cantoni]

I have received a response from Sparx indicating that label rotation is NOT supported for shape-scripted labels.  Their argument is that there may be any sort of code behind the shapescript label code and so it's too dangerous.

My counter-argument is that whatever the code, the end result is a text label value (or null - in which case no issue) which is what is being rotated.  I can't see any effective difference between a text label that has 1000 lines of code behind it to generate a value and a text label with no lines of code behind it generating a (the same?) value.

I've asked Sparx to respond with what kinds of code (behind) might inhibit the use of the rotation functionality, but so far no answer.

Thoughts?
Paolo

[Eve]

My counter-argument is that whatever the code, the end result is a text label value (or null - in which case no issue) which is what is being rotated.

Where did you get that from?

Code: [Select]

label middletoplabel
{
ellipse(50,50,100,100);
print("#Name#");
}

[Paolo F Cantoni]

My counter-argument is that whatever the code, the end result is a text label value (or null - in which case no issue) which is what is being rotated.

Where did you get that from?

Code: [Select]

label middletoplabel
{
ellipse(50,50,100,100);
print("#Name#");
}

My bad,  I obviously thought that a label section (as opposed to a shape section) produced only a label - otherwise you'd (or I would) have used shape middletoplabel!
Since you CAN use: shape middletoplabel and it works fine...

I recognised that shape middletoplabel is more complex (since it would produce a shape) and would therefore not be amenable to rotation.  I didn't realise that label middletoplabel is just a spurious difference.

So why add the extra keyword when it doesn't mean what it says.

Paolo

[Eve]

I can only hypothesize that the original author of the shape scripts had something else in mind for them.

[Paolo F Cantoni]

I can only hypothesize that the original author of the shape scripts had something else in mind for them.

But are you saying (even by implication) that label XXXX and shape XXXX will execute the SAME code?

Paolo

[Eve]

I know of one difference. The labels still have the resize behavior (automatically sizing to contained text) as base labels.

[Paolo F Cantoni]

I know of one difference. The labels still have the resize behavior (automatically sizing to contained text) as base labels.

Unclear what you mean here.

Are you saying that: label XXXX has resize but shape XXXX does not?  Or did you mean the base labels without a shapescript?

Paolo

[Eve]

If I use the exact script I previously gave you, resizing the label will result in it snapping back to the size of the text. That won't happen if you put the exact same thing in a shape main.

[Paolo F Cantoni]

If I use the exact script I previously gave you, resizing the label will result in it snapping back to the size of the text. That won't happen if you put the exact same thing in a shape main.

Thanks...

Paolo