The problem is that inside Transaction::addObjectNew() a transaction object is deleted before removing it from the container. When deleting the corresponding transactional object (i.e. a DocumentObject or ViewProvider)
it can happen that it e.g. calls Transaction::addOrRemoveProperty() that now finds the dangling pointer in the container.
The safe way is to first remove the object from the container before deleting it.
The counterbore is basically a special case of the countersink
with a countersink angle of 180 degrees and applied depth.
Handling it that way elimintaes some duplicate code and adds the ability to
combine countersinks and counterbore to form a counterdrill.
The sanity check on countersinkAngle can be safely dropped as it is ensured
by a constraint on the property itself.
HoleCutDepth is reset to 0 to force a recalculation of te depth when
HoleCutType is set to a new value.
But the line
pcHole->HoleCutCustomValues.setValue(false)
also forces a recalculation. So the depth was recalculated with the old
value in HoleCutType which was not expected behaviour.
================================================================
Master has a problem in that internal alignment constraints are suggested to the user for removal.
This is fundamentally wrong, as an internal alignment constraint are an inherent part of the geometry. They cannot be the ones suggested for removal.
The popularity contest algorithm is an heuristic algorithm that determines which redundant/conflicting constraints should be proposed for removal.
Basically, the algorithm works on groups of redundant/conflicting constraints detected via the QR decomposition. A constraint may belong to more than one group.
The algorithm runs some heuristics, each constraint scoring a value, the one constraint from each group scoring the highest is proposed (is more popular and wins the contest).
This PR documents the algorithm, and adds a further condition, that internal alignment constraints are never proposed.
As the solver works with solver constraints as opposed to the sketcher, which works with sketcher constraints, information about whether a solver constraint originated from a
sketcher constraint that is internal alignment is necessary. So the solver constraint is extended to accomodate this piece of information.
As a bonus, it fixes a bug. Solver constraints carry information of the ID of the corresponding sketcher constraint in their tag. Knots are not currently implemented as constraints.
However, the tag index was not being update. This caused the popularity contest to provide wrong suggestions despite good detection.
* Change no need function newDocument("Unnamed") call to variant without parameter. "Unnamed" set in App newDocument function instead.
* Refactor New Document command to run without parameter.
* Translate new document's userName. Internal name = "Unnamed".
* Crowdin Add to updatets.py App.ts. Create new file App.ts
* Fix error where document name is set with one function parameter. In this situation set internal and user name to string variable. For default function call (without parameter) set internal name to Unnamed, userName = translate ("Unnamed")
- in current implementation, backedit feature is lost if user changes camera mode (for example from orthographic to
perspective, or oppositely). This happens because when changing camera mode, Coin actually do not just change a
parameter of the camera node, but delete the current camera node and add a new one to the scenegraph. Thus the
SoFieldSensor currently used (attached to camera orientation) is just detached and sensing is left -- notice is would
be same with a SoNodeSensor attached to camera node --. The solution is to attach the sensor at scenegraph root node
so it isn't lost when camera mode changed. No pre-check (such as checking if camera node changed since last call) has
been added currently because it would not actually reduce callback execution time (and even worsen it).
