JanezicDesign

Yup, again not that big of a deal, but if I were to add another layer into the source file it'd be nice to have the ability to just reference all design layers and have that update everything from that source the way the DLVP does, with the added ability to individually toggle visibility in those layers. But not a make or break, this solution is hands down the way to go for what I'm doing. Wish I had asked this before I did have the venues I'm working on! Thank you!

It's great that you teach both. Without the ability to control visibilities per viewport with the DLVP approach, I prefer the DL reference approach. The ONLY thing I am having any sort of annoyance with is the idea of template files. Updating the reference to a new file when using the DLVP approach puts all referenced DLs in the DLVP in the proper stacking order. Not a huge deal, but if I update the reference to a new file then any additional DLs not in the new file will be put to the bottom of the stacking order after I check them off. They both have their pros and cons as you said. I wonder if those pros and cons could be combined to make for one approach to referencing DLs and/or VPs. Again, thank you for pointing me in that direction! It's definitely doing what I was wanting now after updating the stacking orders of newly imported/referenced DLs.

Yes, and as @C. Andrew Dunning put it, the "old-style" design layer referencing option DOES fix part of this issue and serves as a workaround to the design layer viewport reference. Having it streamlined to be more direct seems possible in concept though, and I think would make for a better workflow when it comes to simply being able to have one file for geometry and a single set of plates, while another can reference it and make a new set of plates in new sizes with sheet/page counts that don't add them all together. Multiple solutions to that specific need, but this referencing suggestion was my first go at it since it's how I'm working with it at the moment.

I see it now in settings! Thank you for making me check this again. I like the Design Layer Viewport approach, except for the ability to control design layer visibility from the source file. The purpose of my referencing is to make multiple sheet layers of different sizes and have the page counts be individual, which another solution to this; packages of sheet layers to count independently from one another so you can have Arch D plates counting 1-4 in the source file lets say, and letter size sheets counting 1-10 after splitting up across more sheets. All in all, the design layer reference via the organization references settings is another solution I missed. Maybe because it's considered "old-style", but is a solution to this nonetheless. Thank you again!

I must be missing something then, as I have only seen and read about importing design layers, and referencing them means doing so in a design layer viewport, not referencing the design layers directly. Is there another way to reference design layers directly so that when the geometry changes in the source file it updates in the active file? From what I gathered, it was only possible in a design layer viewport referencing a source file.

Hello! Working with referencing viewports and am frustrated by something. So wanted to put a feature request, and also ask for a reason as to why Vectorworks acts like this. The Request: Simple; I'd love to see the ability to reference viewports directly from another file, OR reference the geometry (like we do now in a design layer viewport) while being able to control the visibilities in the sheet layer viewports individually. At the moment, the process of viewport referencing is: Create a new viewport ( View > Create New Viewport... ) Designate the viewport to a design layer (i.e. Design Layer-1 ) Set the source to be another file Select all design layers in the file you want in the viewport EITHER: Copy a viewport from the file you are referencing OR Create new sheet layer viewports from the reference design layer viewport Make the one design layer with the design layer viewport in it visible to see the architecture being referenced The Problem: If you want to hide any design layers from the referenced file you need to show/hide/gray them in the design layer viewport, meaning if you want different visibilities in other sheet layer viewports you need to: Create a separate design layer with that same referenced viewport in it Show/hide/gray each referenced design layer in each design layer viewport Show/hide/gray the active file design layers (the ones holding the design layer viewports in the active file) in each sheet layer viewport That's the request, either managing the referenced design layers from each sheet layer viewport directly or referencing viewports directly from another file. My question is: What's the point of the current workflow? Why would it make more sense to have this seemingly roundabout way of achieving this vs a more direct link with more management of the visibilities? Genuinely curious as to the thought process behind this decision and why we haven't see this evolve to be more flexible within viewports in a file referencing another. Thanks for any support or input!

If it's not possible (which it doesn't seem to be when I tried), it would be so useful to have records attached to line types, so a text block can take on the field contents along a path. Additionally, being able to export data of objects (say the perimeter of a polygon or polyline) with the records attached and the field contents would be really useful for a lot of applications I would think. In this case I'm using it for cabling, which I know the cable tool but trying to make it simple for others to use who don't know those tool sets. Thinking about irrigation, or specific pipes, things that may not be in vectorworks and want a visual label, custom color, and multiple field inputs while remaining on one class and using the same line type seems really useful in a lot of ways without adding more and more tools and tool sets. Thoughts on this idea and the applications you may see it useful for?