You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When using TechDraw_DimensionRepair, after clicking "OK" to apply a repair, the repaired dimension is selected in the tree, but not in the drawing (it is no longer green to indicate that it is selected).
With greedy selection, and multiple dimensions to repair, I then click on another dimension to select it, click to repair, and select the correct references, click "OK", and the previous dimension is what was actually being modified and is then updated.
Even though nothing is showing as selected in the document (nothing is green), I still have to first click the background to deselect the dimension in the model tree, then click on the dimension to repair, in order to actually repair it.
For example, loading https://gitlab.com/mcdanlj/RotaryBroach/-/raw/main/RotaryBroachParts.FCStd?ref_type=heads&inline=false and repairing references on BodyBoreOpsPage, I can have (as here) have just repaired Dimension007, then select Dimension001 on the page, silently leaving both Dimension0001 and Dimension007 selected in the tree, and Dimension007 the one actually chosen to repair. If I don't notice that, then when I replace the references, the wrong dimension changes.
When finishing a repair, either de-selecting the repaired dimension in the tree or re-synchronizing the view in the page to the selections would avoid this problem. It would be better to de-select the repaired dimension in the tree because if TechDraw_DimensionRepair is required at all, it is probably required for multiple dimensions, therefore the workflow is probably repairing multiple dimensions in a row, and having to explicitly deselect is additional and unnecessary work.
<<With greedy selection, and multiple dimensions to repair, I then click on another dimension to select it, click to repair, and select the correct references, click "OK", and the previous dimension is what was actually being modified and is then updated.>>
On exit from DimRepair, the original selected dimension is still in the selection list (don't know why it isn't green yet) and greedy selection adds the second dimension to the end of the selection. When you start the 2nd repair task, it takes the first dimension in the selection as the subject.
I don't think clearing the selection on exit from DimRepair will cause any issues.
Is there an existing issue for this?
Problem description
When using TechDraw_DimensionRepair, after clicking "OK" to apply a repair, the repaired dimension is selected in the tree, but not in the drawing (it is no longer green to indicate that it is selected).
With greedy selection, and multiple dimensions to repair, I then click on another dimension to select it, click to repair, and select the correct references, click "OK", and the previous dimension is what was actually being modified and is then updated.
Even though nothing is showing as selected in the document (nothing is green), I still have to first click the background to deselect the dimension in the model tree, then click on the dimension to repair, in order to actually repair it.
For example, loading https://gitlab.com/mcdanlj/RotaryBroach/-/raw/main/RotaryBroachParts.FCStd?ref_type=heads&inline=false and repairing references on BodyBoreOpsPage, I can have (as here) have just repaired Dimension007, then select Dimension001 on the page, silently leaving both Dimension0001 and Dimension007 selected in the tree, and Dimension007 the one actually chosen to repair. If I don't notice that, then when I replace the references, the wrong dimension changes.
When finishing a repair, either de-selecting the repaired dimension in the tree or re-synchronizing the view in the page to the selections would avoid this problem. It would be better to de-select the repaired dimension in the tree because if TechDraw_DimensionRepair is required at all, it is probably required for multiple dimensions, therefore the workflow is probably repairing multiple dimensions in a row, and having to explicitly deselect is additional and unnecessary work.
Full version info
Subproject(s) affected?
None
Anything else?
No response
Code of Conduct
The text was updated successfully, but these errors were encountered: