Transferring blocks from A to B creates mess

I have a two files: let’s call them file A and file B. They both have lots of various blocks, with the same names in A and B respectively, (ca. 100 types).
File A contains complete blocks while file B only has it’s outlines in different locations, some of them are multiplicated.
I want to transfer all blocks.from file A to B to have all blocks in file B replaced with a new contents and position.
Aaaaand Boom! What a surprise. Neither copy-pasting nor inserting does not replace blocks. Instead, Rhino creates new instances by adding suffixes to existing names. What a mess.
Now, I have to manually (100 times) find a blocks with a corresponding ones, replace them, remove empty blocks and then edit their names to original ones.
So my question are:
Is there a way for automated blocks replacement? Am I missing something essential?
I haven’t been using block’s transfer before but this is not an expected behavior to me.
I can’t post a file since it is large and content-sensitive.

Hi Piotr- See if ReplaceBlock helps. I think I’d insert one instance of each block from A into B, and then delete the instances- the definitions will remain. Select all the instances to change (instances of one block) and start ReplaceBlock > SelectFromBlockDefinitionList and then choose the definition name that has the number pre-pended. I hope that is clear…

Also, if the blocks are linked to files, you can use BlockManager to change a block from one file to a different one.


Piotr - Just reported the same issue last week - I was very surprised this functionality is gone compared to Rhin previous versions. ( See: Imported block to replace the definitions existing in the file? )

Currently I have no good workaround - with files with 100s of blocks (as in our case) this is a major disaster; ReplaceBlock one by one is not an option; even scripting this seems not that straight-forward. I really hope good solution will be offered soon as this is a major drawback in our workflow here.


As Jarek described above it is a major disaster to me since all blocks looks nearly the same.
Please restore current behavior with an old functionality bringing at the same time warning info that informs about blocks with identical names and different contents. I guess it will please everyone (I’m referring to the Mitch’s concerns from the post that Jarek has linked).

Hi Piotr- Yeah, I understand the complaint about name collisions for blocks. We are looking at what to do about it.