| Issues with moving elements between models [message #1693319] |
Thu, 23 April 2015 08:08  |
 Tomas Sandkvist
Messages: 149
Registered: October 2013 |
Senior Member |
|
|
I've did some tests with a new model structure today, and a a part of this I also tried to move a package containing a block and a diagram to another model. Working with Papyrus Luna SR2.
An example:
The block 'Part AA' is in the package I want to move (OtherLib), and the part 'Safety PLC' is from another imported library containing common parts shared between all models.
First, in model A, I imported the target package (OtherLibExternal) from model B. Then I moved the package (OtherLib)containing the block(s), associations and a diagram I wanted to move. Closed the diagram above and reopened it, and got this:
Also when opening OtherLibExternal, the diagram was lost.
Shouldn't this work?
And to make things weird, I made the import the other way (model A into B) around one time, didn't work, remade the import (model B into A), and all of a sudden it worked! But after closing the model, it was back to the failed state again.
Cleared up the diagram by either deleting or hiding the parts not possible to show, made sure there was no references or import elements for OtherLibExternal (which not is totally empty), but still OtherLibExternal pops up in the ModelExplorer each time i open model A. The only way I could get rid of OtherLibExternal was to delete its model files.
So, am I trying something not supposed to be possible here? Or are there flaws in the mechanisms for moving parts of a model to another model?
Regards,
Tomas
|
|
|
| Re: Issues with moving elements between models [message #1693320 is a reply to message #1693319] |
Thu, 23 April 2015 08:19  |
Camille Letavernier
Messages: 932
Registered: February 2011 |
Senior Member |
|
|
Hi Tomas,
Moving an element from one resource to another is a refactoring operation, which is not always properly handled by Papyrus. Unlike simple changes, refactoring operations may cause inconsistencies in related models if they are not consistently saved during this operation.
We did some work on the Control Mode operation (Which is also a similar refactoring) to ensure consistency, but we didn't generalize that to elements moved from one model to another.
The workaround (To avoid the issue) would be to force a change in the Diagrams, to ensure that they are consistently saved. Otherwise, diagrams will be considered unmodified and will not be saved, causing this inconsistency.
The second workaround (To repair the model) would be to use the Refactor > Switch Library operation, but this is probably too much in that case, because it would update *all* references to a model to references to another model. In this case, you only want to update some of them (the broken ones), so that's probably not an option
So that's definitely a bug in Papyrus, and I don't think it has been reported yet
Regards,
Camille
Camille Letavernier
|
|
|
|
|
| Re: Issues with moving elements between models [message #1693346 is a reply to message #1693336] |
Thu, 23 April 2015 12:15 |
|
Hi, Camille, Tomas,
Note also that a complete refactoring solution (which I think we need)
would also account for updating models that are open in other editors
and those that aren't open in any editor.
Something like a workspace wide-index of cross-resource references
would be useful in the implementation of such refactoring capability.
Neon, anyone? ;-)
Christian
On 2015-04-23 10:03:51 +0000, Camille Letavernier said:
> It is the resource (notation file) that needs to be saved, but it is
> unable to detect move operations as actual changes. This means that a
> single forced-change for each notation resource should be sufficient
>
> Camille
|
|
|
|
Powered by
FUDForum. Page generated in 0.01564 seconds
Search
Help
Register
Login
Home
Hopefully it will even be available in Mars or Mars SR