* Maybe you meant to call base method instead [-Wclazy-skipped-base-method]
* Missing reference in range-for with non trivial type [-Wclazy-range-loop-reference]
* Mixing iterators with const_iterators [-Wclazy-strict-iterators]
* Unused QByteArray [-Wclazy-unused-non-trivial-variable]
* C++11 range-loop might detach Qt container (QList) [-Wclazy-range-loop-detach]
- to avoid invalid results:
- don't allow to set equal radii for cones
- don't allow to set equal wedge parameters
- don't allow zero quantities like e.g. the box width
- use full internal precision because it must be possible to create an e.g. 23.5 um wide box and using the default 2 displayed digits
- take spinbox limits from App
- add missing tooltips
- remove disturbing commented out line from Workbench.cpp
- some coding style issues fixed automatically by the MSVC IDE
We already have the possibility to create skewed prisms. I recently stumbled upon that I would need this feature for cylinders too.
This PR takes the existing prism extrude direction feature and use it for cylinders too
the UI and the property is not consistent. In the dialog we use the term angle upon user feedback while the property still has the name "skew" in it.
I simply forgot this change in my PR that implemented skew prisms.
This is now corrected by this PR.
A better fix for #0004188
Delay calling setPreviewDisplayMode() in ViewProviderPrimitive::setEdit
also fixed issue of not turning off preview mode if the user cancels
editing because there is already a task dialog active.
Rename Python variable 'tv' to avoid potential conflict with others
(PS. I can't reproduce error caused by this. But there is no harm doing
it either).
Handle editing attachment through an App::Link.
=============================================================
The values for the primitives are set after the connections to the slots "onchange" are connected.
This causes a river of onChanges at feature level which set the properties and modify the feature (to the same values).
Moving the connections at the end of the function just solves this issue.
With the recently introduced AttachExtension the PartDesign primitives can be attachable by themself and don't need anymore the helping coordinate system datum. This simplyfies the code and the TreeView largely
