Hi - this is new behavior to me in V5 - I’d like to import blocks from other file, and the imported definitions to replace the definitions that sit in my file. Currently they get autorenamed. What is the best way to do it?
Personally, i think this should be considered a bug as Rhino is not clever enough to detect that a file with the same instance name exists upon importing another one. It should never change blocknames on the fly by appending numbers to the blockname and if it does so, it should at least inform the user about it, or even better let the user interact to define what is happening next.
Last time i´ve stumbled over that, i`ve opened Rhino twice, double clicked on the block in each Rhino instance and used Copy & Paste to transfer my geometry.
c.
Thanks Clement. Really!? There is no way around it? I have dozens of blocks so the by-hand method is out of question. In V4 it worked just fine… If there is no way to do it I’d definitely consider it a problem. Still hope there is a good way. @Pascal, any suggestions?
j
If you export the blocks out from old file, then in the new file under the properties of the blocks, change them to “Embed and Linked” and browse to the exported files they will get updated.
I am guessing the thinking is if you want a block to be updated by external source it would be linked. Otherwise you would want the block definition to have a different name.
Hi Jarek,
I have some scripted functionality to replace the paths for linked blocks as well as renaming blocks per rules.
What would your ideal workflow be; are your blocks linked or fully embedded?
-Willem
Hi Willem - thanks~ the blocks are embedded. I just import the same set of blocks (updated) from another file, and want to have the old block definitions updated and keep their names the same.
Currently it will keep the old definition and add the new one, instead of replacing.
@clement @Jarek Well, as a counterpoint, with V4, we chronically suffered the opposite way from the same problem, that is same named blocks replacing the originals when importing files. The typical scenario was importing a dozen or so adjacent dxf files from the local city planners for a neighborhood, and finding that they all had the same set of “standardized” blocks for different parts of the file - building outlines, street borders, etc. - so when importing a new file (say the neighboring parcel) it killed the existing one by replacing the existing blocks with different ones. The only workaround was to systematically explode all blocks on import.
–Mitch
@Mitch, I can see how that can be a problem as well… but flipping it the other side in V5 doesn’t solve it. There should be prompt on import what to do with same name block instances… no?
Please try this: Create a new document containing a filleted box and make an embedded Block named “RoundCube_01” from it, then save that file. In a new document, create a sphere, make a block from it named again “RoundCube_01” and then open the Blockmanager and double click on the blockname. Once the Block definition type is changed from "“Embed” to “Embed and link”, the icon to browse for a new file gets accessable. Choose the file containing the round cube and this is how blockmanager looks:
Now i have two blocks, both contain a round cube and one is named RoundCube_01 01. This is not funny, especially if you deal with +250 different blocknames which all have numbers at their end. You could imagine the mess if the file imported is a file containing multiple blocks which are present in the original file.
I would prefer the V4 behaviour and additionally a dialog which gives the user control what is going to happen for the cases Mitch mentioned. It should work on embedded Blocks and linked blocks if possible. One possible scenario would be a file option for the ReplaceBlock command which lets me choose a File and then pops up a dialog containing all the block names in the file. The one the user chooses is then imported and the existing name should be maintained.
A similar, error preventing control would be possible for insert and import.
c.
1 Like
This is because you have a block named RoundCube_01 and a nested block called RoundCube_01 inside it. So RoundCube_01 01 is the nested block that is inside RoundCube_01 which cause a conflict as you can’t/shouldn’t have a nested block inside another block with the same name. Rhino treats all geometry it imports geometry it links as blocks, so block inside a file become nested blocks.
If you have a file is box polysurface in a file a called RoundCube_01.3dm and a file called RoundCube_01.3dm in another location with a sphere it. Then insert box RoundCube_01 into a test file “embed and linked”. Then you can browse to sphere RoundCube_01 and it will updated showing the sphere, and you will have just in your test file.
Definitely…
–Mitch
I agree as well. It would be nice to the option and let the user decide, that way you could give the name you really want on import instead of have to rename after the fact (if you did want a new block)
If i import one file into another one, Rhino decides that one of the blocknames in the opened file is used in the imported file. Thats all, there is no nesting involved. Please forget the example above using linked blocks, the problem is there with embedded ones that Rhino changes block names which i use programatically. The renaming, without user interaction can cause chaos.
Please try: Create single box, Block it, name the Block “A”. Save file as xyz.3dm. In another file create a sphere, Block it, name the Block “A” again. Import the first saved xyz.3dm file in the opened file, Rhino renames one of the embedded blocks. This is the initial problem Jarek is having.
The problem with the files i´m dealing with is that numbers are appended to our blocknames and that many people send files which contain a large amount of instance definitions but have not placed them. They are remaining in the files so they can be added by scripts using their blockname. After importing files containing changes made by external sources (changes made on the geometry, not on the blocks), it is very hard to keep track of things which have been deleted after Rhino renamed blocks during import. The way Rhino handles imports, containing (embedded) blocknames existing in the currently opened file, is all i would like to see improved.
Personally i would prefer to use more linked blocks as you suggested, so they can be exchanged much easier, but this not has been my decision 
c.
Hi Clement- This seems to me to be a little different since the result is a nested block - what should happen here? If the file you link to does not, itself, contain a block but only the round cube polysurface, then the replacement is as expected, correct?
-Pascal
Yes, that is correct.
c.
Hi Jarek- there is a chance- we are considering what to do here.
thanks,
-Pascal.
great, thanks for looking into that. I vote for simple ‘prompt’.
~j