When BlockEditing a linked block, Rhino opens a new rhino instance (Child) and makes the Parent File unavailable until the Child is closed.
After BlockEdit, the dialog box asking what to do with the blocks from the Child that exist in the Parent does not appear.
As a result, the block instances that are embedded in the Child’s Linked blocks and/or that already exists on the Parent is added with a suffix " 01".
This creates a huge mess for several reasons:
up next time the block is edited it will replace by a * 02 and so forth.
If the renamed block also exists in other linked blocks in the Parent, the block will deviate from the original name and the two (or three or four or…) will coexist autonomously
when you want to update the non linked block the original block name is changed and possibly multiplied, which makes it impossible to work with.
This was something that happened in the past when inserting or updating the blocks. The dialog box is annoying (and unnecessary in my opinion) but at least avoids this problem.
Workaround is to open the linked file autonomously (i.e. not block edit) and then update through the block manager.
However, the problem is that the BlockEdit doesn’t even need to be saved. If you accidentally double click on a linked block the nested blocks will be doubled no matter what.
I have a very large file where that occurs and at first attempt I could not reproduce on a simpler file. At last I was able to reproduce it follow these steps to ‘break it’.
Create a Child.3dm file.
Create a ParentA.3dm file, insert Child embedded and linked.
Create a ParentB.3dm file, insert Child embedded and linked.
Open Child.3dm, and save it
Now the Child inside both parents is not updated.
Create a Grandparent.3dm, insert Parent A embedded and linked.
because the files are linked the Child is updated.
Insert ParentB embedded and linked, it asks what to do with the Child, choose keep current
Although the child is not updated in both parents, the child is updated in Grandparent. BlockEdit ParentA, it asks if you want to update Child, normally I say no and do it over the BlockManager. Update Child, save and close.
On returning to Grandparent the child will be duplicated. BlockEdit ParentB, BlockManager. Update Child, save and close…
On returning to Grandparent you have three Child. BlockEdit ParentA, do nothing, don’t save, just close
On returning to Grandparent you have four Child.
Purge a few times only the last two remain.
Delete ParentB and purge until only one child is left. BlockEdit ParentA, do nothing, don’t save, just close
On returning to Grandparent you have another Child.
If the dialog box would appear after editing the block, you could choose the option you wanted.
@nsgma it looks like the name is only changed in the current session, and not in the linked file. The best option is to open the linked file and give the block a unique name, then after saving the block with ## suffix gets correct automatically.
I’m not sure if a dialog would help much here, because the name cannot be changed in the linked file anyways.
Maybe I am confused by what you just said. You say the name should not change ever. That means the block in the named file should not change either. Currently it doesn’t. I don’t think it is possible to have the same name blocks in the one file for different blocks. So how would you want to solve this? Imo this can only be properly solved by using a unique block name.
If a block conflict dialog would show up, it would be of little help, since the external block cannot be edited from within the current Rhino session.
@Gijs
Maybe we start by a common situation. I have toiletdoorA that is repeat through out the project, I use it on the several toilet blocks of my building1 of which there are several different layouts blocks. it is also on building 2 and 3. The door should never change its name in any of the buildings and also not is the combined file of the three buildings.
It currently does already work like that. When updating a file with toiletdoorA, which already exists in a combined file, the block name conflict dialog box will ask me if I want to add it as a new named instance, replace with the new block or keep the current. Typically by convention (1), we replace with the new block (2). The default option (3) is the worse of all and when the dialog does not appear that is what provokes the renaming.
In Rhino 7, when you open a file with a linked block that needs updating, it asks you if you want to update, if you say yes, the Block Name Conflict dialog box comes up (this doesn’t happen in Rhino 8 - it should!).
When you edit a file that is linked in your file, BlockManager will highlight that the linked file is newer, when you update it, the Block Name Conflict dialog box comes up.
When you double click a linked block, on returning to the file, the Block Name Conflict dialog box does not comes up
Rhino should check if the updated file has blocks that are already in the scene and pop the Block Name Conflict dialog box if that is the case. It would 100% solve the problem.
Please note that this issue occurs even if you accidentally double click a linked block and return to the main file without saving!
To bring the example two or three posts above further, because I realized I had not reach one point that I reached in an actual example in my working files.
After that sequence, create a file called ‘2nd Child.3dm’ and insert embedded and linked only on ParentA. the second time you BlockEdit Parent A, and close it (even without saving), 2nd Child is renamed, even though it is not on ParentB and is only in Grandparent through ParentA itself. The reason being that since there is no Block Name Conflict dialog box, it took the default option for all the blocks in ParentA irrespectively if they were repeated in the main file or not.
You multiply this by several blocks per generation and quickly you have chaos. This should really be taken in consideration as a big problem.
N
Unfortunate. These patches should be worked into R7 as well.
In the meantime, testing another issue I found a simpler way to provoke the renaming of blocks.
Create Child.3dm. Close.
Create Parent.3dm, insert Child as a block Embedded and Linked. Close.
Create Grandparent.3dm, insert Parent as a block Embedded and Linked.
While on Grandparent, BlockEdit Parent. Parent will open in another Rhino Instance.
In Parent, BlockEdit Child. Child will open in another Rhino Instance.
Save and close Child.
Save and Close Parent.
In Grandparent, a renamed version of Child will be added.
@Gijs, (@dale@mary)
I read now the YT report and would like to make two notes.
In Rhino 7, it was not that easy to break this. You have to ‘force’ it to occur, as described in my previous message.
The YT does not mention the “easy fix” of popping the Block Name Conflict dialog box, when returning to the host file. If this would happen (as it does on opening or updating) the issue would be “pushed” to the users choice.
I hope this makes it easier to address and faster to get a solution. Please let me know if that is not clear.
N
