Arc Shapescripts - Rendering Order

[Paolo F Cantoni]

As a further example of how this current order is questionable, I tried to move a glyph from the main line to one of the end-shapes.  Why? Because http://sparxsystems.com/forums/smf/index.php/topic,30134.msg220298.html#msg220298  tells us that the measurements ONLY apply to the centre section - which can be problematic.  For example, I have arcs where the centre section is overwriting the target shape - while the bulk of the line is empty!
So, I decide where I want to place the shape and all appears fine for direct lines, but other types of lines have problems, BECAUSE the shape is drawn BEFORE the line which may be drawn somewhere else! I have these "orphan" shapes over my diagram.

EAUI...

Paolo

For example:

Code: [Select]

shape source
{
setlinestyle("SOLID");
setfixedregion(-5,-5,5,5);
setpencolor(255,0,0);
setfillcolor(255,255,255);
polygon(0,0,3,5,90);
setpencolor(0,0,0);
startpath();
moveto(0,-2);
lineto(0,2);
endpath();
fillandstrokepath();
}Change the value of "X" and watch the behaviour as you move the line around and rotate it.

[Eve]

I'm not entirely sure what you're trying to demonstrate here.

However, I did discover that version 10 of EA draws the end shapes after the lines, so the regression issue that I was afraid of causing is actually the problem you are reporting.

PS. SetFixedRegion inside a connector end should be unnecessary.

[Paolo F Cantoni]

I'm not entirely sure what you're trying to demonstrate here.

However, I did discover that version 10 of EA draws the end shapes after the lines, so the regression issue that I was afraid of causing is actually the problem you are reporting.

PS. SetFixedRegion inside a connector end should be unnecessary.

Thanks for that Aaron,
So, t's a real (regression) bug?  Do I need to report it or is that in hand?  As I've mentioned a couple of times, due to circumstances, I went straight from v9 to v11.x  (just before v12) and was at different assignments so I "skipped" the v9 to 10 transition.   But in any case, due to what I was doing (with EA) around that time, I doubt I would have picked up the regression problem.

Also, I did understand about the fixed region - but I've been cutting and pasting stuff around the place trying to get the shapescripts to do some funky stuff.  It doesn't hurt to leave it in does it?

As for what I was trying to demonstrate here, was that when we users (or a least I) set a value for the position on the line, we are expecting the position to be relative to the line as it is drawn...

So moveto(10,3) should mean, move along the line curve 10 units and then +3 units to Y axis.  Thus if the line is a bezier curve, you should follow the curve of the line.  If the line is an orthogonal or other type composed of straight line segments, then follow the line through any way-points.  No other algorithm makes sense (at least to me).

Hence why the main line should be drawn first then the end points....

Paolo

[Eve]

That's about position calculation, not rendering order.

Pretty sure the "algorithm" for calculating the angle of the script is return the angle between the end point and the next connector waypoint. In my opinion it's a reasonable approximation except if you're trying to draw a long way up a bezier. (And the math of trying to convert all shapes drawn into a bezier plane isn't worth it)

I would be surprised if the fixed region didn't cause the shape script to do some more "funky" things. At a minimum, it makes coordinate calculation much more complicated than it needs to be.

[Paolo F Cantoni]

Thanks for the clarification, Simon,

The Bezier was a tough call, but to define the concept, I thought it was necessary.

Accept the point about the fixed region.

Paolo

[Paolo F Cantoni]

After using this product for over a decade, I've just noticed that shapescripts for arcs draw the elements in a (to me) non-intuitive way.  It appears EA will draw shapes source and target (not clear which order) and THEN shape main.

This makes it REALLY difficult to suppress the main line at either end so that it is not visible if you wish to create an end shape that doesn't include the line.  For example, draw a circle as either source or target and you'll see what I mean. 

Because of the order of rendering, even a fill command won't do it.

It seems to me that if the order were shape main THEN shapes source and target, we'd end up with a more flexible shape script mechanism.

I think this could be done without affecting any existing shapescripts.

What do others think?

Paolo

Guess what!  An Association seems to draw the source and target (not clear which order) and THEN shape main as above;  BUT change the type to an Aggregation  and it will draw the SAME SHAPESCRIPT as shape main then source and target as I requested. (as of 1229)

NOTE: If - behind the scenes -  it doesn't actually do that, the rendered output looks like it does!  The pesky line will disappear behind the shape!

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

Any chance of a change to consistency, now?

Paolo