* Assembly: replace properties float by propertylength & propertyangle
* [pre-commit.ci] auto fixes from pre-commit.com hooks
for more information, see https://pre-commit.ci
---------
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
* Core: Add signalBeforeOpenTransaction
* Assembly: Isolate
* [pre-commit.ci] auto fixes from pre-commit.com hooks
for more information, see https://pre-commit.ci
* Update src/App/AutoTransaction.cpp
Co-authored-by: Chris Hennes <chennes@pioneerlibrarysystem.org>
---------
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Co-authored-by: Chris Hennes <chennes@pioneerlibrarysystem.org>
When validating distance joints, parts would move from preview position to
a different valid solution. This was caused by preSolve() being called
inconsistently - applied during offset changes for all joint types, but
distance joints are not in JointUsingPreSolve list.
Fix: Only call preSolve() for joint types that are designed to use it,
matching the logic used elsewhere in the codebase.
As the title says - root cause of this problem was imprecise reference
matching by moving_part and TNP string processing incosistencies, so the
solution is to give enhanced matching and TNP string mapping for
reliable deletion.
Also added context menu with keyboard shortucs so user is able to delete
stuff with right click.
Currently if we close document on Assembly WB while having dialog
opened, it will throw segfault because it is not being auto closed
automatically during document close. This in turn resulted in dialog
having dangling references to document that was no longer existing,
throwing segfaults in random places.
So solution is simple - add `setAutoCloseOnDeletedDocument` for every
dialog in Assembly to avoid this situation and close every dialog upon
document close.
* Assembly: Replace "Activated" property by the core "Suppressed" mechanism.
* Fix inaccuracy
* [pre-commit.ci] auto fixes from pre-commit.com hooks
for more information, see https://pre-commit.ci
* move the change to migrationScript5 function
* Update JointObject.py
* [pre-commit.ci] auto fixes from pre-commit.com hooks
for more information, see https://pre-commit.ci
---------
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
Description of Defects in migrationScript2 and migrationScript4:
Several additional issues have been identified in the Assembly
functions migrationScript4 and migrationScript2, beyond those fixed in
patch 71f0104bb2.
One common problem is that the Joint property Reference1 or Reference2
can be set to an invalid format. For example, user can manually cause
this issue by assigning an incorrect reference (e.g., the Z-axis) to
these properties via the FreeCAD GUI. When this happens, internal
errors (exceptions and their corresponding Python call stack) are
reported in the Report View. However, such information is not helpful
for the user to fix their 3D model.
Issues with the Current Implementation (Using migrationScript4 as
Reference):
- Lack of Type Validation for Reference1 and Reference2:
The script does not check whether joint.Reference1[1] or
joint.Reference2[1] is a sequence. If this condition is not met,
statements like:
sub1 = joint.Reference1[1][0]
will throw an exception, printing the Python call stack.
- Lack of Length Validation for Sequences:
The script does not ensure that the sequence length is sufficient
for indexing. For example, joint.Reference1 and joint.Reference2
must each have at least two elements to allow:
joint.Reference1[1][1]
joint.Reference2[1][1]
Without validation, such calls can result in exceptions, printing the
Python call stack.
- No Feedback on Problematic Joint:
The user is not informed about which Assembly joint in the object
hierarchy has an invalid Reference1 or Reference2. Depending on the
size of the 3D model, identifying the defect can be time-consuming
and frustrating without proper feedback.
This patch is focused on:
- Reporting Problematic Joint Path:
A new function has been added to retrieve the full path to the
Assembly joint. The return value (a string) is used to report the
issue.
- Improved Exception Handling:
Instead of adding more conditional checks (see above), exception
handling is implemented. AttributeError, IndexError, and TypeError
exceptions are caught. The exception message (excluding the call
stack) is displayed at the end of a user-friendly warning.
- User-Friendly Warnings in the Report View:
A single-line warning is now shown in the Report View, containing
the following details:
- Source of Warning: 'Assembly joint'
- Location in the 3D Model: e.g., 'Assembly_XY.object_XY.joint_XY'
- Problematic Attribute: e.g., 'ReferenceXY'
- Exception Message: e.g., 'list index out of range'
- Refactoring and Optimization:
The functions were refactored and optimized at the end of the
conversion process.
Advantages:
- Cleaner Report View:
Internal errors (e.g., Python call stacks) are no longer logged in
the Report View, as they are not useful for end users. Only the
exception message is displayed.
- Improved User Feedback:
Users can now identify the problematic Assembly joint in the object
hierarchy, saving significant time and effort.
- Robust and Concise Code:
The solution simplifies the code while increasing its robustness.
* Assembly: Joint Object : encapsulate the joint creation widget such that the task can be subclassed and ui customized by other commands.
* Assembly: Insert New Part
* Update src/Mod/Assembly/CommandInsertNewPart.py
Co-authored-by: Kacper Donat <kadet1090@gmail.com>
---------
Co-authored-by: Kacper Donat <kadet1090@gmail.com>
The old CAD model created by the development version of FreeCAD
(in which the Assembly workbench was used) contained joints that,
for some reason, had an empty Joint Connector 1 reference (Reference1).
This was causing an exception and a crash of the Python function
called migrationScript4. The FreeCAD Report view contained:
23:28:29 pyException: Traceback (most recent call last):
File "/FreeCAD/Mod/Assembly/JointObject.py", line 175, in onDocumentRestored
self.createProperties(joint)
File "/FreeCAD/Mod/Assembly/JointObject.py", line 181, in createProperties
self.migrationScript4(joint)
File "/FreeCAD/Mod/Assembly/JointObject.py", line 514, in migrationScript4
if hasattr(joint, "Reference1") and joint.Reference1[0] is not None:
~~~~~~~~~~~~~~~~^^^
<class 'TypeError'>: 'NoneType' object is not subscriptable
This patch attempts to avoid such exceptions by validating the type of
the property variable before accessing it.
