There are other posts concerning this. I’m casting another vote/wish.
“There is a block definition named “x” on layer “y”, use the BlockManager command to delete this block before trying to delete this layer.”
Why not:
“There is a block definition named “x” on layer “y”, would you like to delete this block in addition to the selected layer? OK / Cancel”
It’s tedious to open up a separate function (Block Manager), weed through the blocks until I find it, then go back and delete the layer.
I’m sure I’m overlooking the difficulty in actually implementing this option. But it seems like an objective improvement to the current workflow.
If this can’t be solved, Block Manager should at least show the layer each block resides in, allow the user to sort by layer name, and even search to narrow to a specific layer.
Thank you for reviewing, and for any insight on the issue.
The worry here is that in deleting a block definition will delete any block instances remaining in the file that have been made from that definition. The wording is also somewhat inaccurate, block definitions do not reside on a layer… but the objects making up the definitions do.
So I would say this:
When deleting a layer that has or had objects that make up an existing definition, Rhino should first check if there are any instances still using that definition. If not, then it throws up a message something like:
“Deleting this layer will also delete unused block definition(s) Blockname XYZ. Proceed?”
(Yes/Cancel)
If there are instances in the file that are using this definition, then the message could read:
“There are X block instances in this file that are using (a) block definition(s) that include(s) this layer. Deleting the layer will also delete the block definition(s) and ALL of these instances. Proceed?”
(Yes/Cancel)
Certainly a major improvement to the status quo. But perhaps the real solution is to undo the ill-advised design which fails to make a clear distinction between definitions and instances. Definitions need to be conceptually distinct from instances and reside in their own “parking spot” with clear formalized relationships and procedures connecting them with their instances.
I thought that was how it would work before I encountered this illogical handling of blocks. After importing copying object as the project goes on, it gets more than frustrating to track down blocks, nested blocks just in order to delete garbage layers.
It would be handy to have a button “Open Block Manager” just here to save some time and make UI more friendly. Then user will figure out what to do with those blocks.
