I know that this request has been made many times before.
The solutions presented so far only work if there is no curve. While it is possible to adopt the angles from the original curve, unfortunately it is not possible to adopt the handle length.
As far as I understand, the problem lies in how the points are designated. Could the copied points not be clearly defined by adding the corresponding block?
For example
Copy to block B: A1; A2; Spl_A1_A2, which then results in A1_B; A2_B; Spl_A1_A2???
The advantage would be that the layers would lie precisely on top of each other, making it possible to clearly work-out the cut pieces, such as the pockets. This would enable you to save several pocket options and select them by showing or hiding the draft block.
If it is not possible to copy to a new draft block, it would be very convenient to be able to define the starting point in relation to an existing point. For example, the x and y coordinates of starting point B are identical to those of A34. This means that the blocks fit perfectly on top of each other, eliminating the need for cumbersome auxiliary constructions.
CP length and angles are formulas. And just like any other tool formula, once all the point names have been renamed - all the fomulas have to be parsed and updated to reflect new references.
Don’t need to rename the spline, as splines, arcs, and lines are named by reference. Once you rename the points, the spline(s) will rename themselves.
Do you mean “pattern pieces” ? Draft blocks are always shown where only 1 block is active at any given time.
I assume you mean to “anchor” the B block to point A34, so that if A34 moves, so does the B Block? Easier said than done. Currently the app does not provide access to point data across blocks. For ex… here the B block can not see the points in the A block:
It is possible to access the length and angle from another block. Am I correct in understanding that it is not possible to link the coordinates to another point?
Block B does not contain point A1, so it can’t reference it. Trying to do so will throw an exception such as above. In fact that’s what I did to cause the above error… I changed the basepoint of B1 from B to A1 in my editor.
@Douglas , is there a way that one can see (or copy) the x,y location of point A56 on Block A so that I can place the base point B on Block B at the same x, y location?
Well you could hover the mouse over the A56 point and get the x:y positions from the status bar.
The issues though are 1) Accuracy. 2) The basepoint B is NOT anchored to the A56 point… which means if A56 moves - such as a change in measurements - basepoint B is no longer located at A56. Which is the whole idea behind @MG2024 's question.
Problem is the app only works with the history on a block by block basis… so in this case Block B knows nothing about Block A. In otherwords… we can’t just create a dropdown list of points - including from the A block - to anchor B to.
I’m not super sure that I’m understanding what you’re saying, but I’m not seeing how the existing Groups don’t fulfill this function. It feels like you’re trying to come up with a more complex method of reproducing an existing feature.
Possibly because I feel like B_A34 is possibly worse than A134
I assume that this fits your description of “cumbersome auxiliary constructions.”:
