Indeed, after modifying and updating the original sketch, the relationship added to completely define the derived sketch is cleared and we find ourselves again with the initial problem.
With your solution it's the same: if the derived sketch moves, the projected elements will also move!
In the end, the only viable solution is to use the blocking bar.
Hello Silver-S
Yes, it poses a problem to re-rate. Then here is the Taff doing the job twice.
On the other hand, the projection solution is good. If you change a dimension, the entities follow. Unless you remove an element and replace it, but that's true with all design methods.
What you need to understand with this bug is that you don't have any information when you move an element, which you shouldn't normally do. In short, it's not reliable. The projection method uses the classic methods that you might have in an assembly with external references between two parts.
Another point for which I do not recommend this solution is the pack and Go or moving parts attached to a skeleton.
Pack and go, you have to repoint the skeleton of each piece, when you have two, it's not a problem. I'm working on a project where I have more than a hundred pieces and I've had the case. It's a crazy job because the software doesn't warn you that it has lost the link. And it's cumbersome, the updates take a lot of time.
The solution I propose is to integrate the skeleton as a part in an assembly and to integrate new empty parts, edit the parts and by external reference you do the same thing. Less skeleton to repoint, the software warns you when it has lost the link, or that you repoint it to another place after moving your folders for example.
We must integrate methods of this type when we have feedback. Or choose Inventor which has a more advanced management on this subject. Or have PDM that I advise as soon as you want to do collaboration and technical of this kind.
Bred that's just my opinion, others haven't listened to me on this subject, and they're no longer here to finish their work of m...
Hello FRED78,
I agree with you about the skeletons, on Solidworks I don't like it but in some cases it's better to have only one skeleton. Indeed on Inventor it's more sophisticated, I liked it for mechanically welded (Inventor).
=>Solidworks Skeletons=>https://www.youtube.com/watch?v=j-qViam3fkg&t=183
=>Inventor Skeletons=>https://www.youtube.com/watch?v=TIgz3Yg-zkY
That's just for the record.
@+.
AR.
Hello
I use it everywhere.
The final goal is to be able to make compositions for your drawings.
You have to think carefully about the compositions of your assemblies and sub-assemblies. If all your parts are built on this method, you can recompose assemblies without constraints (weight sheath, and errors). Ability to quantify working time and reliability.
Inventor on this subject is classy.
SolidWorks - I prefer to create an assembly and work as an external reference, even for a part it's surprising but it works without too much latency.
When you have rigorously applied this method to complex conceptions, afterwards you don't do without it.
The work on the skeleton seems to be long, heavy, but in the end the possibilities between the trades and other designers in collaboration are very effective when it is done well. And for collaboration with a PLM such as Vault, or PDM.
Several skeletons, why, how!
A skeleton on a simple structure with a few parts ok.
But when you have a thousand parts on different subsets of your mechanism, then having several skeletons makes sense.
1/ You have to design these skeletons by going down
2/ Broken down by subset or by profession but attached to common references.
3/ The updates only apply to the skeleton concerned, so to a minimum of parts. Opening is faster (when you apply a modification).
4/ easier when you only have about thirty sketches
And believe me, on large assemblies, the time saving is enormous, especially if your skeleton is internal to the parts and not to an assembly as I recommend on SW.
Once again, my opinion and my experience, and the current one, taught me very good things 
You have to test the different methods (See attachment)
02-methode.7z (678.1 KB)
Thank you very much for your examples.
@+.
AR.
Personally, I use the 2B method.
On the other hand, I understand your remark about unconstrained sketches. On your example it is the case but in my case the skeleton is always constrained. The (-) you can see on my model is only that there are axes of symmetry that don't have a defined length, this is useful for me to operate a sketch mirror so I often don't dimension the length. Nevertheless, the logic remains the same and it is rather stable, unlike the publication of a play in the context. Having practiced this technique for a while, I know that it always screws up after a while.
Hello Ronathan
Skeleton integrated into a room:
Possible for the axes I have not checked, I do not have time to devote to the problems inerrant to this method. But the fact is that when editing a function to be able to stretch the sketches without constraint or dimension, is a problem seems serious to me. That even an option would block this possibility seems to me to be a problem in itself. But I may not understand the logic.
We must be able to produce sketches driven by the dimensions on which we act. If these can be modified without insurance or control, this is not normal.
Beyond this problem, identifying latencies due to long updates, and sometimes even for no reason, requires resources that are not always easy to obtain with a PC lacking power and RAM, which is my case. But I'm not a computer scientist.
The shit after a while? Explains?