Christiaan

Ahh, I mistakenly thought this script would generate all the classes!

Yes, we have added an A for architect prefix to our Classes, which achieves the same result.

I don't see why Style parameters need to be edited by entering the Style dialogue windows. Why can't we edit them directly in the model? Currently, for example, if somebody picks up the Texture Tool and tries to apply a new texture to a window frame which is controlled by Style, they get an error saying they can't edit it because it's controlled by Style. But why? Why not this instead: they apply the texture and are presented with a message that it's controlled by Style and would like to go ahead and update the Style, and would they like to do this every time they try to edit a Styled parameter during the current session. They click Yes and, boom, all the Style and all the relevant window textures are updated. Same thing, say, with a door/window schedule Worksheet. Worksheets only work two ways with unstyled parameters. I don't see why.

Awesome, thanks Steven. It's kind of awful that there is a mixture of hierarchy and different ways of referring to components (e.g. Site-Hardscape Comp-Main vs Component-Hardscape Joint, comp vs component). I imagine there are a lot of practices out there who would be far better organised if the default Classes weren't such a mess!

Brilliant, thanks Peter, I'll give that a shot.

Hi Peter, no I mean all the Classes that would be brought into a file when using various tools and adding library content to a file. Basically, an extended version of the VW Arch template. Or does VW Arch contain all such Classes?

Is there a Class template file available anyway—or any way of generating one easily—that has all the Classes that come in with Vectorworks Architect and Landscape objects?

Except that it doesn't, and I'm pretty sure that's what the original complaint is. Editing a symbol via the Resource Browser uses whatever view you have active, including rotated views.

Thanks for identifying that one. I've added it to my list of problems when working in Rotated Top/Plan:

I'm collating a list of problems with rotated view here @Hugh Chapman https://forum.vectorworks.net/index.php?/topic/129461-rotated-topplan-niggles/

Too transient; too many ways to end up back in an unrotated view.

I think this would be helped if we had a more permanent rotated view option too.

Does changing the accuracy in VW make any difference?

I've been working in Rotated Plan View exclusively for all projects for few years now, and it works great, but there're still quite a few workflow niggles that need to be ironed out to make it perfect, so I'm collating a list. Please suggest any I've missed. Many workflows will unrotate the view: e.g. editing a Roof Face, editing a Site Modifier polyline, editing a Slab modifiers, editing a Space modifier, editing an image crop, editing a PDF crop, etc. When creating Interior Elevations the viewports can be distributed badly, off the page/sheet Dimensions can sit on the wrong side of the dimension line and be upside down in a working view. If you're in a rotated view and edit a symbol from the Resource Browser, it too displays in a rotated view, which isn't necessarily desirable. Too often the rotated view is lost through a series of navigation steps. I think it would be great if we could have something a little more permanent. Perhaps a Document setting that sets the Rotated View as the default view, with a lot more hoops to jump through to reset to an unrotated view.

One of the many little niggles of working in rotated plan views. I've been meaning to submit a bug report about this, but I suspect it's known already.