Will have a look.
For the 2nd example (Body), I think there isn’t much to do as double click is caught by the class to be used as “Make active” whatever is the edit mode. We can eventually discuss to change this, but need to find an agreement on new behavior.
For 1st example (and in general), notice that the PR just changed the way the ‘Edit’ of the classes is called, but not the classes themselves. However IIRC we discussed with @wmayer in another thread of some special handling of editing in some classes (to handle transactions) and maybe that breaks user edit mode.
Also remember that user edit mode didn’t add any new abilities to objects, it just supports edit modes that were already implemented.
In case someone else want to have a look, from a code point of view, user edit mode will ATM work only if edition is called with ‘FCMD_SET_EDIT’ macro.
I see. Since Bodies are a main object, maybe there should be a note in the Wiki, that Bodies are not affected by UserEditMode.
I reported this case since the PartDesign primitives have the same coloring feature than the Part primitives. Therefore when using UserEditMode with Color mode on a Part primitive should give the same result than with a PartDesign primitive.
You were right to report in any case.
OK, I had a deeper look and … it’s a mess. PartDesign ViewProviders are implemented in much different & inconsistent ways that will make working on it pretty difficult. There also are things that I can figure out the purpose, so I can’t ATM be sure of a solution proposal.
Regarding inconsistencies, you can see them first from the editing behavior (in following lines ‘Box’ is a PartDesign additive cube primitive) :
If you double click a PartDesign feature inside a non-active Body, the latter will become active for example with Loft or Sweep, but not with Pad or Box
If you have a Box inside a non-active Body and copy then paste it (will paste out of the Body), then finally double-click on it, it will reject editing but the Body will become active if the document has a single Body, not if 2 or more
If you save the file above and reopen it, you won’t be warned about the lamous document structure if you edit the Box. But if you edit for example a Loft that is also there, it will prompt you to propose structure migration
You can also see them in the undo stack management :
If you edit a Pad or Box, you’ll see a transaction called ‘Edit OBJECTNAME’ but if you edit a Loft for example, you’ll just see a laconic ‘Edit’, because on the latter case non Command is open but it’s generated only by the AutoTransaction system
Enough boring details for now. Now the things I can’t figure out. Will ping @wmayer and @abdullah because I think they have a good knowledge of that, but anybody feel free to answer :
Some questions you may be able to answer that can help me figure out some things :
Is that possible to disable AutoTransaction with some parameter switch or other ?
I can’t understand what exactly means the doc string of FCMD_SET_EDIT. Could you clarify what makes it special to “Edit the object using the active document” allowing “in-place editing”. What special behavior/capability it brings compared to other editing methods ?
On these lines of Utils.cpp, ‘setEdit’ makes different cases whether the edited feature is inside the active or a non-active Body. Roughly, it will respectively generate “DOCUMENT.setEdit(‘BODY’, 0, ‘.FEATURE’)” or “DOCUMENT.setEdit(‘BODY.FEATURE’, 0, ‘’)”. As far as I could test, I see no functional difference between both. Would you know why these 2 cases are processed differently ?
On the same block, the last line uses ‘Gui::cmdGuiDocument’ to run the edit command. Do you see reasons why it could harmful to use ‘FCMD_SET_EDIT’ instead ?
Tanks. However can you please split the PR in two PRs, one for the GUI part and one for the PD fix? This is easier to backport and also better to keep the overview.
