CASES:
| I. | non-instance moved to non-instance |
| II. | instance moved to non-instance - moved within same parent or original parent is not multi-instanced |
| III. | instance moved to non-instance - original parent is also an instance -moved to a new parent – user option 1: break cut instance and move |
| IV. | instance moved to non-instance - original parent is also an instance -moved to a new parent – user option 2: move all instances |
| V. | non-instance moved to instance |
| VI. | instance moved to instance - moved within one of it's own instances or sub's instances |
| VII. | instance moved to instance - moved outside it's own instances and original parent is non-instance |
| VIII. | instance moved to instance - moved outside it's own instances and original parent is instance - moved within it's own highest instanced parent's tree - moved within it's own parent |
| IX. | instance moved to instance - moved outside it's own instances and original parent is instance - moved within it's own highest instanced parent's tree - moved within the higher tree structure |
EXAMPLES OF EACH CASE FOLLOW
The examples show basic cases with the minimum number of instances to have an effect, but the methods are the same regardless of how many instances are in the model.
In the document, the terms "instanced", "multi-instanced", and "linked" all refer to the same thing. Also note that the colors do not change automatically, but are forced here to show links. Parts that are the same color are linked.
Note that the term "highest parent instance" refers to the parent of an instance furthest up the tree that is still an instance, for example:
"Part3" is linked to "Part_2", "Part2" is linked to "Part_1", "Part7" is linked to "Part_6", "Root" is not linked (and in fact can never be linked). The highest instanced parent for "Part3", "Part2" and "Part7" is "Part7". The highest instanced parent for "Part_2", "Part_1" and "Part_6" is "Part_6".
I. Non-instance moved to non-instance
•This is the simplest case. There are no other instances of these parts in the model. Moving "Part2" before, after, or as a sub of "Part3" simply results in:
•No link-related changes are made.
II. Instance moved to non-instance - moved within same parent or original parent is not multi-instanced
•"Part_1" is an instance of "Part2", all other parts are not multi-instanced. Moving "Part_1" anywhere in the tree, except moving it as a sub of "Part2", does not require any link-related changes. "Part_1" remains linked to "Part2".
•within same parent:
•to a new parent when original parent is not instanced:
III. Instance moved to non-instance – original parent is also an instance -moved to a new parent – user option 1: break cut instance and move.
•"Part2" and "Part_1" are instances of each other, "Part3" and "Part_2" are thus also instances of each other. "Part4" is not multi-instanced. Moving "Part3" as a sub of "Part4" will elicit the following dialog box:
•Selecting Cancel leaves Part3 in its original position, and nothing happens.
•Selecting OK brings up the following dialog:
•Selecting Cancel:
•"Part2" links are broken so that "Part2" is no longer linked to "Part_1". However, "Part_2" remains linked to "Part3".
IV. Instance moved to non-instance - original parent is also an instance -moved to a new parent – user option 2: move all instances
•Selecting "OK" in the dialog from scenario III above results in:
where all previous links remain intact, i.e. "Part2" remains linked to "Part_1" and "Part3" remains linked to "Part_2".
V. Non-instance moved to instance
•This has the same startup model as III above: "Part2" and "Part_1" are instances of each other, "Part3" and "Part_2" are thus also instances of each other. "Part4" is not multi-instanced. Moving "Part4" as a sub of "Part3" will result in:
•Since "Part3" has other instances, changes must be made to make sure the other instances remain identical. Thus "Part_3" is added as a sub of "Part_2" and is linked to "Part4".
•Similarly, if "Part4" had been moved before or after "Part3", the related instances would be adjusted as such:
where "Part_3" is added as a sub of the corresponding new parent's instance and in the correct position in the sub list.
VI. Instance moved to instance - moved within one of it's own instances or sub's instances
•"Part_1" is an instance of "Part2" and thus "Part_2" and "Part3" are also instances of each other. Moving "Part_2" as a sub of "Part3" (an instance of itself) results in:
where all involved links are broken. (colors do not change automatically)
•Similarly, moving "Part_1" as a sub of "Part3" (an instance of one of it's subs), results in:
where all links are again broken.
•There exists one possibility for maintaining certain links after moving parts beneath their own instance trails. This can occur when "Part_1" is moved as a sub of "Part2":
•For now, all links are also broken for this case. However, for this scenario it is possible to only break the link between "Part2" and "Part_1" while maintaining the link between "Part3" and "Part_2".
VII. Instance moved to instance - moved outside it's own instances and original parent is non-instance
•"Part2" is linked to "Part_1" and "Part4" is linked to "Part_3". Moving "Part2" as a sub of "Part4" results in:
where "Part4" and "Part_3" remain linked and "Part_1", "Part2", and "Part_2" are linked.
•The order of the sub parts must also be maintained:
•The following parts are linked: ("Part2", "Part_1"), ("Part4", "Part_2"), ("Part3", "Part_3"), and ("Part5", "Part_4").
•Moving "Part2" after "Part3" but before "Part5" results in:
•All links remain active, but "Part_5" is added and linked to "Part_1" and "Part2".
VIII. Instance moved to instance - moved outside it's own instances and original parent is instance - moved within it's own highest instanced parent's tree - moved within it's own parent
•The links are as follows: (Part_1 is instanced from Part5) and (Part_2 is instanced from Part4, so Part_3 and Part_4 are linked to Part_1 and Part5) (Part6 is linked to Part_5)
•Moving "Part5" after "Part_1" in the sub list results in:
•All links remain active and "Part_3" is moved to coincide with the movement of "Part5". The use of indices is demonstrated here since just using linked parts would add confusion as to which part should be moved. In this case 2 of the 3 subs are linked ("Part5" & "Part_1"), but only 1 is being moved.
IX. Instance moved to instance - moved outside it's own instances and original parent is instance - moved within it's own highest instanced parent's tree - moved within the higher tree structure
•The links are as follows:
•Moving "Part5" as a sub of "Part6" (constituting a move within it's original instanced parents hierarchy) results in:
where the 1st sub of the parent instance ("Part_3") is moved 1 level down in it's tree and would be reordered to it's sub position if needed. The use of indices is again demonstrated here since just using linked parts would add confusion as to which part should be moved. In this case 2 of the 3 subs are linked, but only 1 is being moved. As Part5 is moved back, Part_3 follows.
X. Instance moved to instance - moved outside it's own instances and original parent is instance - moved to another part & outside it's own instances - break cut instance and move & adjust parent instances
•"Part4" and "Part_2" are linked as well as their respective subs. "Part7" and "Part_6" are also linked. Moving "Part6" as a sub of "Part7" results elicits the dialog:
•Pressing Cancel results in:
where the following parts are linked: ("Part_5", "Part6" , "Part_1") and ("Part7", "Part6").
XI. Instance moved to instance - moved outside it's own instances and original parent is instance - moved to another part & outside it's own instances - move all instances & adjust parent instances
•This scenario involves the same model situation as X above, except that pressing "OK" in the dialog box results in:
where the links are: ("Part4", "Part2"), ("Part7", "Part_6"), and ("Part6", "Part_5", "Part_1", "Part_3").