Addresses one of the issues mentioned in #21667.
* If the Terrain is dropped on the Site it is added to the Group (as before) but the Terrain property is then also set to None.
* If one of the objects in Group is selected as the Terrain it is removed from the Group.
Procedure to trigger the crash:
* Create a document
* Create a spreadsheet and open it
* Close the 3D view
* Open the Start page
* It may or may not crash but the program is in an undefined state
The reason of the crash is caused by an inappropriate use of static_cast.
This bug is caused by PR 17152.
To fix the crash use dynamic_cast instead. If the cast fails it returns
a null pointer instead of a dangling pointer.
This PR fixes a V1.1 regression.
The default for the last point should be the origin of the working plane if Global mode is off.
Forum topic:
https://forum.freecad.org/viewtopic.php?t=97452
* The new align_to_face_and_edge functions would align the Y axis to the edge. This should be the X axis.
* The align_to_point_and_axis functions did not accept a zero length upvec.
* Added a return value to the _next function for compatibilty with its counterpart the _previous function.
All of PathSimulator uses floats, rather than doubles: to prevent
compiler warnings about truncation, explicitly use the single-precision
version of the standard pi constant.
Include `<Base/ProgressIndicator.h>` and bail out when
`Base::ProgressIndicator::getInstance().UserBreak()` returns true during
transformation loops and composite operations in
`FeatureTransformed.cpp`.
Introduce a `Build(const Message_ProgressRange&)` overload in
`FCBRepAlgoAPI_BooleanOperation` (guarded by `OCC_VERSION_HEX <
0x070600`) and route user-abort checks around the operation. Add a new
`OCCTProgressIndicator` adapter (`OCCTProgressIndicator.h`) that bridges
`Message_ProgressIndicator` to `Base::ProgressIndicator`. Include
`OCCTProgressIndicator.h` where needed and update all `Build()` calls in
`TopoShape` and `TopoShapeExpansion` to pass
`OCCTProgressIndicator().Start()`, enabling singleton-based progress
reporting and user-break handling.
Handle possibly raised exceptions in RecoveryRunnable::run().
Since the run() method is executed within the context of a worker
thread all exceptions must be handled before returning to Qt
Concurrent as otherwise the application will be terminated.
For testing purposes load the corrupted project file from this forum
thread https://forum.freecad.org/viewtopic.php?p=823608#p823608
and wait for the auto-saving.
If FreeCAD is loaded without GUI it isn't allowed to access the
QKeySequence class as it will cause a crash. So, it checks
beforehand if QApplication::instance() is null.
This fixes issue 16407
When checking for recovery files also check for validity of the
actual project file. In case it's broken but has a never date
then still process the recovery file.
This is done to reduce the chance of data loss as described in
issue 18044
If an object has a link to itself it may cause a stackoverflow
in several cases:
* If the method claimChildren3D() returns a list containing the
object of the view provider then Document::handleChildren3D()
will add a SoGroup to itself as a child. This will result into
a stackoverflow as soon as an action traverses the scene.
* If the method claimChildren() returns a list containing the
object of the view provider then DocumentItem::createNewItem()
causes an infinite loop with DocumentItem::populateItem()
Solution:
* Inside Document::handleChildren3D() avoid to add a SoGroup to itself
* In this specific case fix ViewProviderCoordinateSystem::claimChildren()
to avoid a cyclic dependency
Hint: Since PR 18126 FreeCAD is vulnerable for this problem.
This fixes issue 19682
This is a regression caused by PR 17564.
ViewProviderDragger has the member 'forwardedViewProvider' that is used
to handle the editing by the parent object. This means that inside
ViewProviderLink::startEditing 'transformDragger' can be null but this
isn't checked so that accessing the member causes a segmentation fault
or a failing assert in debug mode, respectively.
Solution:
Make sure that transformDragger is not null before accessing it.
This fixes 19542.
The command is only able to show the property view in case it's
invisible. But it fails to raise the widget. And if in the preferences
'Combined' mode is set it fails completely.
Solution:
The method DockWindowManager::activate already does everything what's
needed. Now the command only must be changed to access the right
docked widget.
Introduce a new `ProgressIndicator` base class
(`ProgressIndicator.h`/`.cpp`) with a singleton-managed, no-op default
implementation matching OCCT’s `Message_ProgressIndicator` interface.
Update `CMakeLists.txt` to include the new sources.
Do not use the number of decimals from the user settings to pass
the material to the property as this will cause some unexpected
rounding effects.
This fixes issue 19048
The current implementation always returns a width that is too small
so that a scrollbar is shown. Especially on the General page this is
unfortunate as some important controls are truncated or completely
hidden.
Another problem of this implementation is that when loading a not
yet loaded workbench in the 'Available workbenches' page then the
computed size will be by far too high leading to a dialog that all
the sudden covers most of the screen.
Solution:
The correct width is the sum of:
width of the tree view + width of the biggest page + spacing of the layout
This fixes both of the above problems.
* Fix Workbench::listToolbars() to also return custom toolbars or added by a manipulator
* Fix Workbench::getToolbarItems() to also return custom toolbars or added by a manipulator
* Fix Workbench::listMenus() to also return menus added by a manipulator
Fixes issue 18647
When performing undo/redo after tansforming an object it flips back
to its original position but the dragger does not.
This commit set the dragger's placement to the object placement.
Fixes issue 18914
If the user clicks on undo while the transformation dialog is
open the currently active transaction will be closed.
From now on any change of the placement won't be recorded any
more so that e.g. canceling the dialog or an undo after
accepting the dialog leads to unexpected behaviour.
To fix the issue two new virtual methods onUndo() and onRedo()
are added to TaskDialog and reimplemented in TaskTransformDialog.
These functions make sure to open a new transaction.
This fixes issue 19152
Previously you had to make 4 clicks to apply a combo
1 to enter edit, 1 to open the combo, 1 to select, and 1 to defocus and apply
with this commit only 2 clicks:
1 to open the combo and 1 to select
