Community
Participate
Working Groups
Created attachment 267306 [details] Screen shot showing a resized state frame in the subclass If you resize the state(-machine) frame in the superclass, does not cause the subclass to fully follow along, even if it follows the superclass view. It seem to be some issue with the contained "region" (I have heard something about "zones" as well), which still has it's original issue. This in its turn causes issues with scroll-bars and elements that can get "lost" due to that they do not fit in the "region". The actual frame itself seem to follow along. In the attached screen shot it can be seen that the "region" contained in the frame has not followed along and been resize to the same size as the frame itself. This can cause additional issues with scroll-bars (for example as discussed in Bug 507449).
New Gerrit change created: https://git.eclipse.org/r/95325
Gerrit change https://git.eclipse.org/r/95325 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus-rt/org.eclipse.papyrus-rt.git/commit/?id=fb9efb8fab246468d6c2e3df6f73b9f220028a56
(In reply to Eclipse Genie from comment #2) > Gerrit change https://git.eclipse.org/r/95325 was merged to [master]. There remain a couple of problems in the nested diagrams for composite states that is unrelated, or at least orthogonal, to this issue of following the superclass layout. These should be tracked as separate bugs, probably in Papyrus. 1) For some reason, when redoing a change in the size of the diagram frame that was undone, the "zone" machinery in the base Papyrus edit-parts adds to the width of the RegionEditPart the difference between its previous width and its new width, even if the change that was undone (and then redone) was a shrinking of that width. 2) In the nested diagram for a state only, it seems that the name label causes the first reduction of the width of a RegionEditPart to be countermanded by the name label wanting to maintain the original width. But then subsequent resize gestures of the diagram frame modify the region bounds as expected.
Verified to be fixed in the latest Papyrus-RT build (#574). The state(-machine) frame now follow along in the subclass as expected. Regarding the remaining issues mentioned in Comment 3, do you write bugs for tracking those (I guess as pairs of one tracking bug on the Papyrus-RT side, and another one for Papyrus)? I don't have enough insight to be able to formulate those. Setting this one as verified fixed.
Closing as verified fixed.
(In reply to Peter Cigehn from comment #4) > > Regarding the remaining issues mentioned in Comment 3, do you write bugs for > tracking those (I guess as pairs of one tracking bug on the Papyrus-RT side, > and another one for Papyrus)? I don't have enough insight to be able to > formulate those. No problem. They are truly minor and bizarre details. I have raised bug 515538 and bug 515540 for these issues.
