Wish: LayerName of BlockDefinition Displayed in Property Panel

When selecting a block instance, I really (really) need to see - immediately - on which layer the BlockDefinition resides. In R7.

If modifying the definition there’s the risk of accidently moving the definition to some irrelevant Current layer and… well, I think people have had this wish a thousand times. Or maybe I’m wrong, perhaps two thousand times?

// Rolf

Hi Rolf - the definition objects can reside on any number of layers.


I meant the definition info for a specific block instance (top-most in a nested block).

If redefining a block (after deleting it) without knowing on which layer the original definition was located (can’t even find out beforehand), then the definition may move to another (the current) layer, which is not good if retaining the original definition-layer is required in order to maintain hide/lock strategy etc for a hierarchy.

This problem happens quite often when redrawing some imported models in which I need to retain the definition-layer structure. I understand that re-creating while the definition is still in the model doesn’t change the layer, but sometimes I need to delete the definition ([edit] or exploded block) or altogether when redrawing an object.

But also as a general thing, I often want to know where the top-most block definition ended up (often mistakenly on the wrong layer, but how would I know?). Two-way info needed:

  1. Selecting a block instance = show layer name of definition.
  2. Selecting a layer = show definitions on this layer.

Why is this info hidden?

// Rolf

I might very well be confused…
The block definition doesn’t maintain information of layers other than those on which the objects in the definition are created.

The instance is created on a layer that, when created, is the current layer. You can move the instance to any layer.

When you select a block, irrespective of how many levels of blocks there are inside that block, the layer on which the block resides is shown in the layer field in both the status bar and the Properties panel.

The SelLayer and then selecting a layer from the list will tell you if there is a block instance on that layer.

Yeah - this is the confusion - the definition is the object(s) that make up the block - these can be in any number and be on any layers. An instance of a block resides on exactly one layer but this is independent of the objects in the definition. Note ExplodeBlock does nothing to the block definition, it just copies the bits from the definition and puts them where the exploded instance was.


I know the difference between instance and definition. No confusion there. I tried it again and again (see “Test this” below.)

So again, I’m not talking about instance layers, instead I want to know on which layer the definition resides. Whether the definition “resides” there of not (technically speaking) doesn’t really matter, what matters is that that very layer cannot be deleted, and when hiding/locking this definition layer, then any instances are also hidden/locked. That’s what matters.

So, there’s something about “definition layer” which I don’t want to know more about other than that I want to know ITS NAME, so I can control where it lands.


Okay now; test this so we are on the same page:

  1. Define a simple “Block A” on layer “A”.
  2. Move the visible instance of “Block A” to layer “Default”.
  3. Try to delete layer “A” (won’t allow, since there’s block definition (“Block A”) on layer A.

Now again, when I select (any) instance based on “Block A” I do want to se in the property panel that this instance is based on a definition which resides on layer “A”.

This should be very clear and I don’t think I am confused about the difference between a block definition and a block instance.

// Rolf

Hi Rolf -
It’s clear as long as there is only one object, or only objects on one layer, in the definition. This is seldom the case. Or, at least very often not the case.


You can’t delete layer “A” because, in the definition, the object is on layer A.

There’s no difference if there are multiple instances on different layers regarding the problem I talk about.

In the picture below, I defined a sphere on layer Sphere_BLOCK. That layer cannot be deleted (since it has a definition defined in it. The two sphere instances are on separate layers (sphere 1 and sphere 2) which can be deleted. If I select any of the two sphere’s I want to see that the definition layer name is “Sphere_BLOCK”.

I don’t understand how you mean that multiple instances on different layers would make any difference. There’s only one definition for any instance of that definition.

Are we talking about different things?

// Rolf

Hi Rolf - a block can be made up of a sphere that resides on layer Sphere and a box that resides on layer Box. These together can be in a single block definition and instances can be on either of these layers or some other layer.


A new “top-level block definition” that is. But that doesn’t do away with what I’m talking about - selecting that very new top level block should show me where it was defined (on “new compound layer”, that is. Again, regardless of where a zillion other instances are located).

Selecting an instance (which always would be the top-level block, not it’s nested sub-blocks, that is) should give me the layer on which the top-level block is defined. If I want to know about the nested “sub-blocks”, of course I assume I would have to drill myself down to each of them to find the same info (on which layer it was defined).

// Rolf

But this is not a thing, ‘top level block’. If you select objects and run the Block command, the result is an instance of the block - It does not care where it resides - you can move it to another layer, it not a special kind of instance. If you then use the Insert command you’ll see you can insert a new instance on any layer. The bits inside - the definition - stay on whatever layers they were on to begin with - they do not care about the instance layer.


It is a description of a nested (“compound”) block instance.

// Rolf

Create a sphere on “Layer 1”
Create a box on “Layer 2”
Make “Layer 3” the current layer
Select both object and run Block

Now, the definition of block contains 2 layer - those that the objects reside on.
The definition doesn’t contain any other layers.
The instance is on “Layer 3”.

You select the instance. Which layer are you expecting to get information about?

So you are saying that there is no block definition for the “compound” (sphere + box) on Layer 3?

But regardless of that, my request/wish is till the same, given your example: When I drill down to the individual “sphere” instance (which I expect I would have to do), I still want to know on which layer it was defined (on layer 1 in this case).

A bonus would be to have the property “Details” panel show all the instances paired with their block definition layers (to show also the case when a nested block is selected.)

I don’t see the problem with this, only problem is that this crucial info is hidden.

// Rolf

Hi Rolf - how are you drilling down? If you BlockEdit and select the sphere within the block instance you are editing, it will tell you what layer that part of the definition resides on - and you can change it. BlockEdit gives you access to the definition, albeit indirectly.

In case it helps, I think I have a script around here someplace that will move all definition geometry to a selected instance’s layer.


On which layer is this red cube-block defined? I can’t see it, although in this case I know it’s defined on layer Sphere_BLOCK:

Again, the information is hidden, which is a problem many many times, again and again (causing the losing of control over the definition layers).

The “compound” block before selecting it (so the colors are the colors shown on the layer table):

// Rolf

If you select the red sphere and look at its properties, you can see, and change, what layer it is on. Being red, I assume it is on Default.


No, and no.

  1. You cannot see on which layer the sphere block was defined, only on which layer the instance resides.

  2. The red colors was (unfortunately) due to selection. The Sphere instead resides on its “Sphere 1 - Instance” layer (se added picture in last post where all layers can be paired to the object colors).

Can you post that file?