Doors VW12

[Gary C]

I'm trying to figure out the new door plug-in. I'm using VW12 and everytime I install a door it does not show the door itself just the frame. To have the door show up I need to make the class "Sill" visible. I don't want the door installed in this class how do I change?

[CipesDesign]

Gary, the new 'sills' class is written into the plug-in, and I don't think you can change it. The door itself is not in the sills class, just the door & swing (in plan view). This is actually quite useful for framing plans, and reflected ceiling plans, as it can be turned on or off. You can still place the entire door into any other class you choose, and while this can be used to change the visibility of the entire plug in, it will only affect attributes on parts other than the door or swing. In order to fine tune the look of your door, you need to go to door settings>view>special classes and/or line weights.

At first using the new door and window plug-ins might seem cumbersome (it sure did for me!), but for better or worse, you will get used to it. I now have the habit of creating one door or window with all the attributes/setting I want, and then duplicating it and simply changiing the size/config as needed.

[Gary C]

Peter,

Thanks for the quick response. I guess I can get used to it.

On another note, maybe you can help me out a little. see my post at: http://techboard.nemetschek.net/ubb/ultimatebb.php?ubb=get_topic;f=12;t=005500

I'm trying to setup VW to use my previous setting and come up with a office standard.

I design alot of additions so I use classes like Door-New, Door-Exist, Door-Demo, Wall-New, Wall-Demo etc... By doing this I can draw the existing condition then cut walls where windows will be removed and class them as Wall-Demo etc.. I'm looking for help getting the file setup so I can automatically insert the layers/classes I will need with the setup feature (File>Document Setting>Create Standard Viewports)

Does this sound logical or should I just keep a template with all the classes, layers, views, and viewports. This leaves alot of extra classes.

[Christiaan]

I think hard-coded class names for components of plugin objects is unintuitive. I'm guessing this is a situation whereby the coders priorities have had to take priority over the user. I haven't thought about it enough to offer a preferred and realistic approach (I'm sure there are bits of the puzzle I'm not taking into account) but ultimately I like to be able to call a class whatever I like. How this then links back to the component across different files with different names is up to the programmers but it's not something that I as a user should have to deal with ideally.

[quigley]

The big problem with hard coded classes is that if a company uses a class standard setup dropping plugins can inadvertantly add classes to the file. This is OK for experienced users but for most big installations (by which I mean 15-20+) most users come from a range of backgrounds and abilities and it causes confusion.

Personally I would like to see a new command called plug-in class map, where ANY VW plugin class can be mapped to a user class as an application (or template document) preference.

This would be a set once and forget task and would allow the developers to design and create new PIOs with a restricted class list that users KNOW will map correctly.

I don't think this would be that hard to do soon?

[Christiaan]

quote:

---

Originally posted by KQ:

Personally I would like to see a new command called plug-in class map, where ANY VW plugin class can be mapped to a user class as an application (or template document) preference.

---

Sounds like a good approach to me.

[Gary C]

Originally posted by KQ:

quote:

---

Originally posted by KQ:

Personally I would like to see a new command called plug-in class map, where ANY VW plugin class can be mapped to a user class as an application (or template document) preference.

---

This would make life alot easier

[blimey]

EXCELLENT IDEA. Should we post it in the wish list?

In the meantime, I read it is still possible to manually change the plugin's classes from the vectorscript editor. It represent a lot of work though. I might nevertheless doit for the most common plugins. Otherwise, I do back and forth standard naming...