vocx wrote: ↑
Mon Oct 21, 2019 10:36 pm
You cannot expect a completely new feature like what you want to be included in 0.19. [...] As soon as you develop a prototype, the faster it can be tested and included into FreeCAD.
realthunder wrote: ↑
Thu Oct 24, 2019 12:36 am
It is not impossible through App::Link. Well, nothing is impossible. But it's too much trouble to achieve this
Well, as it happens, this link to a "variant
" part is not a new feature and o trouble at all because it is already possible to do it with FreeCAD_v019. I'll show here the prototype. It does some workarounds because of the way App::Link behaves, and this should be fixed IMO, and the sooner the better. That's the reason I continue to post under this thread.
DeepSOIC wrote: ↑
Tue Oct 22, 2019 9:31 am
So, to properly support it, we'll need an optimized mechanism of copying objects, and a mechanism of storing these varied objects.
This is the crux of the matter, and there is a solution: create a hidden document, copy the part there, and link to that part. Except that App::Link doesn't allow that, so you have to "cheat
" it by giving a fake file-name to the hidden document. This produces an error <PropertyLinks> PropertyLinks.cpp(2566): document not found /home/hubertz/Documents/3Dcad/FreeCAD/Data/Forum/toto
but the links still work. This means that it's a self-imposed limitation and the error checking is useless.
Zolko wrote: ↑
Wed Oct 23, 2019 7:52 am
OK, so if I understand then the "variant" would need a copy, and thus cannot be a pure App::Link.
In the attached file, there is a part Beam
with an extrusion, and an assembly with 4 links to that same part. If you insert into the Python console the following lines, it will create the hidden document, copy the Beam part there, link back 3 links to this Part, and change the variables of the copied part. This affects only the 3 links to that copied part, but not the original part and not the first link that is linked to the original part:
Code: Select all
asmDoc = App.ActiveDocument
tmpDoc = App.newDocument('tmpDoc', label='tmpDoc', hidden='True')
beamCopy = tmpDoc.copyObject( asmDoc.getObject( 'Beam'), 'True' )
asmDoc.getObject('Beam_2').LinkedObject = beamCopy
asmDoc.getObject('Beam_3').LinkedObject = beamCopy
asmDoc.getObject('Beam_4').LinkedObject = beamCopy
copyVars = beamCopy.getObject('Variables')
Unfortunately, I cannot post here the resulting assembly because it cannot be saved: since the variant parts point to a document in memory App::Link in its current form cannot deal with it.
This means that the functionality of "variant
" parts cannot be represented on disk with the current App::Link implementation, although it's a perfectly valid — and extremely useful — functionality. So it's not a question of App::Link "functionality
" but a question of App::Link "data structure
". I haven't seen here an analysis of the data structure in the fcstd files used by App::Link, and I think that this also should be reviewed. There are 17 properties for each App::Link instance, and I think this should be adapted/extended.
As I said in another thread
, the user's data structure is what matters most: once users start producing data with this new tool (App::Link) it will be very difficult to change the way the data is represented on disk. As long as v0.19-pre
is identified as a development version this is still adaptable, but once it reaches -beta
status it's over, then all developers will have to support whatever has been agreed-on (or left-in by lazynes). And I think that the current App::Link data structure as stored in the *.fcstd file needs refinement, one of them being able to represent "variant
" links as described here.