Community
Participate
Working Groups
Steps to reproduce. 1. Copy State from a composite state diagram 2. Open another Composite state diagram and edit->paste 3. Results in duplicate elements dropped. They both pointing to same semantic element.
Keep in mind that duplication occurs not only for states, but also for pseudo-states and transitions (in the case a multi-select and copy-paste of a transition and its source/target is made) as well.
What can be noted here is that we have an inconsistency in behavior regarding what is selected (or not) before the paste it performed. As noted in several other cases, e.g. also copy-paste of ports and capsule parts in a capsule structure diagram (see for example Bug 494401 and Bug 494407 Comment 10 and forward), the behavior of the paste operation is very different depending on if you have nothing selected, i.e. only the diagram in itself active, or if the frame of the state/state-machine is selected. It seems as the duplication only occurs if nothing is selected prior to pasting. If the state/state-machine frame is selected, then the duplication does not occur. This feels like a very general issue in Papyrus, which is extremely confusing for the user. In diagrams like the state-machine diagram and the capsule structure diagram, it should not really matter if nothing is selected vs. if the frame of the capsule/state/state-machine is selected, since the diagram only have one root element so semantically having nothing selected and selecting the root element is for the end-user the same thing.
Needs more investigation - need a release note in 0.9
Create Papyrus bug for this problem. If Papyrus will not fix, then move this bug to future.
(In reply to Peter Cigehn from comment #2) > What can be noted here is that we have an inconsistency in behavior > regarding what is selected (or not) before the paste it performed. As noted > in several other cases, e.g. also copy-paste of ports and capsule parts in a > capsule structure diagram (see for example Bug 494401 and Bug 494407 Comment > 10 and forward), the behavior of the paste operation is very different > depending on if you have nothing selected, i.e. only the diagram in itself > active, or if the frame of the state/state-machine is selected. It seems as > the duplication only occurs if nothing is selected prior to pasting. If the > state/state-machine frame is selected, then the duplication does not occur. > > This feels like a very general issue in Papyrus, which is extremely > confusing for the user. In diagrams like the state-machine diagram and the > capsule structure diagram, it should not really matter if nothing is > selected vs. if the frame of the capsule/state/state-machine is selected, > since the diagram only have one root element so semantically having nothing > selected and selecting the root element is for the end-user the same thing. There is a different behavior in Papyrus. The copy-paste only works if the region is selected and the copied state is very wide and cannot be resized. Also, a separate, new state is created in the target state machine, not linked to the source state. So neither behavior is correct. I believe we need to raise a separate bug on Papyrus and deal with this one once Papyrus fixes that one.
(In reply to Charles Rivet from comment #5) > (In reply to Peter Cigehn from comment #2) > > What can be noted here is that we have an inconsistency in behavior > > regarding what is selected (or not) before the paste it performed. As noted > > in several other cases, e.g. also copy-paste of ports and capsule parts in a > > capsule structure diagram (see for example Bug 494401 and Bug 494407 Comment > > 10 and forward), the behavior of the paste operation is very different > > depending on if you have nothing selected, i.e. only the diagram in itself > > active, or if the frame of the state/state-machine is selected. It seems as > > the duplication only occurs if nothing is selected prior to pasting. If the > > state/state-machine frame is selected, then the duplication does not occur. > > > > This feels like a very general issue in Papyrus, which is extremely > > confusing for the user. In diagrams like the state-machine diagram and the > > capsule structure diagram, it should not really matter if nothing is > > selected vs. if the frame of the capsule/state/state-machine is selected, > > since the diagram only have one root element so semantically having nothing > > selected and selecting the root element is for the end-user the same thing. > > There is a different behavior in Papyrus. The copy-paste only works if the > region is selected and the copied state is very wide and cannot be resized. > Also, a separate, new state is created in the target state machine, not > linked to the source state. > > So neither behavior is correct. > > I believe we need to raise a separate bug on Papyrus and deal with this one > once Papyrus fixes that one. Trying on Papyrus Oxygen, the behaviour is slightly different... The doubled element on paste did occur once, and there was stll only one element in the model explorer, with both graphical representations linked to the single semantic element. I could not caracterize a way to consistently reproduce this behaviour. However, the size of the copy still filled the complete width of the container state (or that of its region?).
(In reply to Charles Rivet from comment #6) > (In reply to Charles Rivet from comment #5) > > (In reply to Peter Cigehn from comment #2) > > > What can be noted here is that we have an inconsistency in behavior > > > regarding what is selected (or not) before the paste it performed. As noted > > > in several other cases, e.g. also copy-paste of ports and capsule parts in a > > > capsule structure diagram (see for example Bug 494401 and Bug 494407 Comment > > > 10 and forward), the behavior of the paste operation is very different > > > depending on if you have nothing selected, i.e. only the diagram in itself > > > active, or if the frame of the state/state-machine is selected. It seems as > > > the duplication only occurs if nothing is selected prior to pasting. If the > > > state/state-machine frame is selected, then the duplication does not occur. > > > > > > This feels like a very general issue in Papyrus, which is extremely > > > confusing for the user. In diagrams like the state-machine diagram and the > > > capsule structure diagram, it should not really matter if nothing is > > > selected vs. if the frame of the capsule/state/state-machine is selected, > > > since the diagram only have one root element so semantically having nothing > > > selected and selecting the root element is for the end-user the same thing. > > > > There is a different behavior in Papyrus. The copy-paste only works if the > > region is selected and the copied state is very wide and cannot be resized. > > Also, a separate, new state is created in the target state machine, not > > linked to the source state. > > > > So neither behavior is correct. > > > > I believe we need to raise a separate bug on Papyrus and deal with this one > > once Papyrus fixes that one. > > Trying on Papyrus Oxygen, the behaviour is slightly different... > > The doubled element on paste did occur once, and there was stll only one > element in the model explorer, with both graphical representations linked to > the single semantic element. I could not caracterize a way to consistently > reproduce this behaviour. > > However, the size of the copy still filled the complete width of the > container state (or that of its region?). Further information with regards to the double graphical element for the copied state: definitely related to the canonical/synchronization: setting synchronization caused the doulbe to be displayed.
Verified that this problem (duplicate edit parts) no longer exists in nightly build 912. However a problems still exists in that Copy and paste between state machine diagrams is possible, but only for a single state, and the copied state is placed outside of the statemachine visible area. Selecting multiple elements does not work on diagrams but appears to work from the model explorer. Actions: 1) Documenting in release note 2) Create new bug for future to address the new behaviour seen in the Oxygen release 3) Close this but as resolved fixed with a "see also" to the new bug from (2).
Release note created for v1.0 New bug 519854 created to address the new behaviour seen in the Oxygen release in a subsequent release Moving to
Moving to verified fixed
Closing as this particular problem is fixed - use bug 519854 for further issues.
