[fixed] dimension removal issue

[uwestoehr]

_THE_ main issue of FreeCAD is toponaming. However for now one has to live with it, also for TD. In order to do this, TD must allow to remove broken dimensions but does not yet.

Take for example this test file:

TD-Test2.FCStd

testfile

(129.85 KiB) Downloaded 37 times

You see there dimensions like "0.000" since I changed something in the construction and used afterwards the menu TechDraw -> Redraw Page.

- directly after opening perform TechDraw -> Redraw Page

You will get the info that some dimensions are broken. The quickest way is to remove them and re-add the ones you need.

- therefore select in the page (not in the tree) in the Front view the dimension "0.000" and press the DEL key on your keyboard

result: -> you get this warning:

TD warning

FreeCAD_gfeOF1jJEn.png (4.85 KiB) Viewed 2247 times

But why should the page break just because of removing a dimension? So TD should be robust enough that the page and template stays stable and only the dimension is removed and such a warning dialog is not necessary.

[wandererfan]

But why should the page break just because of removing a dimension? So TD should be robust enough that the page and template stays stable and only the dimension is removed and such a warning dialog is not necessary.

This message is not generated by TD. It comes from Gui::StdCmdDelete, which gets the Delete key press before TD.

Deleting a Dimension doesn't break anything in TD.

[uwestoehr]

Deleting a Dimension doesn't break anything in TD.

OK, but then the dialog must be omitted. As user I cannot know FC's internals. One sees the info that something might break despite this is not the case.

[wandererfan]

OK, but then the dialog must be omitted. As user I cannot know FC's internals. One sees the info that something might break despite this is not the case.

I don't know of a way to tell the core system not to display the dialog. I think it comes up on every deletion of a DocumentObject that is linked to another DocumentObject.

[chrisb]

We had this discussion already, it occurs similar in the Path workbench. It seems to be desirable to handle a TechDraw page or a Path job similar to a PartDesign body where you can remove features without breaking the body, but that doesn't seem to be an easy task to adapt for TechDraw and Path.

[uwestoehr]

We had this discussion already, it occurs similar in the Path workbench. It seems to be desirable to handle a TechDraw page or a Path job similar to a PartDesign body where you can remove features without breaking the body, but that doesn't seem to be an easy task to adapt for TechDraw and Path.

Good point. What we need is what PartDesign already offers: deleting objects without wrong warnings. So technically it is possible, the question is how.

Werner, could you maybe give us a hint how it can be achieved that one can delete e.g. a dimension from a TechDraw page without getting a warning dialog that the deletion could break something? The point is that the deletion is safe so the warning is wrong and annoying too.

.

[wmayer]

- therefore select in the page (not in the tree) in the Front view the dimension "0.000" and press the DEL key on your keyboard

result: -> you get this warning:

The Delete function from the core system first asks the view provider of the parent object if the selected object can be safely removed. If it says "No" (which is the default behaviour) then the dialog comes up where it's then up to the user to decide what to do.

But why should the page break just because of removing a dimension? So TD should be robust enough that the page and template stays stable and only the dimension is removed and such a warning dialog is not necessary.

The core system doesn't know whether the deletion can break something or not -- only the view provider of the module knows it. But since in this case the virtual method "canDelete" return false the core system assumes that a removal can be harmful and thus asks the user how to continue.

I don't know of a way to tell the core system not to display the dialog. I think it comes up on every deletion of a DocumentObject that is linked to another DocumentObject.

The method canDelete() must be re-implemented by ViewProviderPage which checks if the object can be safely removed.

FYI:
There are use cases where the core Delete function is not suitable like for an edited sketch or a spreadsheet. There you have the possibility to avoid that by pressing DEL the core function is even called.
For this to work you must override the event(QEvent*) method of a widget and handle events of type ShortcutOverride. You must then exactly check what key was pressed and in case of DEL tell the system to accept it. Qt then will send the regular key event directly to this widget.
For a reference implementation how to do this exactly have a look at SheetTableView::event.

[uwestoehr]

The Delete function from the core system first asks the view provider of the parent object if the selected object can be safely removed. If it says "No" (which is the default behaviour) then the dialog comes up where it's then up to the user to decide what to do....

Many thanks! So we can improve the workflow with TD a lot.

As ChrisB pointed out the Path WB guys face the same issue. Chris, could you please forward Werner's info to them?

[chrisb]

ping

ping

[uwestoehr]

Many thanks! So we can improve the workflow with TD a lot.

I found now some time and implemented it accordingly: https://github.com/FreeCAD/FreeCAD/pull/3124

Now removing objects is much easier since you get now only a warning, if necessary and warning with text for the specific case. Moreover the deletion of an anchor view is now forbidden because this would destroy the projection group.

The PR improves the situation already, despite I can imagine there is more fine-tuning to do for some TD objects. For this case , here is the base structure:

* Page: all objects on a page can be deleted; if the page itself should be deleted, issue a warning if it is not empty
* Template: issue a warning because deletion this will break the page, nevertheless allow the deletion if the users insists.
* ProjectionGroup: all objects in a ProjectionGroup can be deleted; if the ProjectionGroup itself should be deleted, issue a warning if it is not empty
* ProjectionGroupItem: all objects in a ProjectionGroupItem can be deleted; block if the ProjectionGroupItem to be deleted is the anchor of a ProjectionGroup because this would break the ProjectionGroup
* low-level objects like dimensions: they don't need special treatments, you can just delete them, either directly or by deleting their view.

I will have the next days a look to check if special objects like e.g. RichAnno need warnings. However, the PR itself does not harm the situation of these objects -> if they can already be deleted, they can still be deleted.