[Merged] [PR #3822] Strange behavior of copyObject

Merged, abandoned or rejected pull requests are moved here to clear the main Pull Requests forum.
carlopav
Veteran
Posts: 2062
Joined: Mon Dec 31, 2018 1:49 pm
Location: Venice, Italy

[Merged] [PR #3822] Strange behavior of copyObject

Post by carlopav »

If App.ActiveDocument.copyObject(obj) is used on an App::Part, all the Grouped objects appear in the 2 parts at the same time.

Create an App::Part;
Create another object (Part::Cube for example) and move it inside the App::Part;
Use Draft Move with copy enabled to copy the Part object (or the python console with App.ActiveDocument.copyObject(obj));

Result:

Code: Select all

Part001
  └ Origin001
  └ Cube001
Part002
  └ Origin002
  └ Cube001
The cube is inside 2 different Part objects... I didnt' think this could be possible...

Code: Select all

OS: Windows 10 (10.0)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.22284 (Git)
Build type: Release
Branch: master
Hash: bf1e8e48389f5e9e25bd77b67fe98da4213e797c
Python version: 3.6.8
Qt version: 5.12.1
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: Italian/Italy (it_IT)
Last edited by Kunda1 on Tue Feb 02, 2021 12:27 pm, edited 2 times in total.
Reason: Added [Merged]
follow my experiments on BIM modelling for architecture design
chrisb
Veteran
Posts: 53919
Joined: Tue Mar 17, 2015 9:14 am

Re: Strange behavior of copyObject

Post by chrisb »

Moved from Developer forum.
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
User avatar
DeepSOIC
Veteran
Posts: 7896
Joined: Fri Aug 29, 2014 12:45 am
Location: used to be Saint-Petersburg, Russia

Re: Strange behavior of copyObject

Post by DeepSOIC »

I can confirm. Furthermore, i can achieve the same result with duplication dialog (which is a new thing to me actually, I didn't notice when did it appear).

The single-container rule was thought to be necessary when instance objects and crocc-cs links were in planning stage. But realthunder has implemented it all differently, so technically I think the single-container rule is not really needed anymore.


OS: Windows 10 (10.0)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.18234 (Git)
Build type: Release
Branch: master
Hash: 3af5d97e9b2a60823815f662aba25422c4bc45bb
Python version: 3.6.8
Qt version: 5.12.1
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: Russian/Russia (ru_RU)
chrisb
Veteran
Posts: 53919
Joined: Tue Mar 17, 2015 9:14 am

Re: Strange behavior of copyObject

Post by chrisb »

IIRC there is a function returning the placement in the global coordinate system. What does it yield for the cube, if it appears in two positions?
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
User avatar
DeepSOIC
Veteran
Posts: 7896
Joined: Fri Aug 29, 2014 12:45 am
Location: used to be Saint-Petersburg, Russia

Re: Strange behavior of copyObject

Post by DeepSOIC »

chrisb wrote: Tue Aug 25, 2020 10:53 pm IIRC there is a function returning the placement in the global coordinate system. What does it yield for the cube, if it appears in two positions?
For me, it returned the position of cube in Part (and Part001 was apparently ignored)

Part-o-magic goes crazy and is stuck with "container tree is not a tree" error message...

I would also expect visibility automation in Sketcher breaking if a sketch is in two places, as I coded it with single-container assumption too... i think...
carlopav
Veteran
Posts: 2062
Joined: Mon Dec 31, 2018 1:49 pm
Location: Venice, Italy

Re: Strange behavior of copyObject

Post by carlopav »

realthunder wrote: Ping
I do not think this is the intended behaviour: an object should be in 2 different positions just if it has a link nested into the tree, or if if is linked, not if it's simply contained by 2 different parts... Is it?
follow my experiments on BIM modelling for architecture design
chrisb
Veteran
Posts: 53919
Joined: Tue Mar 17, 2015 9:14 am

Re: Strange behavior of copyObject

Post by chrisb »

DeepSOIC wrote: Wed Aug 26, 2020 1:00 am For me, it returned the position of cube in Part (and Part001 was apparently ignored)
Users can of course just not do this and avoid troubles, but to me it seems to point to an unclean concept.
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
realthunder
Veteran
Posts: 2190
Joined: Tue Jan 03, 2017 10:55 am

Re: Strange behavior of copyObject

Post by realthunder »

Just check out the doc string of copyObject(). There are two additional parameters letting you control the behavior. I did modified this function, but the behavior is kept the same before the big merge, i.e. copy without duplicating the dependency.

Same purpose for the object copy dialog. Because of App::Link, there are many possibilities on what depending objects the user want or do not want to copy.
Try Assembly3 with my custom build of FreeCAD at here.
And if you'd like to show your support, you can donate through patreon, liberapay, or paypal
realthunder
Veteran
Posts: 2190
Joined: Tue Jan 03, 2017 10:55 am

Re: Strange behavior of copyObject

Post by realthunder »

I have submitted a PR to throw error in case of copy GeoFeatureGroup/OriginGroup/Part without dependency.
Try Assembly3 with my custom build of FreeCAD at here.
And if you'd like to show your support, you can donate through patreon, liberapay, or paypal
carlopav
Veteran
Posts: 2062
Joined: Mon Dec 31, 2018 1:49 pm
Location: Venice, Italy

Re: Strange behavior of copyObject

Post by carlopav »

I'll check out the doc string of copyObject(). perhaps some different parameters suits better the Draft move with copy usecase.
realthunder wrote: Wed Aug 26, 2020 8:38 am I have submitted a PR to throw error in case of copy GeoFeatureGroup/OriginGroup/Part without dependency.
That was quick! Thanks!
follow my experiments on BIM modelling for architecture design
Post Reply