xref layers still show after detatching
After removing x-refs from a drawing, the layers continue to show up in the drop down menus and the drawing explorer. Using the "purge" "all" command sequence does not help either. Has anyone else experienced this? How can it be resolved? I am running v8.2.12. Thanks.
Comments
-
I often have that problem. It's not only that the xref's layers continue to show in the list of layers, but also that the xref itself continues to show in the list of xref's. What seems to be happening is that Bricscad doesn't recognize that the xref has been detached (but other programs do recognize it, and don't include the xref or its layers in their listings).If I try to detach one of these problem xref's in Drawing Explorer, nothing happens. The xref remains in the list. If I try to detach it using the old -Xref command, I just get this message:1 reference found for detach.0 references detacheded.I'm using v8.2.12, but this problem has persisted through several upgrades.I experimented a little just now: I opened one of the problem files in Bricscad v7. The xref showed as still being attached, and was easily detached in v7, and didn't show when the v7-saved file was re-opened in v8. So this is could be a workaround in some cases. But in the case of the other problem file I tried that with, v7 wouldn't open the file. It gave this error message as soon as I selected the filename (before clicking again or clicking on "Open"):Warning: Error was found during open. We recommend that you close this drawing and run DDRECOVER on this one.I can't replicate the problem in a file that I create. It only happens with files that I get from a consultant, but it happens both with xref's already attached and with new xref's that I attach. I assume it's because something is corrupted in the file when I receive it -- something that throws off Bricscad v8.
0 -
Anthony-What you describe is exactly what is happening to me. I do not have V7 any longer, so I can't simulate the workaround you have suggested. I will also mention that it is a problem in all files I work with, regardless of what version they were originally created in.
0 -
I have seen this also. In my case I attached the xref again then removed it and all was ok. I have not tried hard enough to see if there is anything repeatable so I have not sent in a support request on this.Greg
0 -
Oh yeah, I had to delete the insertion of the xref from the file prior to detach if my memory serves me well.Greg
0 -
Can someone please file a support request and attach a set of drawings that is known to trigger the problem, we will be glad to investigate and solve this issue.
0 -
Hello Hans,Already did, SR 16730Best Regards,Jose
0 -
Hello,While you fix this it might be a good idea to look into something else, when Bricscad displays refferences it is impossible to distinguish among master and and slave refferences which are pulled because they are nested in a master refference, it would be nice to have a means distinguish among master and slave refferences and even a way to have a check item where you can select to show only master or both master and slave refferences, kind of what you do with layers where you have a menu option that allows you to display only drawing layers or also layers from refferencesA really nice way to see this would be to have the master refference first and then every nested/slave refference indented a couple of characters depending on the level of nesting, one level=2 blank characters, 2 levels=4blank charactersBest Regards,Jose
0 -
Has there been any resolve to this issue? Hans- did you review the request mentioned earlier? Please let me know if I need to file an additional request.
0 -
I have the impression we are talking about some slightly different - though closely related - problems here.Some investigation learned that the Drawing Explorer does not update the layer grid after an xref is attached or detached.So if you detach an xref and then select 'Layers' in the 'Open Drawings' tree, the xref layers are still displayed, although in fact they are no longer there.If you close and reopen the Drawing Explorer, or select another drawing in the tree and then come back to the previous one, the layers are no longer displayed.We will provide a fix for this as soon as possible.Marc: This may explain part of your problem, but it does not explain why the layers still appear after the purge command. This I could not reproduce. Could you enter a support request with drawings that illustrates this issue?Anthony: Can you please forward us those files you mention, where xrefs still show in the list of xref's after they were detached? We would be happy to investigate this further.Jose: When you click the 'Tree view' button while viewing xrefs in the Drawing Explorer, the hierarchy of the xrefs will be shown in a tree.
0 -
I attached 2 such files to support request #17363.
0 -
Thank you Antony, I did'n know about that support request. I put it on my name and I will follow it up. This problem looks different from the others, in that the main problem here seems to be that the xref is still shown after detaching.In the other cases the xref no longer appears, but some layers stay behind.
0 -
Hello Stiene,Thanks for your response, the reason we found important in the past to be able to differentiate among master and slave references is when we need to delete references no longer needed that were inserted as a temporary drawing to obtain reference points, like drawing elevations using the plan to project lines. In the option you mention (I must confess that I had forgotten that it was there) which does a nice job of showing the hierarchy structure of references you can only select one item at a time, CTRL+Click does not work to select multiple master references simultaneously to delete, so, while I find that this option will simplify our deleting of unnecessary references it would be nicer if we could do multiple selections to delete several references at once. My example above seems trivial and it is, we have drawings that assemble 40 to 200 hectare projects where this drawing cleaning process gets to be a slow process
0 -
Stiene, I think that Marc, in his second post here, said that he's seeing exactly the same thing I am, which I took to mean the xref itself stays on the list in Explorer.But he said that he sees it in all files, not just certain files as in my case.
0 -
I also see the same problem Anthony described occasionally and have solved it in my case be attaching the xref file again and then deleting. I believe it is related to nesting in my case...
0 -
Just tried it and found that re-attaching and then detaching works for me, too. And it's much easier than the workaround I was using before. Thanks, Greg!
0 -
Jose: Allowing multiple selection in the tree view of the Drawing Explorer seems a good idea. I have changed the code accordingly.Concerning xref layers sometimes staying behind, and xrefs that were detached sometimes still showing up: we will investigate further when and why this happens.In the mean time, for getting rid of the layers, you can use the 'recover' command. After the drawing has been recovered, those layers have a prefix '$DDT_AUDIT_GENERATED', and can be deleted in a regular way.For getting rid of detached xrefs still showing up, the best work around is indeed what what Greg proposed: after reattaching the xref you can detach it properly.
0 -
Stiene Caestecker:I have filled SR 17609 and attached two files that represent what happens. Please let me know if you need additional information.
0 -
Both problems were indeed caused by the same reason:When you try to bind an xref that has unresolved nested xrefs (xrefs that are not found), the 'master' xref is bound, but the nested xrefs are not, they stay behind, and because they are nested, they cannot be renamed, detached... Also, since the unresolved xrefs were not detached, the layers of those nested xrefs are still shown in the layer explorer.We are currently working on a fix for this. Thank you all for providing drawings to illustrate the problem.
0 -
While you're working on the xref part, I would love to have a way to easily toggle xref states (overlay vs attach) like in Autocad. Sometimes people simply insert xrefs in the wrong state, and currently the only way to fix is to detach and reattach the drawing (loosing any finely tuned layer configurations of course).
0 -
Hello Asbjørn,The 'Type' field in the xref explorer has been changed to a toggle field: clicking the field changes the type from 'Attach' to 'Overlay' and vice versa. (For nested xrefs, toggling is disabled.)This change will be available in one of the upcoming releases.
0 -
Hello Stiene!
Is the problem with the detached xref-layers in the explorer solved in the meantime?
My version is 9.3.13 Build 16003.
I'm asking because layers of unattached Xref's are still shown in my explorer and can't remove them in no way.
Thanks.
0 -
Hello Markus,
A fix was added in order to prevent that layers stay behind after binding an xref, but drawings that were created with older versions might still contain such layers.
Did you try using the 'recover' or the 'audit' command to get rid of them? After the drawing has been recovered or audited, those layers have a prefix '$DDT_AUDIT_GENERATED', and can be deleted in a regular way.
We are planning to adapt the code so that such layers are purged silently on opening the drawing, but it's no high priority right now.
0 -
Thanks for answering.
The Audit command was good. After auditing the layers could be deleted.
Bye.
0