It would be nice to have a list of the first level dependencies on any selected object so that you can see which ones you need to delete
4 Likes
You can view a list of all of the objects created in the History. You can open the History by holding the Ctrl key while pressing H.
1 Like
There is no first level dependencies. The pattern is a tree… and you have to delete branches in backwards order. Dependencies may also be internal paths, anchor points and pattern pieces themselves.
2 Likes
@Olaru_Iustin If you have a GitHub account, would you make an issue asking for the feature to list all of the dependencies of a selected object?
Ok, let’s not do this, see @Douglas’ reply below 
1 Like
Actually I will correct myself… referring back to issue #27
“Since an object, e.g. a line, can depend on more than one object (like, a line on two points), the pattern graph is more complex than a tree. It’s a cycle-free directed graph.”
Not easily solved as currently coded. If it was - tools could use other tools in the future history. Right now the tool dependencies are based on a simple counter - where when a tool used by another tool, it’s reference counter is incremented. If a tool’s reference counter > 0 it can’t be deleted as it’s being used by another tool (or more). Tools have no way of knowing what other tools are using it. You have to solve the cycle-free directed graph.
To get a list of downstream dependent tools, we’d have to rewrite a whole new method of tracking dependencies. Like instead of just incrementing a counter, each tool would have a list of tool id’s it’s being used by… either directly or in a formula. 1) There’s your dependency list right there. 2) As long as the list is not empty, a tool can’t be deleted. Key words… “or in a formula” for there in always lies the rub. Oh… and the Line tool is likely to throw a wrench in the works as usual. 
3 Likes
Oh how many hours I wasted looking for dependency just to delete things. I learnt my lesson to make less dependency as possible
4 Likes
Yea this is definitely not ideal when you’re not familiar with cad software
2 Likes
What is special about the line tool if I may ask?
If the graph is non cyclical then the good thing is that it is impossible to have a loop through it which is a good start. So the problem at first would be a classic graph travelsal from wherever the starting point is. Go up the tree and you get the dependencies. Going down the tree gives the parents. I can see this also as a nice ffeature to have if for example you want to change a specific proportion, then it would be very usefull to have a highlight of what it depends on so you can see what paremeters or objects you can tweak.
This is offcourse a surfface assumption. I haven’t seen yet the code to know what are the current issues preventing this.
2 Likes
It’s not a VGObject like the rest of the tools.
3 Likes
2 Likes
Seamly is somewhat like Excel and code programming.
-
Excel: A3 = A1 + A2. You can’t update formulas of A1, A2 or their predecessors to use A3, else you’ll get a cyclical reference error. Excel doesn’t give you a list of dependencies, just the error message. Seamly: Same behavior.
-
Excel: A1 = A2 + A3. You can include A2 and A3 in A1’s formula before A2 & A3 have values. But you can’t include A1 in A2’s, A3’s, or their descendants’ formulas else you get the cyclical reference error. Seamly: Can’t create A1 with objects not yet created A2 and A3. And after A2 & A3 are created, you can’t go back to A1 and update its formula to include A2, A3, or any object created after A1.
-
Programming: you can’t reference a variable (or pattern object) before it is defined, and after it’s defined you can’t “scroll back up” in the program (or pattern) and reference it,
-
Seamly: In a draft block, you can reference any object from a previously created draft block. This is why I draft Front blocks separately from Back blocks, and draft sleeves, collars, and other pieces as separate blocks. This prevents overly complex dependencies. But there are many benefits to combining blocks, so this is a personal preference.
HTH
2 Likes
That’s the whole repository, I mean I haven’t yet seen the logic in the code and understand how it is rendered
1 Like
Right, I’m not sure what the term code programming is supposed to mean really.
From what I understand then, is that the pattern data isn’t actually all loaded into memory to be processed fast during work? Is it constantly read and written in the pattern file after each change a user makes? This would explain the blindness of not being able to query up or down the tree of objects for related dependencies.
1 Like
Yes, that is the explanation. If it didn’t work this way, we wouldn’t be able to use line lengths & angles or curve lengths or curve handle lengths & angles in the formulas. We’d only be able to use direct lengths and angles or measurements.
1 Like
Yes, that is how editable, referential, and responsive parametric tools work. When one object is defined by referencing another object then each update requires re-calculation and re-rendering.
1 Like
The pattern is loaded into memory as a QDomDocument, but that’s not the issue. If you want to be able to resolve all the formulas you would have to parse a pattern twice everytime it needs updating. It’s analogous to rendering video… you can do a 1 pass encoding or a 2 pass encoding to get better compression - BUT it takes twice as long.
Not always… but again… because of the formulas it’s NOT a tree. The tools are added in a tree like structure, but the formulas allow you to reach across branches. And to determine what dependencies any given tool has, you would have to parse every formula to extract the tools used by name, then accertain what tool id that correlates to.
4 Likes
Ooooo now I understand. Not a tree. But a generic graph … Fun problem
2 Likes