Particular

I managed to solve my own query. The reason the visualizations aren't applying is that the referenced classes are not 'in' the file. The trick is to adjust the Viewport Class Properties, and toggle it to "Use viewport-specific class definition". Now the Classes are filtered by the data-visualization, and everything works. change this: to this:

I have a some data-visualizations I typically apply in viewports to differentiate things like which parts of the plan will be demolished. When I reference the plan to another file, and apply the identical visualization it does not work. It in fact does not identify the drawing items in the referenced plan. I'm not sure if this is a bug, or if I am failing to tick a box somewhere. Any ideas? Thanks! These are the criteria applied to the viewport in the base file, and the result in the sheet layer viewport. These are the criteria applied to the viewport with a referenced plan in another file. There are no objects that meet the criteria, and no visualization is applied.

Ok, so the situation is worse than I anticipated. I have now edited a new ClassNameStds worksheet. If I now drag this onto another file that does not have a standard naming worksheet, all the custom settings I have edited are reset to arbitrary values (not even similar to one of the existing standards). This behavior is exhibited in new as well as old files. In the standards file that I did the editing in, the Standard Naming command works correctly. I'm not sure what is going on here.

Hi, I'm setting up an office standard using Standard Naming. The reason I am choosing to use this as opposed to using a template file with common classes and resources is that I want to bring old project files up to date with my new standard. I also anticipate tweaking the standard and like being able to force any changes across multiple projects. I have edited the ClassNameStds worksheet to add new names and I'm editing the attributes in the Standard Naming Dialog. So far so good. The attributes I can set in Standard Naming are Line, Line Weight, Line type. Fill can be set to only None, Fill, and Pattern but not Hatch. Since I do use hatches, I could apply the standard, and then manually add hatches to certain classes. If I apply the Standard again though, it wipes out the hatches I have set. It does this regardless of whether I tick the 'Use at creation' box. Is there a way to use Standard Naming and still have hatches applied to some classes? Thanks!

I would just like to remind NNA of the desire to have Design Layer Section Viewports. They would be a great help in detailing, but also great under-layers for interior elevations. It is just faster drafting in design layers than in annotation layers. Having live updating is really useful. It makes it easy for someone less familiar with the whole project (like an interior designer) to focus on the elevations, and quickly see the consequences of larger changes. One more thing; Currently snapping in section viewports is only on the section parts, but not on lines in the background. It would be very useful for this to be a toggle in the object info pallet.

What is nice about the Design Layer Viewports is that there is a checkbox in the object info pallet to control it. It would be great if this checkbox was ubiquitous in object info. I think Lock and Unlock are rarely used in VW because it is too cumbersome to keep going to the menu. The Design layer Viewport is different however in that it locks position, but allows editing, while the regular lock is a total freeze. This is a little confusing.

Some improvement ideas: -Link up to Google Earth for location data. This could be done with a command similar to 'Get Current View' in SketchUp. This would be easier than copy/pasting latitude and longitude. -Option to name the light object with date and time automatically, in stead of naming manually -Add a command to create multiple sun objects at specified dates, and time intervals.This would make doing solar studies a lot easier. -Edit the sun position (date and time) in the object info pallet rather than having to create a new light object and delete the old one.

I agree, but it is trickier than it seems. A Left Hand swing is the same as a Right Hand Return swing when entering the room from the other side. To have this work properly, there needs to be a way to indicate which side is 'outside' and which is 'inside'. The LH, RH, LHR, RHR indication is often used to specify which side needs to get the lock in situations where it is not obvious.

I agree. I recently reworked a landscape plan imported from acad. The plan had lots of tree blocks (now symbols) which I replaced with VW trees. In addition I created a 3d symbol in the shape of a low planter box, which placed in the same origin using the replace symbol command. The result was 100 trees growing out of the edge of their planter box. In the end I deleted the boxes and had the trees growing out of the tarmac instead. Not ideal.