Elements copied out of a Block change Layer
I open a Block in Refedit; select some elements; Copy them to elsewhere in Modelspace; minus the copies out of the Block ('Remove from Refedit'); close Refedit. At this point, the copied elements change from the Layer they were on and become Layer 0.
It didn't use to do that (change Layer) - I must have changed some setting, but can't see what that might be. Any ideas?
Comments
-
I am also often surprised by such Layer changing behavior.
Also happens when I try to convert Meshes to Solids by
Explode>Region>Stich>Simplify.
You will need to take care about active Layer or you will ruin
your whole drawing quite easily ....Many Operations seem to throw Elements onto active Layer.
I just don't always know when and why ....0 -
No, this isn't about active layer - it must be a setting, which I didn't have set before - never seen this behaviour before. Can't even delete an element that comes in on Layer 0 - have to change Layer before deletion. Maybe will make a SR of it.
0 -
Got it,
they change after or because you close refedit.While I don’t get how you can paste objects out of a block
while in a block–edit mode ...0 -
It's not the new BEDIT, which seems less capable and useful than old REFEDIT, where the Block (or Xref) is edited in-place in the drawing and it's easy to copy bits of it into the rest of the drawing, then proceed as described above.
0 -
Can it be that you are working on an xref?
0 -
Ah - yes you're right Roy.
So is this because elements on Xref-dependent layers become 'Layer-less' when 'minused' out of the Xref, so they default to Layer 0?
That wd be a feature of using Xrefs rather than Blocks, that I hadn't appreciated. Damn.
The whole point is that the layer states of my Xref dependent layers are identical with ditto of corresponding layers in the drawing, so when using Blocks, elements were freely interchangeable btween Block and drawing.
Not so when using Xrefs instead of Blocks, it seems. Any way round this?0 -
Before using Refset to remove the copied object from the xref file, change its layer to one that's in the host file.
You might be able to automate that by creating a custom command, a sort of specialized version of the Refset command that first strips the object's layer property of the $0$ prefix and then executes the Refset command with the Remove option.
0 -
I don't get "change its layer to one that's in the host file".
Layer names in my Xref file are already identical to layer names in the host file. When queried within Refedit, they therefore already have to desired layer name - there's nothing to change.
But in Drawing Explorer>Layers in the host file, they appear prefixed with "Xref filename|".
It seems that such prefixed layer names are not available to elements which aren't part of that Xref, so those elements 'minused' out of the Xref are 'layer-less' and so default to Layer 0.0 -
@Tom Foster said:
... When queried within Refedit, they therefore already have the desired layer name - there's nothing to change. .....In my version 17, it works a little differently. All layer names from the xref file (as shown in the layers droplist) normally have the xref file's name as a prefix.
During a Refedit session, another set of layer names appears in the droplist, with the prefix $0$. If I select an object in the xref file, the $0$ layer name is the one that shows in the droplist box and in the properties bar.
If I copy something that's on $0$Plan, and then Refset-Remove it from the xref, and then close the Refedit session, that removed object is on layer 0.
But if I copy that same object and change its layer from $0$Plan to Plan before removing it, then the object stays on the Plan layer.
0 -
Using _RefSet on an xref dependent element will cause an error in V18. The element that is added to the current dwg actually becomes layerless. You have to use the _Audit command to fix this.
0 -
"During a Refedit session, another set of layer names appears in the droplist, with the prefix $0$2
Oh yes you're right - up there at the top."If I copy something that's on $0$Plan, and then Refset-Remove it from the xref, and then close the Refedit session, that removed object is on layer 0"
Yes that's it - doesn't happen when it's from a Block not an Xref.Roy says it's illegal to change $0$Plan to Plan before closing Refedit.
Anyway such changing whether before or after closing Refedit is much too laborious, destroys a well oiled workflow.So much for https://forum.bricsys.com/discussion/34558/convert-block-to-xref# - will go back to Blocks - the advantage of using Xrefs instead was marginal.
0 -
@Roy Klein Gebbinck said:
Using _RefSet on an xref dependent element will cause an error in V18. The element that is added to the current dwg actually becomes layerless. You have to use the _Audit command to fix this.Roy, is that a bug in v18? The online help for v19 says that Refset can be used with blocks or xrefs, just like in v17.
0 -
@Tom Foster said:
..... Anyway such changing whether before or after closing Refedit is much too laborious, destroys a well-oiled workflow. .....That's why I suggested a custom command. Instead of using the built-in Refset command, you'd use the custom command, called RefRemove or something. It would include the selection of the Remove option as well as the automatic layer name change, so it would actually be faster than the procedure you were hoping to use. I don't know for sure that it's possible, but it seems like the kind of thing that can be done pretty easily with Lisp.
0 -
That's helpful, but still requires multiple manual selections (or by some kind of filter procedure) of those elements on each one of the affected Layers, to change them to each desired layer.
To make seamless i.e. like with Blocks where no such thing happens at all, wd need a v clever custom command that would automatically change layername [xref filename]|X to levelname plain X, where such identical names exist.
0 -
The problem I have reported in my previous post occurs if the user does not change the layer of the element. I would call it a bug. Note that I use V18.2.20. This may have been fixed in V19, although I can't find an explicit mention in the Release Notes.
0 -
Just checked the issue in V17 (V17.2.12) and found the same bug there. Maybe @Anthony Apostolaros is using a different version.
0
