uwestoehr wrote: ↑Tue Oct 26, 2021 11:19 am
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 :
1) Is that possible to disable AutoTransaction with some parameter switch or other ?
2) 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 ?
3) 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 ?
4) 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 ?
Thanks.