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 