TechDraw_DimensionRepair requires identical re-selection to repair, results in incorrect dimension type

[johnsonm]

Is there an existing issue for this?

• I have searched the existing issues

Problem description

I have a file https://gitlab.com/mcdanlj/RotaryBroach/-/raw/main/RotaryBroachParts.FCStd?ref_type=heads&inline=false which gives many instances of "Autocorrect failed to fix references for Dimension..." even though the parts have not been modified since it was saved in an earlier version. (I have built with FC_USE_TNP_FIX enabled and suspect that this may be related to that symptom.)

I can fix them with the TechDraw_DimensionRepair tool by making a change that looks invisible. Here's the sequence for fixing Dimension001 on BodyBoreOpsPage:

Select the dimension:

Opening dimension repair shows:

See that Vertex20 and Vertex24 are the current geometry. These are the correct names, but "OK" just leads to another "Autocorrect failed to fix references" error.

Re-opening the dimension repair tool, selecting Vertex20 and Vertex24, and clicking "Replace References with Current Selection" makes no visible change to the References 2D Geometry:

Clicking OK does now change the dimension, even though the references did not change visually. However, this horizontal dimension is now wrongly drawn as a distance dimension, even though it still shows as a horizontal dimension in the model tree:

Recomputing does not change the dimension to display correctly.

(Dimensions with aligned vertexes such as Dimension009 are drawn correctly after this repair which does what appears from the user perspective to be a no-op change, but it's not clear if they are really the wrong type internally now.)

Full version info

OS: Debian GNU/Linux 12 (bookworm) (GNOME/gnome)
Word size of FreeCAD: 64-bit
Version: 0.22.0dev.37308 (Git)
Build type: Unknown
Branch: main
Hash: b72a8c4222e74205fcbc181efc2d3182e8c59da5
Python 3.11.2, Qt 5.15.8, Coin 4.0.0, Vtk 9.1.0, OCC 7.6.3
Locale: English/United States (en_US)
Installed mods: 
  * Assembly4 0.50.4
  * Curves 0.6.13
  * sheetmetal 0.3.0
  * ExplodedAssembly
  * fasteners 0.4.66
  * MeshRemodel 1.8919.0
  * freecad.gears 1.0.0
  * Pyramids-and-Polyhedrons
  * dxf_library
  * lattice2 1.0.0
  * boltsfc 2022.11.5
  * in3dca-freegrid 2.0.0
  * parts_library
  * Defeaturing 1.2.0
  * A2plus 0.4.60n
  * CurvedShapes 1.0.4
  * Manipulator 1.5.0
  * Pyramids-and-Polyhedrons.backup1696298372.5270553 (Disabled)
  * Assembly3 0.12.2

Subproject(s) affected?

None

Anything else?

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[maxwxyz]

@WandererFan @bgbsww is this related to toponaming fixes?
Also these related ones in TechDraw: #14052 #14051

[bgbsww]

The DimensionAutoCorrect code does not appear to exist in LS3, so no direct comparison is possible. This is calling into PartFeature.cpp at Feature::getShape() which leads to Feature::getTopoShape and Feature::_getTopoShape, both of which are modified in the toponaming fixes.

This file also throws many, many "DVD::okToProceed - Dimension object has no geometry" warnings before hitting the DimensionAutoCorrect code, which is clearly related. So it looks like many (all?) of the references aren't valid. Not sure why yet.

[johnsonm]

I think that all revisions of that file were created in weekly builds of 0.22, none in stable releases. So if there are indications that any problem here is due to using development versions that had bugs, I'll happily clean up my own files.

[bgbsww]

Fair enough. I definitely haven't ruled out a toponaming connection here; I've never looked at this code or this feature before, so there's a lot I have to understand first. The invalid references could certainly be a side effect of a toponaming bug.

[bgbsww]

Same issues both with TNP and non TNP builds. So it isn't the flag that triggers this. 0.21.1 opens it without broken references, but many warnings like "15:51:10 Dimension039 - no exact match for changed 2d reference: 0".

If it is toponaming, it's common code that got changed, which we've tried to avoid whenever it wasn't super obvious it was correct, and nearly all of it has tests, so this would be more of a special case. I think we need a little input from the TechDraw side to help focus the search.

[WandererFan]

commit 5003dc2 should fix the noise on document load. After that commit, I get 1 complaint about bad references and one about section origin not intersecting shape.

After that fix, I can't duplicate the problems with DimRepair (they may still be there).

There is something funny going on with greedy selection. I can't reproduce it on command, but it seems as if greedy selection works sometimes but not always. I'll look into #14051 and #14052, maybe I'll find a clue there.

[johnsonm]

That is much better, thank you! ❤️

I built 6b5f829 (current main as of a few minutes ago) just now, opened RotaryBroachParts, went to BodyBoreOpsPage, entered TechDraw Workbench, TechDraw_ToggleFrame to see the nodes, selected Dimension001, selected Vertex20 and Vertex24, and got the same result:

I have tried selecting them in both orders (20 first and 24 first) and in both cases, I got the same result each time, each time starting from a fresh instance of FreeCAD.

For greedy selection, I noticed this time that node selection wasn't greedy while doing the vertex replacement. I either clicked or double-clicked on the background (not sure which, since it was reflexive), and then greedy selection worked. But then I have tried a few more times to reproduce that, and failed. I'll keep trying to pay attention and look for a reproducing pattern. 🤞

[johnsonm]

I don't think I was clear before that the type is definitely changing in the display. I also rebuilt with at d4f7807 from main to make sure I'm currently up to date. I definitely see this:

Dimension001 is of Type DistanceX:

Now doing the "repair" of the now-working dimension, having selected identical Vertex20 then Vertex24 and "Replace References with Current Selection":

Click OK and the dimension changes what it looks like:

Select Dimension001 again, and see that it is now of Type Distance:

Finally, changing Dimension001 back to Type DistanceX fixes the display, as you would expect:

[johnsonm]

I confirm that this has been fixed for me; DistanceX no longer changes to Distance.