Can I change the name of "style#"?

[Christiaan]

When using styles to control plugin objects can I change these to descriptive names, instead of "style#"? I tried just changing the class name but it wouldn't show up in the object info palette. All styles were still called "Style#".

[Jonathan Pickup]

the Style# name is hard coded into the plugin, so you can?t change it...

[mike m oz]

This annoying unfriendly programmer's logic issue absolutely must be addressed for the next release.

[ 07-01-2005, 11:16 PM: Message edited by: mike m oz ]

[islandmon]

The whole friggin' Plug-in Class Style# really sucks ... sucks sucks sucks ... it is both a hindrance and a nusance.... arrrrgh.

Give me real Tool modules with real useable realtime GUI and the ability to define class style names as 'string'.

Click on the tool and the module pops up to allow creation of the object ... viewable in a separate window ...realtime.

[mike m oz]

Well said mate!

I couldn't agree more.

[ 07-02-2005, 10:14 AM: Message edited by: mike m oz ]

[Travis]

Actually, you can modify the PIO styles. Please note Petri's response in this thread.

http://techboard.nemetschek.net/ubb/ultimatebb.php?ubb=get_topic;f=12;t=004198

We've taken his advise and created the list in a Word document. Then whenever VW updates, we just run the Plug-in Editor and update the style names.

It's not quite as "intuitive" as Armstrong's wish, but it I believe it maintains better control in a multi-seat situation.

Good luck,

[mike m oz]

Travis - you can but you shouldn't have to. Where you have it together enough to be able to do this most users do not.

To my mind the protocol of using Style-1, Style-2 etc. is just lazy programming.

It does not help the user which surely should be one of the main objectives of the programmers. They need to keep this in mind and do away with this nonsense.

[Travis]

OK, I'd agree to a preferences option (or something similar) that would allow the user to create style classes on the fly, but I reiterate how valuable having control in a multi-seat situation is.

Using the above approach saves a bucket-full of confusion. Whenever someone inserts a stair (or rail, or window, etc.), they simply add the appropriate class from the Standards file. Then one might modify the class for that particular drawing, but we don't allow users to create new classes without approval.

Hard to satisfy everyone, as usual. At the very least, it seems that NNA might do a little better job teaching users how to modify the style\classes.

[mike m oz]

If the built in pop-up classes had sensible names that meant something this wouldn't be an issue.

For example: Stair-Stringer 1, Stair-Stringer 2, etc.

Every license would have the same options so people wouldn't have to make their own classes, and you would still have a controlled system.

A little more thought from the programmers would pay huge dividends in user friendliness.

[Travis]

I agree. And it would be so very simple for them to come that way already.

Good point.

[Christiaan]

Is this overcome in Vectorworks 12? I couldn't find a demonstration of the window tool in VW 12.

[Dietmar Lorenz]

I'd be hesitant adding even more classes but would find it extremely helpful to be able to annotate class names (e.g. style-8 [set invisible in MEP plans] or style-5 [perforated metal texture]) to make it more transparent how they get used in a specific project. The annotation should be a separate field, so no new class is created by renaming it.

I can see the reason of style-# classes being versatility, as a "style" represents graphic attributes rather than a specific element of a design. A door swing and a window sill might share the same class for that matter, unless you want to be able to set the one invisible in specific sheet setups but not the other.

Obviously this is a controversial subject, and everybody has different priorities and preferences. It seems there needs to be a good trade-off between minimalist restriction and lavish class creation.

Dietmar

VW11.5 on PC

[Christiaan]

Dietmar, if you look through all the posts above, and even the substance of your own, I'm sure you could agree that there's no controversy at all. In fact these seems to be quite a strong consensus as far as I can tell.

[Dietmar Lorenz]

Christiaan, I can see a consensus in giving the user the ability to rename classes and make those appear in the plug-in menue more easily. I'm not sure if "more meaningful" class names could be agreed upon that easily. That's why I was suggesting an "annotation" to the (limited) number of classes that appear in those pull-downs. In general, I prefer less classes in the program default, not more.

Dietmar

VW11.5 on PC