Block name conflict pop up

@RBL is it possible for you to send the files that show this problem? If so, please upload them here: http://www.rhino3d.com/upload and mention the URL of this Discourse thread in the comments.

I sent the file that was requested. If you need all files associated with this let me know.

I just reopened this in V5 with no issues, it just opened up. I closed and reopened in V6 and the update blocks dialog window opened up. The attached PDF has the screen shots as I saw them.

WIP SCREEN SHOT.pdf (139.6 KB)

Thanks, I’ve got the file.

So far I cannot reproduce this - @RBL - is this consistent- can you repeat it?

thanks,

-Pascal

It’s consistent, and repeatable. Any file that has linked and embedded blocks will have the “Block Definitions to Update” window pop up where it states the linked files have changed, any file that is linked would show that there as a newer version available. If it was opened in V5 this dialogue window would not open as there have been no changes.

If "Update now” is selected, the block name conflict windows starts to pop up one after another even if “Do this for all block name conflicts” and “use file”is checked Once all its done with the multiple window opening and box checking is done the file finely opens. If blockmangager is opened there will be several error messages before the block list opens. What seems to be common is that in larger files I’ll see this and in smaller files may not see this to the same extent.

I’ve also noticed if “update all” was selected at start up that the blocks don’t always show as updated in Blockmangager once opened, that the drive name is not always shown in the linked file name in block manager. And that smaller files seem to have less problems and open more or less normally except for the Update block window which always pops up

Another thing I noticed is that the Block Preview window isn’t working either.

Below is a screen shot of blockmanager in V6

And the same screen shot in but in V5

There are many missing blocks in V6 that show in V5 and the preview window shows a detail as shown in the 2 screen shots

Also I’ve noticed that in V6 there be statement that there are hidden block definitions at the bottom of the Blockmanager window that don’t exist in V5

@pascal, @dale, @johnc HI Was this ever resolved or answered elsewhere?
we are moving from rhino 5 to rhino 6 and have this pop up , taking a long time to click thru and the checked box doesnt do anything, and it seems will pop up everytime we update out rhino 6 files from now on, which on our bigger models will take half an hour plus to click thru the pop up.It pops up for all our nested blocks which normally in rhino 5 this didn’t happen.

Is there a macro which could on opening, select the file block option for each and every block,

!_open
file name conflict
file block

I’m in exactly the same situation right now and was about to create a post when I found this topic.

It has taken over an hour per file in some cases to click through the constant dialog box popups when opening large files with multiple levels of nested Blocks. We have spent the past week or so upgrading around 800 of our current work files by having to keep clicking - In the end we just had to bite the bullet and do it which is why we had held of upgrading to r6 for over a year

It has now caused our major array file with around 550 linked and embedded blocks with multiple levels of nesting to hang partway through this exercise so I’ve now had to abort the process after half an hour and start again. Its the last pain point for the initial upgrade process to R6

For background information there are over 550 linked and embedded files that end up in this array through multiple levels of nesting through sub-components, components, sub-assemblies, assemblies, sub-arrays and arrays. This makes what would be a 400MB_ into a ‘manageable’ 100MB. All Block files are linked and embedded to enable correct cut-through display using VisualArq and we have spent a good amount of time working with Enric @ VA to troubleshoot various bugs, crashes and hangs with VA over the past 18 months so have become experienced in helping to recreate the errors for debugging

I notice the same/similar problems referenced here and also here

This is what we have learnt from the process about this problem

  • this always occurs when opening a rhino5 file for the first time in rhino6 - once dealt with and saved as r6 then it should be a one-off

  • if you have multiple levels of nested blocks (linked and embedded) you will need to begin at the lowest level of nesting and save as rhino6 before opening and saving files higher up the nesting chain. The higher up the nesting chain you get the longer it takes for the numerous click-through on the dialog box

  • once the whole nested chain for a block instance down through to a single sub component is resolved in this way then the update error will not reappear when the file is subsequently re-opened. You then however need to go through the same exercise for this sub component for each different block instance in the final model

  • after going through this tedious exercise for us on a single product development project. I can only imagine the impact for those with large legacy file projects if they ever have to re-open them in Rhino6

  • the kicker is that when you go to use the Block Manager and select all blocks then press Update you are back in the same position of being required to click through hundreds of dialog box instances. We regularly use this Update process to detect Layer Settings and unpurged items in our nested chains of blocks that filter all the way through and in the case of our final model (in Rhino 5 ) it can take over an hour to process without the interruptions of the conflict dialog box

There was a suggestion in one of the thread on this problem to enable access to the settings on the dialog box to allow universal modification which may be a possible solution. I’m happy to work with the McNeel team to help overcome this problem and can reproduce the scenario through a shared Dropbox folder @pascal you mentioned here about this

Hopefully we can find a solution to this as it would likely make a few people very happy :joy:

Unfortunately its still a problem:rage::rage:

So far I am too dense to get the name conflict message. In the file provided by @RBL, the blocks, being embedded and linked and since I do not have the linked files, just opens. If I export one of the blocks so that a link can be established, in V5 and then open that file in V6, I get a message about updating the block but I do not get one about a name conflict.

-Pascal

perhaps you need two instances of linked/ embedded blocks or two components which use the same nested block. the conflict possibly only occurs where the nesting is at least two deep

@pascal what is your email so I can share a DropBox link with you to enable you to recreate the problem.

Theres a txt note in the folder explaining how to recreate the problem

Thanks @pascal, I’ve added you to the Dropbox folder. The .txt file should explain how to recreate the problem. I have also been able to recreat this problem in the latest Rhino7 WIP

Updating this thread with further work with @pascal on this late last year although to this point the problem still remains in Rhino v6.23 and Rhino7 WIP

I’ve currently spent over an hour this morning clicking on this block name conflict dialog box repeatedly (still going to try and open file) and it has become a real drain on productivity for our team since upgrading to Rhino 6.

Found some further background to this discussed here
https://mcneel.myjetbrains.com/youtrack/issue/RH-26904

and

a ‘simple prompt’ seems to have caused some major headaches for those that work with extensive multi nested linked and embedded block assemblies

@pascal and @dannysquires
Just for my information… It does not seem as if this issue got solved, right?
I am experiencing the same problems as dannysquires at the moment and I am very curious to find out how to solve that - or if I just gonna have to be a bit more patient. :wink:

Thanks,
T.

Hi Tobias,

Yes it is still a problem for our team which drains productivity and is tedious to manage on our large assembly files with hundreds of sub-components.

I understand why the function exists but t would be good if we were able to set the default behaviour to override the persistant dialog box popups which in some cases have been over 1 1/2 hours to open one file or update all the blocks. Previously this could run in the background whilst working on other things but it now demands constant attention to keep addressing the dialogs.

@pascal I note that R6 has upgraded from v6.21 to v6.27 since this was fisrt discussed.

@dannysquires and @pascal
Yes, I agree. I think what Rhino provides with linked blocks is amazing - honestly!
I would wish for an option (especially for coding) which would let you chose which behaviour to use (e.g. using the newly imported block).
Also as you mentioned it would be cool to check the “replace with imported block” for all conflicts.
I recently forwareded that to Dale and he created this issue.

https://mcneel.myjetbrains.com/youtrack/issue/RH-59783

Basically I guess we are not the only ones having this problem.
I guess a feature like that would be making a gorgeous system even more adoreable.

T.

I’ll be watching this thread with hopeful anticipation. Rhino 7 BETA the problem persists for me, as well.

I wish this would get fixed. I still work in V5 because of this problem, but sometimes the project gets so big that I need V6 to handle the video. Then I’ll save to a step file, then reopen in V6 so the block dialog box doesn’t pop up 2,000 times. It usually works, but not always as some surface may not save correctly in step and then reopen correctly in V6. And of course you loose links to the blocks but they are still blocks…Have not spent a lot of time in V7 Thought this would be a priority to resolve.

It’s on the developers list as a “7.x” item. That means the developer is aware of it, and plans to fix it in the 7.x service release cycle.

Awaiting this fix keenly in our office as the team spending far too much time clicking endlessy to open files when updating nested blocks through to our master arrays.