Path Workbench Repairing an Operation Moved Out of the Job

[freman]

Thanks Chris. Can you point me to that earlier discussion, it would be good to see the detail on this and why it is hard to control DnD.

IMO the better solution is to make DnD do what it appears it should do rather than breaking the treeview. That would be nice.

At a minimum a hack to avoid the destructive results could be added. It should not be too hard to make DnD to nothing on mouse release.

[chrisb]

Thanks Chris. Can you point me to that earlier discussion

Sorry, I haven't bookmarked it.

[Russ4262]

If anyone reading this thread is in possession of an affected file with this separated child operation problem, and is able to shares said file, please due so. I have an idea for a possible solution, but I need `test subjects` to analyze and with which to experiment. Or, if you are able to reproduce this undesirable result, please post some instructions for reproducing the problem.

I also have had this happen inadvertently on occasion in the distant past, but not for some time now.

Thanks,
Russell

[onekk]

One of the main problem with actual implementation of Operations is that they refer internally to some properties of the original job using expressions.

The problem I have tried to script some Path operation, but creating multiple jobs is not possible without bringing the Gui up and ruining the scripting advantage.

The workaround was to create one job with all the operations and then create new job and move the operations in the new job one by one.

Sadly a plain Op copy between Jobs is not as "easy" as it could be, you have to "reset" and "rewrite" every line that refers to the original job, and put "static values" in the right fields, so I suppose that if you move the operation outside the job, something would break in that mechanism and it could not be repaired by the actual "interface".

Hoping in the future (hoiping soon) rewriting of ops and job to make them scriptable such problems are adresses.

Regards

Carlo D.

[chrisb]

If anyone reading this thread is in possession of an affected file with this separated child operation problem, and is able to shares said file, please due so. I have an idea for a possible solution, but I need `test subjects` to analyze and with which to experiment. Or, if you are able to reproduce this undesirable result, please post some instructions for reproducing the problem.

I can do both:
- I start with a standard cube (10x10x10) and a job with nothing but the defaul tool
- add a facing op to the top face
- add a profile to the whole object

Everything is fine with facing op before profile:

SnipScreenshot-b79863.png (13.49 KiB) Viewed 2039 times

ungarbledJob.FCStd

(14.29 KiB) Downloaded 58 times

.

Now I drag with the mouse the profile before the facing op. As a result the MillFace op lies outside of the job:

SnipScreenshot-d6addb.png (13.7 KiB) Viewed 2039 times

garbledJob1.FCStd

(14.14 KiB) Downloaded 59 times

.

I take the MillFace and drag i back to the place before the profile:

SnipScreenshot-84e2a7.png (13.6 KiB) Viewed 2039 times

garbledJob2.FCStd

(14.04 KiB) Downloaded 54 times

This leaves the job in an error state where the Operations node and its profile child lie outside of the job while the MillFace is inside. It is not possible to get rid of the job it cannot be deleted.

[Russ4262]

...
Now I drag with the mouse the profile before the facing op. As a result the MillFace op lies outside of the job:
...
I take the MillFace and drag i back to the place before the profile:
...
This leaves the job in an error state where the Operations node and its profile child lie outside of the job while the MillFace is inside. It is not possible to get rid of the job it cannot be deleted.

Afternoon sir.
Thanks for your great example. I am able to reproduce. Furthermore, I am able to fully restore! I do not have the solution for restricting such damage in the future, but I can provide a solution for restoration! I might make a GUI macro that assists with repairing these issues.

Simple fixes:
1.) For an operation, including dressups with children that have been ejected from their Operations group, do the following in the Python Console:
* Get/make a reference to the parent Job object, such as "job = App.ActiveDocument.Job001", replacing "Job001" with your job's name, not label.
* Get/make a reference to the sad, lost child, such as "op = App.ActiveDocument.Profile002", replacing "Profile002" with your op's name, not label.
* Restore the parent-child relationship, "job.Proxy.addOperation(op)" with kind words
* Finish it off with a great big hug, and "App.ActiveDocument.recompute()"

2.) For an Operation group, with or without dependent children, that has been ejected from their parent Job, do the following in the Python Console:
* Get/make a reference to the parent Job object, such as "job = App.ActiveDocument.Job001", replacing "Job001" with your job's name, not label.
* Get/make a reference to the sad, lost Operations group, such as "ops = App.ActiveDocument.Operations001", replacing "Operations001" with your op group's name, not label.
* Restore the parent-child relationship, "job.Operations = ops" without criticism
* Finish it off with a great big hug, and "App.ActiveDocument.recompute()"

Happy Tuesday (or Wednesday if you are ahead, or Monday if behind)!
Have a fantastic day fellow FreeCADians.

Restoration of relationships is a marvelous endeavor and can bring peace! God bless.

Russell

[freman]

Many thanks for this relatively simple fix. There's a few times I could have done with that. Instead, I've just had to ditch a broken file pick up the pieces from a back-up and redo any recent changes.

I think this was the reason I adopted the strategy Chris suggested earlier of setting a pretty high back-up file count. This means a bit of house cleaning from time to time to remove the clutter.

Outstanding work as always. Many thanks.

[chrisb]

Furthermore, I am able to fully restore!

That is great!

I do not have the solution for restricting such damage in the future,

Can you say what it would need? It is probably some general change in the tree objects. It sounds so useless to invest time in error fixing if the errors could be avoided.

[Russ4262]

...
Can you say what it would need? It is probably some general change in the tree objects. It sounds so useless to invest time in error fixing if the errors could be avoided.

Evening ChrisB.
Thanks for asking. Unfortunately, I know practically nothing about the drag-and-drop code, its location, and what it triggers in say a Job object that is affected by a DaD event. I suspect some of the DaD code is C++ and related to Qt5. If one could locate the python method that is triggered with DaD events, then a few things could be done to lessen or perhaps avoid the damaging behavior.

For example, if `dragEvent()` is called/triggered in the parent object with a DaD event, then we could at minimum add a `restoreDragDamage()` method that would search for orphaned Path objects in the object tree and put them back into at least the correct group or job. No, this is not the solution I would choose to fix the DaD problems we experience; however, if this type of solution is the best we can do in light of current knowledge of DaD and its available controls and current implementation, then I would be willing to work on such an orphan-restoring method, or a structure-verification method. Such a solution would benefit from adding a property to Path objects that identifies their parent object or group by name or other relational genealogy type string that could help verify correct placement of a given object within a job structure.

Just some thoughts, no solution to your question of whether I am able to offer a solution for cause correction, rather than the restoration solution provided in the earlier post. For now, we might ought to clean up the restoration solution and post it in the Wiki for troubleshooting of known problems.

Glad to collaborate with you sir. Thanks for all you do with the project!

Russell

[chrisb]

no solution to your question of whether I am able to offer a solution for cause correction, rather than the restoration solution provided in the earlier post. For now, we might ought to clean up the restoration solution and post it in the Wiki for troubleshooting of known problems.

I see. I had just hoped that while you investigated the problem you have come to some insight where the issue should be fixed. And then it would have been useful to document.

Glad to collaborate with you sir. Thanks for all you do with the project!

And more so vice versa!