!!!!!Please withdraw relocation of elements when dragged and dropped from one di

[PeterHeintz]

I realized that now, when you drag and drop an element from one diagram to another, the element is relocated under the assumptions that the element should have the same place as if it was created on the diagram.
However, if you want to show the element on several diagrams by creating the drag and drop link, this new (at least for me bad feature) causes the element to jump around within the repository each time you put it to an additional diagram.

[Geert Bellekens]

How do you do that exactly?
 
I just tried dragging some elements from the project browser to a diagram, and I don't see any relocation of the element happening.

Geert

[OpenIT Solutions]

Hi,

Swimlanes. I think it happens if you drag and drop "onto an element" on a diagram, such as a swimlane. The element is then added as a child of the swimlane - and by definition, move into the same package as the swimlane. At least this is where I've seen the behaviour.

[Geert Bellekens]

Hi,

Swimlanes. I think it happens if you drag and drop "onto an element" on a diagram, such as a swimlane. The element is then added as a child of the swimlane - and by definition, move into the same package as the swimlane. At least this is where I've seen the behaviour.

That behavior I know and understand. But not just any element on any diagram.

Geert

[qwerty]

Hi,

Swimlanes. I think it happens if you drag and drop "onto an element" on a diagram, such as a swimlane. The element is then added as a child of the swimlane - and by definition, move into the same package as the swimlane. At least this is where I've seen the behaviour.

I guess you mean pools/lanes. Swimlanes are just graphics on a diagram.

q.

[PeterHeintz]

No, what I mean has nothing to do with pools/lanes/swim lanes!

When you add an element from the toolbox to a diagram, it gets typically located under the parent of the diagram. This is a solution which fits to most cases I have.

If you add an element to any diagram from the project browser in the very most cases it remains on its project browser location. This is a solution which fits to most cases I have as well.

Before current version(s!), when you dragged and drop an element from on diagram to another and selecting “Create Link on this Diagram”, the element typically remained on its original location. What was good!

Now in current version(s!) when you dragged and drop an element from on diagram to another and selecting “Create Link on this Diagram” several types of elements are relocated to the parent of the dropped diagram.

I have several scenarios where this is bad.

Exapmle: In activity diagrams I frequently use a send signal action in one activity diagram and several accept event actions in other diagram.
To get a glue where a signal comes from what is “accepted “, I connect the send/accept actions with trace links and to visualize that link, I drag and drop the send action to the activity diagram having the accept event action.
Before V14 I put the send signal action outside of the activity diagram boarder frame, to clearly mark that it is a kind of visual reference and does not belong the activity. Unfortunately since V14 it is not allowed to have thing outside of the diagram frame anymore.

Anyhow, now when I drag e.g. an action from the project browser to an activity diagram it remains on its browser location and if I do a “Create Link on this Diagram” it jump.
For some (not all) other element types I saw the same. Why on earth, an element what is in !!!addition!!! shown on the second diagram has to move its location anyway? And why only when I fetch the element from a diagram rather than from the project browser?

This behaviour is quiet illogical and annoying.

[Geert Bellekens]

You are not supposed to re-use actions on different Activity Diagrams (owned by different Activities), so I guess that is why this happens.


Geert

[PeterHeintz]

Hi Geert,
you are right, Sparx seem to think somehow in this direction!

However, even if so, with my diagram drag/drop procedure the action is still on many diagrams, owned by different activities. So the implementation is a bug anyway.

From my interpretation of the standard, I would say:
1) An action should be owned only by one activity
2) No action should have a kind of flow to other activity nodes not owned by its own owner
3) An action can have dependency links to actions not owned by its owner
4) !!!And!!! An action can be shown on an activity diagram or any other kind of diagram not owned by its owner

###################
The last one I derive from this part of the standard:
„NOTE. This taxonomy provides a logical organization for the various major kinds of diagrams. However, it does not
preclude mixing different kinds of diagram types, as one might do when one combines structural and behavioral
elements (e.g., showing a state machine nested inside an internal structure). Consequently, the boundaries between the
various kinds of diagram types are not strictly enforced.“
####################
Or see here:
https://www.uml-diagrams.org/uml-25-diagrams.html

I have the feeling that Sparx tries to be more UML compliant, what is in principle not a bad thing, but they overshoot somehow.
With the new Sparx implementation it is really hard and might get impossible in future to visualize cross-cutting relationships, and this would be very bad.

[PeterHeintz]

It seems that this strange behaviour has gone in build 1520!!!!
Thank you so much!!!!!