Now for unsupported features we report on line numbers and on the entity
handle, in case that unsupported feature is a DXF entity. To avoid
flooding the output, only a maximum of 5 instances are reported with
details. The rest simply add up to the global count and are ellipsized
in the report.
Report output is now in sentence case.
Fixes: #7387.
See comment: https://github.com/FreeCAD/FreeCAD/issues/7387#issuecomment-2915599566
PR to change the base object of BezCurve, BSpline and Wire to `Part::FeaturePython`. This will only affect new objects. So code will have to also keep handling the old object type (`Part::Part2DObjectPython`).
The modification of BimPreflight.py needs to be verified. The steps in the old code lacked logic IMO. But I may have misunderstood.
* Add a test case for DXF import
* Test gui flag rather than look for import error to make gui decision
The new code is cleaner and faster and avoids any exception stuff
* Properly avoid trying to use Layer's View object in non-GUI
The code was trying to avoid this but had a Python None object rather than a null C++ pointer and so tried setting a property on None. This left an unhandled exception state which acted as a booby trap that caused the later failure of some unrelated code.
* [pre-commit.ci] auto fixes from pre-commit.com hooks
for more information, see https://pre-commit.ci
* De-lint, remove wong "unsupported" message
Hidden layers have been supported for a while but still generated an import note about this being unsupported.
* [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>
Fixes#5990
Supersedes #13652
This solution only works for sketches. The export of other planar objects remains the same.
This is similar to the way the C++ DXF exporter handles things. What is different here is that if multiple sketches are exported they are assumed to have the same normal, and their position relative to each other is preserved.
Fixes#16550.
Fixes#16552.
* Layer blocks receive a name with the "LayerBlock_" prefix.
* They are put in a layer if the "Use layer" import option is checked.
* If Draft or Sketch objects are created a Part_Compound instead of a Draft_Block is created. This was done because a Draft_Block does not claim its children. I am not sure about this change. Maybe the behavior of the Draft_Block should be changed instead.
@yorikvanhavre: do you know why a Draft_Block does not claim its children?
* Fix double-import on exception in ImportGUI.readDXF
The python code has a try/catch block intended to detect if the ImportGUI module is present and if so use its readDXF method, otherwise use Import.readDXF.
The block was incorrectly structured so that Import.readDXF would also be called if ImportGUI.readDXF raised an exception, causing the DXF file contents to be loaded twice into the drawing (at least, up to the point where the exception occurred)
* Make ImpExpDxfRead::MakeLayer use centralized accessor for Draft module
The importer class already had a method to find the python Draft module, but MakeLayer was doing the work itself. Now it uses the centralized accessor, which has also been improved to generate a message if the module can't be loaded.
* Give compounded objects names related to the containing layer name
If "Use Layers" is set and also "Group layers into blocks" the names of the generated compound objects will be based on the name of the containing layer.
If "Use Layers" is not set this will not occur because in general objects from several layers would be compounded together.
Fixes (partially) #16068, the remaining fix is likely just an explanation of the interaction of the options.
closes#13597
* Use correct (new) property name OverrideShapeAppearanceChildren
This corrects a bug created by commit 495a96a which renamed the layer property "OverrideShapeColorChildren" to "OverrideShapeAppearanceChildren" but missed this particular reference to the property by its old name.
The code here called PyObject_SetAttrString which, due to the wrong attribute name, set an expection state in the Python engine, ultimately causing the next attempt at importing a module to fail, with various consequences depending on why the module is being imported.
* Wrap PyObject_SetAttrString and PyObject_GetAttrString with error-checkers
In DEBUG compiles these methods are wrapped to report errors which can occur if the property cannot be referenced.
* Make some error-printers static instead of const
They don't need the CDxfRead object to work
* Display exceptions raised by ReadEntity
Although the DXF reader has an ignore-errors flag, it should still report any errors it encounters. The flag is deemed to mean that, after an error, the reader should continue to try to read the file rather than quitting on the first error.
* [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>
* Remove O(n^2) time on DXF import
Accumulates the contents of each layer in a local Python list, then at the end assignes all the objects at once into the layer. This avoids a very slow process of traversing the objects so far and (re-)updating their properties each time a new object is added.
Fixes#16604
* Correct last change to not damage existing layer contents.
The layer could already have contents if the DXF file is being Imported rather than Opened.
The original change would lose the previous layer contents.
Fixes#13621.
Currently the legacy DXF importer creates a main group with the DXF name if a DXF is imported into an existing FreeCAD document. For each DXF layer it then creates a sub-group (or Draft Layer) inside that main group. Objects are nested in the sub-groups (or Draft Layers).
This does not make sense for Draft Layers as they should be nested in the LayerContainer, which should be in the root of the FreeCAD document.
Both for Draft Layers and sub-groups there is the issue that if mutliple DXF files are imported in the same FreeCAD document, exising Draft Layers and sub-groups are not taken into account. For each DXF a new "0" group/layer is created (with a Label that is not "0" and therefore not recognized), and if there are objects on that layer a new group/layer is created for each object (labelled "0001", "0002", "0003", etc).
To solve this the main group with the DXF name is no longer created in the revised code and the layers variable is initialized with the groups/layers that already exist in the FreeCAD document.
Additionally the formatObject function should not format objects that are in Draft Layers. Its action conflicts with the layer mechanism resulting in the last imported object having an incorrect color.
