Clean-up tool for BOUND>BOUND drawings

[Wish List System]

Summary: Tool that searches the database and uses all definitions that match local (non-bound) definitions to overwrite bound]bound database entries.

Description: When users use the Bind XREF option to Bind instead of Insert the XREF, all data related to block, layer, or style names becomes unusable to programs that may rely on naming conventions to read data for automated processing. Once a drawing is bound rather than inserted through the bind command the data in the resulting drawing is almost impossible to clean up with automation many times, and sometimes it is nearly impossible to clean up using custom tools.

While there are cases when the XREF data needs to be kept independent of other referenced drawing objects, this option is chosen (often in ignorance of the consequences) and drawings with important data renamed are accepted by unknowing personnel before there is a chance to get the individual drawings or the drawings bound using insertion.

In these cases it would be helpful to have a tool that would allow automatic association of a bound object to assume the definition of a matching native object in the drawing database if one can be found, and if not, the tool would be able to strip off the drawing prefixes of objects that are unique to the old XREF's. This would in effect, undo the mess created by using the Bind]Bind method of XREF binding.


Product and Feature: AutoCAD - Database

Submitted By: RapidCAD on 10/24/2022

[Wish List System]

Clean-up tool for BOUND>BOUND drawings

Summary: Tool that searches the database and uses all definitions that match local (non-bound) definitions to overwrite bound>bound database entries.

Description: When users use the Bind XREF option to Bind instead of Insert the XREF, all data related to block, layer, or style names becomes unusable to programs that may rely on naming conventions to read data for automated processing. Once a drawing is bound rather than inserted through the bind command the data in the resulting drawing is almost impossible to clean up with automation many times, and sometimes it is nearly impossible to clean up using custom tools.
Example: P1000-P1300 SERIES$0$Bldg_XRef4$0$0202$0$5100-CONV-BELT
Example: P1000-P1300 SERIES$0$Bldg_XRef4$0$2022-01-24-PROJECT HANK UPDATED WAREHOUSE LAYOUT-PROVIDED CAD_dwg_0202$0$ATTACHMENT_POINT-8846205-OVERALL FLOOR PLAN TEST FIT

While there are cases when the XREF data needs to be kept independent of other referenced drawing objects, this option is chosen (often in ignorance of the consequences) and drawings with important data renamed are accepted by unknowing personnel before there is a chance to get the individual drawings or the drawings bound using insertion.

In these cases it would be helpful to have a tool that would allow automatic association of a bound object to assume the definition of a matching native object in the drawing database if one can be found, and if not, the tool would be able to strip off the drawing prefixes of objects that are unique to the old XREF's. This would in effect, undo the mess created by using the Bind]Bind method of XREF binding.


Product and Feature: AutoCAD - Database

Submitted By: RapidCAD on 10/24/2022

[Wish List System]

Clean-up tool for BOUND>BOUND drawings

Summary: Tool that searches the database and uses all definitions that match local (non-bound) definitions to overwrite bound]bound database entries.

Description: When users use the Bind XREF option to Bind instead of Insert the XREF, all data related to block, layer, or style names becomes unusable to programs that may rely on naming conventions to read data for automated processing. Once a drawing is bound rather than inserted through the bind command the data in the resulting drawing is almost impossible to clean up with automation many times, and sometimes it is nearly impossible to clean up using custom tools.
Example: P1000-P1300 SERIES$0$Bldg_XRef4$0$0202$0$5100-CONV-BELT
Example: P1000-P1300 SERIES$0$Bldg_XRef4$0$2022-01-24-PROJECT HANK UPDATED WAREHOUSE LAYOUT-PROVIDED CAD_dwg_0202$0$ATTACHMENT_POINT-8846205-OVERALL FLOOR PLAN TEST FIT

While there are cases when the XREF data needs to be kept independent of other referenced drawing objects, this option is chosen (often in ignorance of the consequences) and drawings with important data renamed are accepted by unknowing personnel before there is a chance to get the individual drawings or the drawings bound using insertion.

In these cases it would be helpful to have a tool that would allow automatic association of a bound object to assume the definition of a matching native object in the drawing database if one can be found, and if not, the tool would be able to strip off the drawing prefixes of objects that are unique to the old XREF's. This would in effect, undo the mess created by using the Bind]Bind method of XREF binding.


Product and Feature: AutoCAD - Database

Submitted By: RapidCAD on 10/24/2022

[Tom Beauford]

Cannot comprehend what you mean by "automatic association of a bound object to assume the definition of a matching native object in the drawing database". If an object had all the same properties on a bound layer as another object on a normal layer why would you need both objects?
Why not just delete all the bound layers and xref the drawing in properly?

[RapidCAD]

Thank you for your question Tom. I should have clarified what I meant when I said "a tool that would allow automatic association of a bound object to assume the definition of a matching native object": A tool that would allow by the same list found in the PURGE command, each type of data - to look to see if the object with the same name of a bound object exists, and if so, it replaces the definition of it with the non-bound definition and removes the bound definition.

Layer names are only one example and they really are not the sticking point for us (although they are often a mess to navigate). We rely on dynamic block names and dynamic properties in our layout drawings in order to read the intent of the designer by parsing the block properties and for order processing. When block names are bound they are no longer usable to our programs that read those blocks and parse their properties -whether for adding on blocks representing accessories or order processing. Of course the other renamed objects are not deal killers but they do make the entire drawing a lot more difficult to navigate.

I understand why Bound>Bound exists - it has a purpose when objects are named the same but have different definitions (layers are the prime example of this) but blocks and styles are not typically different between our referenced drawings. Our drawings, hosting hundreds and sometimes thousands of dynamic blocks are already huge sometimes 40-100Mb, so adding 2 or more times the number of definitions of everything in the database is a bloat not easily fixed and very painful to live with. We do our best to warn the uninitiated to not accept drawings in this condition but some of our personnel in non-CAD roles really don't know much about CAD and file them with our jobs.