Layer References overriding my Titleblock

[Wood]

I've referenced a document in that included a titleblock on a layer. This block's data has messed up my Titleblock manager, and it has overridden all of my border, sheet, project settings etc. 

 

Where are these file Formats hiding, and how do I replace them with my native versions? 

Super frustrating that settings from other documents get imported when I just want some geometry out of a file. Is there something wrong with my workflow?

 

This is the error I get when I try to import a good Titleblock border style. 

 

 

 

Thanks in advance.

 

 

[shorter]

Easy fix.

[Nikolay Zhelyazkov]

Hello @Wood,

 

The Title Block Project Data record contains document wide data but is attached to each title block border object. That is why you get this dialog when referencing a TBB and if you select to use the data from the active file you will not have the data from the referenced file.

 

Would it be a valid solution for you to just have this title block border saved as style in your favorites folder and then importing the style in your document, instead of referencing it? Then you will be able to merge the project data and not loose any data because of that.

 

Let me know if this helps.

 

Best Regards,

Nikolay Zhelyazkov 

[shorter]

With resopect, this is not a solution, @Nikolay Zhelyazkov

 

Referencing updates without thinking.  That's the whole point of it.

 

Merging is not reliable.

 

The solution is easy, IF you use referencing priority.  There are a couple of other 'rules' when you use referencing but there is a simple solution to this.

 

You can also avoid it altogether if you do not reference files containing titlesheets, or files that are referencing files containing titlesheets due to that 'unfortunate' WAD of proxy referencing where a resource does not even need to be placed in a file for it to become 'owned' by the proxy file.

[Wood]

11 hours ago, shorter said:

With resopect, this is not a solution, @Nikolay Zhelyazkov

 

Referencing updates without thinking.  That's the whole point of it.

 

Merging is not reliable.

 

The solution is easy, IF you use referencing priority.  There are a couple of other 'rules' when you use referencing but there is a simple solution to this.

 

You can also avoid it altogether if you do not reference files containing titlesheets, or files that are referencing files containing titlesheets due to that 'unfortunate' WAD of proxy referencing where a resource does not even need to be placed in a file for it to become 'owned' by the proxy file.

Steven, 

 

I reference complete VWX files with their own titleblocks very often, as I work with multiple departments in multiple companies. Referencing is the simplest way to push their updated revisions into my drawing, as well as not risk modifying their geometry accidentally. 

 

Your advice to use reference priority was right on the money! Can you share your other 'rules' for referencing? I feel like the VW guide is lacking here. This is the first I've ever used Ref priority, but I can already see its value. 

 

 

For those following along and wanting to solve the problem yourself:

I reference in base symbols instead of importing, and that included my titleblocks. That way, if I revise a symbol, it's fixed for all of my other projects. 

In this instance, my symbol file had a lower reference priority than another team's file that I referenced as well, so it's titleblock superseded mine. 

 

It was a very simple fix to enable reference priority in the reference settings, and then drag the references into the correct hierarchy. 

 

Thanks again Steven

[shorter]

Well, one rule we are insistent on and always careful about when we configure a Vectorworks system for our clients, is 'No Text Styles in Referenced Titlesheets'.

 

You have to be careful with resources generally when referencing, particularly resources that aren't yours or worse, your resources on a round-trip.

 

So when we talk about rules, it is all about how you manage data, what your segregation strategy is, what the project requirements are, how big the team is, how complex the project is, what sort of data you are being asked to work with, and what you need to deliver.

 

It is very easy to over-think things.

[shorter]

I should also add that we have written the definitive guide to referencing.  It details the pros and cons, the whys and wherefores, explains how and why it is such an efficient methodology for team-working and includes scenarios and guidance on setting up Vectorworks correctly within a referenced environment because it is NOT as simply as just linking two files together.

 

It is not for everyone, and we accept that, but anyone coming from or used to AutoCAD or Microstation will find our system a breath of fresh air, or as one of my clients said our support was "...like a glass of iced water in a parched digital desert; always refreshing & reinvigorating".