Does this mean move the TechDraw Page to a separate FreeCAD file .FCstd?realthunder wrote: ↑Thu Aug 22, 2019 11:01 am... The recompute touch problem you've experienced is caused by two bugs in Datum and TechDraw objects which I've fixed also. ...
There is one suggestion. The current TechDraw workbench seems to have many problems, causing slow down in document loading and recomputing. I'll propose some fix later when I have time. But even with the fix, I would suggest you to move the drawing out of the assembly. ...
What? Why would somebody put a TechDraw Page inside a Part container? I assume a Std Part (App::Part)? This seems completely counter-intuitive, as a drawing isn't a physical part, it's just additional data that depends on the other physical objects.realthunder wrote: When you put the drawing inside a part container, everytime the part is updated (e.g. moved), it has too recompute all its children first, including the drawings. TechDraw update takes time, lots of time if comparing to mere placement updates in links and parts.
I assume the intention was to keep the physical object together with its drawing. Would a Std Group not work better for this?
@user1234, why do you put a TechDraw Page inside a Std Part?
user1234 wrote: Ping
So I guess this means that with App::Link now part of FreeCAD we will achieve something that has been requested before: one .FCstd will hold the geometrical bodies, or assemblies, and a separate .FCstd will hold their corresponding TechDraw drawings. The second file can even have its own extension, .FCdrw for example. This is how it's done in Catia and other commercial systems; there is a file for simple parts, one for assemblies, and one for drawings, and others for different uses.realthunder wrote: It would be better if you put drawing in its own document, and use link to bring in any necessary parts. This way, when you modify your main assembly, and hit that recompute button, the drawing document won't get updated, because the assembly does not depend on the drawings. It is the other way round, and it should be.
Also see the realthunder's commit in pull request #2449 to address this issue. He again mentions the problem of unnecessarily touching the children of the TechDraw View.