Xref binding, exploding block and defpoints layer is now visible but not available to select.

[atribo141141]

When I have binded my xrefs in a file, I have later exploded them to make edits.  Now the defpoints layer that I plan to reassign to a part geometry layer is not able to be selected at all.  What can be done to access this layer in this case?  Perhaps there is a better way to accomplish this goal, but this is how I have tried.  Thanks in advance for any help.

(My ultimate goal is to have xrefs in the file, but when I import file into a nesting software the xrefs don't transfer unless I bind them in the file first.  Once the xrefs are binded, I will still have to modify them, so I have been doing that binding in a copy of the file if that makes sense) 

[pendean]

>>>...My ultimate goal is to have xrefs in the file...<<<
Why did you explode the XREFs to make edits? You could just edit the source files and reload.
You should also have a second copy with bound xrefs there for the sole purpose of using with the other software, instead of destroying your source files for a short-term gain.

What's this other software?

[atribo141141]

I couldn't figure out how to get my xrefs to read in this nesting software, SigmaNEST.  I couldn't figure out how to control the xref source file after the xrefs were binded.  The binding seemed to sever that connection with the source.  I would certainly rather not have to do it in this way, I just didn't know how else to.

[Kent1Cooper · Accepted solution]

---

@atribo141141 wrote:

.... the defpoints layer .... is not able to be selected at all.  What can be done to access this layer in this case?  .... 

---

Thaw and turn on Layer "0".  When it's off or frozen, things on "DEFPOINTS" can't be selected, and only in limited conditions can Object-snap "see" them.

Better yet, don't use DEFPOINTS for this kind of purpose.  Make yourself a non-plotting Layer for those parts, which will not have the peculiarities that DEFPOINTS has.  You can find discussions of the why-nots with a Search of this Forum and the Customization Forum.

[atribo141141]

Could you please elaborate on the second copy of xrefs that I should have bound.  I am unclear how to do this in the way you seem to understand.  It would be most helpful if I didn't have to destroy the file each time I nest, so I create a copy of the file to use for nesting which I bind them.  Does it make a difference if I am doing the xrefs as an attachment or should I be doing overlay perhaps?  The path is relative, however I have noticed when I move the source file location it has issues reading it.  I am eager to reduce keystrokes of course and would love to know how to do this better.  Thank you

[pendean]

Your original top file (and it's XREFs) remain intact. Always. Any changes and edits you always do there. Always.

When you need to use the other software you BIND then SAVEAS to create a second file that exists solely and only to open in this other software. This last portion can be automated with LISP so it is a single action for you, not multiple actions.

HTH

[atribo141141]

Ok, this sounds like what I am currently doing, only I am doing the SAVEAS intentionally before I BIND them (thinking that is the purpose of the first file to be pure with the xrefs still editable.)  I think I am understanding this.

I am curious why when I will take an xref from one project folder and move it to a new one, when I use that xref in its new file location, it brings in both xrefs, the source one and the new one, but has one as unreferenced.  Then it won't let me detach or unload or purge or anything to remove the unreferenced one.  The saved path has something to do with this, but I am unclear how to change this.  With the xrefs changing per projects, I am copying them often to move to new folder locations.  Is there something I am missing with this process?  Thank you

[pendean]

It could be a sub-XREF (an xref inside your XREF): as a general rule you can only detach an XREF in the top file it is actually referenced into, not from any other file up the chain of references.

HTH

[atribo141141]

I see.  I will check this out.  This is helpful, thank you very much.