Christiaan

Thanks Robert, I've ended up resolving the problem by simply stripping out any old stairs and starting again with the new stairs from the v12.5.2 Library.

Here's the other thread Pete refers to, which discusses what is essentially ArchiCAD's master-satellite synchronisation capability: http://techboard.nemetschek.net/ubbthreads/ubbthreads.php?ubb=showflat&Number=74599 This may be of interest too: http://www.stress-free.co.nz/following_up_on_cad_collaboration

For instance, what's the difference between these two files, apart from the fact that someone has taken the imperial version and changed the document units from inches to millimetres? Libraries>Objects-Imperial>14_Stairs.mcd Libraries>Objects-Metric>24_Stairs.mcd Better yet. the default stairs are also imperial: Defaults>Stairs>14_Stairs Imperial.mcd Why don't metric users get default stairs that are sensible metric dimensions, such as 3000mm floor-floor, 250mm max going, 170mm max risers, 900mm wide, etc.? Why do we get lumped with imperial objects?

We have a "universal" Layer which we use to put keys/legends on. So we'd have one Viewport with two Design Layers in it.

Thanks Robert, will this fix stairs that are not placed in the drawing? (i.e. only in the Resource Browser)?

As DWorks suggests, put your keys on a Design Layer and use Viewports.

Given that we tend to deal in brick dimensions in the UK the opening is just what it is. The standard tolerance here is 10mm.

Regardless islandmon, we dimension to structural/rough openings, not door (or window sizes).

Yeah it's our template, so it was created before 12.5.2. Where do I find the Fix Stair Associations script?

Actually it doesn't appear to be consistent. I have another stair that behaves the same way whether you duplicate from the lower or upper level.

I've found that if you duplicate while viewing the upper level of a (PIO) Stair and then move it, it will then move the lower level of the original stair. It seems to work okay if you duplicate the lower level. I'm still experimenting, but do others have this problem?

- Rebated door jambs - Ability to show rough opening (i.e. move loci to suit frame+shim gap), so we can dimension the opening instead of the door frame. -Ability to show ironmongery and trim in plan on Guide class to facilitate correct placement of doors, or something similar. -Ability to show potential wall returns (finished), again to facilitate correct placement of doors. See attached example.

As I alluded to, the problem I have with 'None' stems mostly from showing others how to use VW rather than my own use.

I can understand if people are going to argue that "None" should stay because it's the status quo and they're used to it. I'd argue against this but it's quite a valid argument. What surprises me, however, is that people are arguing that "None" is semantically better than "General". Anyway, I'm gonna have to agree to disagree with you all, buy out NAG and order the change from the top down.

Presumably you meant to comment on a different thread Mike?

I find it's more than that. I find it's often something to explain to new users, whereas "general" wouldn't need explaining. Clearly I'm outnumbered though! As always Mike, you excel at missing my point, which was about default usability, not whether or not you can customise it or not.

DWorks, this wish is to specifically do away with the need to have a "General" Class.

File doesn't need to be closed anymore. See: http://download2.nemetschek.net/www_misc/VW12.5_WhatsNew.pdf

I'd submit that you're simply used to it. Give this software to somebody new (and with a reasonable grip of the English language) and generally they'll tell you it's unintuitive to have an object in a Class called "none class". 3 more characters in "general". I can see VectorWorks falling apart at the seams already! Some of my suggestions on this forum don't come from my own experience with VW but with teaching others how to use it. People can hold onto the antiquated "none" Class if that makes them comfortable but I think it's to the detriment of VectorWorks if such things remain for the sole reason that the user-base is used to them. I meant selectable sub-group headings can't be implemented with Standard Naming: http://techboard.nemetschek.net/ubbthreads/ubbthreads.php?ubb=showflat&Number=67740

I think this is probably what you're after Furr: http://techboard.nemetschek.net/ubbthreads/ubbthreads.php?ubb=showflat&Number=64934 Unfortunately it's just a wish at the moment, so doesn't exist.

Being a rapid socialist I was thinking more about other people buying the software for the first time. Why should they be faced with a Class called 'None' when there's no such thing? The answer is because someone who doesn't have a very good grasp of the English language made the decision at some point and nobody at NNA has ever bothered to change it. In any case Standard Naming won't deal with the second request I mentioned.

This just creates another top level Class DWorks. What I'm after is described in the attached image:

I'd like to see "None" Class (which is an unintuitive) changed to "General." And also Classes such as "Ceiling-main" changed to "Ceiling-General", or even better, implement this instead (selectable sub-group headings): http://techboard.nemetschek.net/ubbthreads/ubbthreads.php?ubb=showflat&Number=67740

I like these too: http://www.nemetschek.net/training/trainingcd.php And this is a very good free resource: http://www.nemetschek.net/training/library.php

VectorWorks>Templates (which includes a template that holds most of our resources) VectorWorks>Libraries>Defaults>Walls>Wall Styles Metric.mcd VectorWorks>Libraries>Defaults>Attributes - Hatches>Hatches_Default.mcd And Library>Application Support>VectorWorks>12>Plug-ins>Toggle Guides.vsm Library>Application Support>VectorWorks>12>Plug-ins>Toggle Objects in Group.vsm Library>Application Support>VectorWorks>12>Plug-ins>Toggle Viewport Crop.vsm Library>Application Support>VectorWorks>12>Plug-ins>Toggle Zoom Line Thickness.vsm Which I add to both the document and object contextual menus.