Thanks for all the feedback guys, I begin to get ideas:
- Although some (autodesk mainly) applications allow you to embed any file into any other, without the need to do anything special in the file that you plan to embed, others (solidworks, or the assembly/body system) require you to do something: put your stuff under one structure (body), or save under a special name. This all means you have to "prepare" your file somehow to be importable. This is actually not so terrible as it sounds (to me
), it's actually very little work. I think it would be totally tolerable.
- Seeing my list above, why not have all the options? Imagine a "xref" object, which has a file path property, a timestamp (to autoreload the file if it has changed), and an enum property that can be "compound", "one shape" or "representation". Compound would make the object a compound, and list all the individual objects of the embedded file under it. One shape would show one, big, one-color shape which is internally a compound of all the shapes of the embedded file, but doesn't let you access the individual shapes. The advantage would be that the import would not require any GUI operation (we would be just reading the individual brep files from the fcstd file) and therefore would be much faster. And finally, "representation" would read only an OpenInventor node from the fcstd file.
- So for that last mode to work, one would need to "prepare" the file to be embedded, by adding all the objects one wants to embed to a certain object (a kind of lightweight "body") which will store their openinventor representation in the file. If such preparation is not made, this last mode will not be available.
- We still have to test that, but the selection system is embedded into the coin representation. So it's possible that on importing the coin node, selection still works as if these objects were really existing in the document. But there is the problem of possible double names... Somthing to check on later.
- Of course there is still the problem that in the first (compound) mode, one could create links to the imported objects, and when updating the file, these objects could be gone. But we can minimize the problem by warning the user on file update if some link will become broken...
How does that sound?