Embedding blocks by batch in Rhino 6

I have many linked blocks in a file. And most of the linked blocks have common child blocks inside them. I am selecting blocks, and looping through all selected blocks. For all those selected blocks, I use

foreach (InstanceDefinition iDef in instanceDefinitionsToEmbed)
Doc.InstanceDefinitions.DestroySourceArchive(iDef, true);

The blocks are ebmedded, but as they contain common child blocks, I keep getting the prompt where I have to choose whether to keep Model Block, File Block or Both blocks.
If there are 1000 blocks, I have to respond to the prompt 1000 times as each of them have common child blocks. Is there any way to skip this and always choose one option untill and unless specified? Thanks

Would it help to DestroySourceArchive of the children or nested blocks first in your code?
Use InstanceDefinition.GetObjects to get to objects within the block instance, and perhaps use recursion if you have more complex nesting.

Hi @rajaa
Thanks for your response. I tried DestroySourceArchive of child blocks, but I still have the prompt showing up. The thing is,

  • Let’s say I have 4 linked blocks named Block_1, Block_2, Block_3, Block_4.
  • I have a block named “Block_A” inside all of the above mentioned blocks
  • I destroy source archive of “Block_A” from Block_1 which should work fine. Then I destroy source archive of Block_1 which is also fine.
  • When I destroy source archive of “Block_A” which is inside Block_2, I get the prompt. If I directly destroy source archive of “Block_2”, i get the prompt.

So If I have 100 blocks, and many similar child blocks, this will cause prompt to appear every time I triy to embed them. Is there any setting where I can specify to use “Model Block” for all of the instances instead of prompt showing up? Thanks

Can you share a sample code and file that I can try to debug at my end?

I have attached the folder with example rhino file with the name “Main_File.3dm”. Which has 3 blocks inside. Block_A(embedded), Block_B(embedded), Block_2(linked). When I try to embed Block_2, I get the prompt.

  public static void EmbedBlocks(List<InstanceObject> instanceobjects, RhinoDoc Doc, bool includeNestedreferences)
        var namesOfInstanceObjectsToFix = instanceobjects.Select(x => x.InstanceDefinition.Name);

        var distinctNames = namesOfInstanceObjectsToFix.Distinct();

        if (includeNestedreferences)
            IEnumerable<InstanceObject> NestedBlocks;
            IEnumerable<InstanceObject> NonNestedBlocks;
            // This gets all internal child blocks from the given list, and also includes the input blocks
            GetAllBlocksList(instanceobjects, out NestedBlocks, out NonNestedBlocks);

            var allBlocks = NestedBlocks.Union(NonNestedBlocks);

            namesOfInstanceObjectsToFix = allBlocks.Select(x => x.InstanceDefinition.Name);

            distinctNames = namesOfInstanceObjectsToFix.Distinct();


        var instanceDefinitionsToEmbed = Doc.InstanceDefinitions.Where(x => namesOfInstanceObjectsToFix.Contains(x.Name)).ToList(); ;

        foreach (InstanceDefinition iDef in instanceDefinitionsToEmbed)
            Doc.InstanceDefinitions.DestroySourceArchive(iDef, true);           

Test.rar (39.8 KB)

@dale I wrote a sample, and tried different orders to traverse through and unlink the nested blocks. I see the problem with a nested block that uses same names as other blocks in the doc (used the example file supplied by Darryl). The prompt box does appear to confirm which block to use. I wonder if it is reasonable that the user specifies this preference in the InstanceDifinitionTable.DestroySourceArchive function. Any thoughts?

@Darryl_Menezes I’m trying to write a sample at my end. your code has a function “GetAllBlocksList”, that I do not want to guess what goes there. Could you please share a more complete sample with the function, command and anything that will help me run in the debugger? Thanks

Hi @rajaa,
Thanks for your response. I have attached the complete sample commandSampleEmbedCommand.txt (5.3 KB)

Thank you for the complete sample. We are working on trying to track this down.