Hi,
I have a block with a certain name in my file. I am trying to import another file which has similar block name. Now because of this, i get “Block name conflict” prompt, which makes sense because there are two blocks with same name.
When I import the file, is there any way I could know that this prompt is going to show up? Probably some changes happening in InstanceDefinitionTable Class, or ObjectTable Class ?
I am trying to use RhinoApp.Idle event handler, so I could detect the conflict just before the “block name conflict” prompt is going to show up, but Im not sure where exaclty to look for.
What language are you developing in?
You could load the file with rhinocommon Rhino.FileIO
You can than read the instance definitions from that file and anticipate on name conflicts.
@Willem I am using c#.
Yes, i am using Rhino.FileIO to read names of InstanceDefinitions first. But the thing is, there is a probability that there is no conflict even if the block names are same (for example the blocks are linked to same file, which I cannot check using FileIO). So this is why I am importing them,first.
Most of the times the conflict doesnt occur. But in some cases, it does, and when it does, i have no control over it from Rhinocommon, and I have to click using mouse manually. So i was thinking, if at all there is a change in property in one of the Rhino.DocObjects.Tables just before the Conflict occurs, I could probably change the block name temporarily, so as to avoid the prompt
@Willem Thanks for your suggestion. I have tried this as well. These values are not saved in 3dm archives. When I access them from FileIO, they always return 0.
Another thing is, even if the blocks are linked to same file path, there could still be conflicts (if someone has changed the block in file), so knowing their link paths is not a good option.
I have been trying for a long time to find out if I can anticipate this popup somehow, but not successful so far. It just shows up even before I know it, and then I have to use the mouse.
Hi @dale,
I have a huge file with a lot of linked blocks (also nested links). I want to insert another block, which is linked to a particular filepath. I do this using Rhinocommon as follows:
I Add an InstanceDefinition with the required name to the InstanceDefinitionTable class using InstanceDefinitionTable.Add() method, with a random GeometryBase (Eg. Point at the origin)
Then I use InstanceDefinitionTable.ModifySourceArchive() method to link the InstanceDefinition to a specified path
Lets say the linked filepath has 10 blocks with similar names as the ones in current document. And for one of those blocks, the “Block name conflict prompt” is going to show up (because rhino thinks it is a different block). I want to know beforehand that this prompt is going to show up, and if so, for which block it is going to show up. Is there a way to do this?
How does Rhino compare if two blocks (with same name, and linked to the same file path) are similar or not?
Hi @dale,
I have attached the rar file with blocks, and their respective links, and also the sample command.
I have linked the blocks to the ‘Public Documents’ folder, so it is better to extract the BlockTest.rar file in the Public Documents folder.
There is a file called BLockTest.3dm, and when you run the command in this file, the prompt shows up. I want to know if there is a way to find this out using RhinoCommon
I ran into similar issue with the name conflict popup - now finally it doesn’t show in the scripted version of the Insert command (which is good), however it automatically assumes to keep both blocks. In most cases we need to use “Model Block” option. Is there a way currently to use that method for non-popup scripted version? Or can a command-line option be added to define how to handle the conflicts?
EDIT: I see the dialog changed recently, no longer “Model Block” vs “File Block” options available in the non-scripted popup… only Redefine (old: File Block) or Keep Both. So above wish would be to have option to Redefine or Keep Both (we hardly even need to keep both)
Any progress or news on this? Trying to script my way out of this issue has been causing me quite a few sleepless nights.
A lot of my blocks have M12 x 60mm bolts. We use the same identical part everywhere. Even on small assemblies I end up with block lists like: 0.3m Tube Base Plate M12 x 60mm Bolt M12 x 60mm Bolt 02 M12 x 60mm Bolt 03 M12 x 60mm Bolt 04 UB 310x45
This negates any benefit scripting the assembly process has, since we then have to go and manually fix several dozens of duplicated common parts anyway. And it’s not just the bolts.
This is a pretty old issue, and may not be related to the issue linked above.
Can you describe the issue you are having? Having sample files and/or scripts that we can run here, which reproduce the unwanted behavior, can often be helpful.
Thanks. I read a few threads and this was the closest thing I could find. But you are right, it might not relate and is the Insert command anyway, not -Insert. I made a separate post as well about how this relates to my problem.
Either way, if you’re able to help, I’d appreciate it:
I made 3 models to test. They are components in an assembly. Each has an identical block called “Common Part” defined. There seems to be no way to permanently store or set how conflicting block names is handled even at a per-command basis when I import them all into a new model:
I run the -Insert as part of a script and pull all 3 files into my new model:
Everything is as expected and desired, except that there are extra definitions where block names are conflicting. I’d really like to be able to set how these are handled:
