Jump to content
  • 0

By class setting of symbols to update according to new assigned class


Art V

Question

AutoCAD symbols generated on layer 0 and set to use bylayer etc. as property will always take on the assigned layer properties and change accordingly when you assign the symbol to a new layer.

Vectorworks is a bit more limited in this aspect and I would like it to replicate this behaviour in AutoCAD that when I create a symbol that it is possible to set it such that it will always take the properties of the class it is residing in when an attribute is set to by class.

Currently it seems that it can either take class properties upon insertion into a class or as class properties by the class assigned in the symbol upon creation but when a symbol is reassigned to a different class the old class properties stick and do not take the properties of the newly assigned class unless I update the symbol itself.

Especially when you have the same symbol used in multiple classes and want to able to differentiate them by e.g. line colour of the class it is annoying to have to create multiple instances of the same symbol to solve this.

Edited by Art V
  • Like 1
Link to comment

19 answers to this question

Recommended Posts

  • 0

This seems to be a wish for one or more instances of a symbol to have unique attributes. eg the "Master" symbol will have blue lines and one or more "unique" instances will have red lines.

Not so sure. Looking for proposals here.

I agree that unique symbol instances (eg different line color) often seem desirable. But they present dilemmas and may reduce work flow efficiency. Symbols are efficient because of ability to adjust attributes and other properties globally. If unique instances are formed, how are future global changes managed?

For a symbol in Class A with all contained components also in Class A, the problem is not so great.

•Present a dialog to accept/reject "Global" changes in unique instances.

•But if there are many instances of many different uniques (red lines, blue, green, orange, etc), how will author track/remember which of the uniques need protection from the global changes?

•All instances may not be visible when the global change is made.

•Reasons for protection of a particular unique may be known by one author but not known by others working on the file.

For a symbol in Class A with many nested symbols and other multiple components assigned multiple classes, global change management of the unique "master" symbol and/or of any unique contained symbols becomes more challenging.

•Accept/reject pop up with indented outline of classes/attributes of all components of every object and nested symbol? Might be OK if file contains only a few uniques or contained uniques.

• But what happens during global change for a master symbol (including its unique instances) containing many unique and standard nested symbols and objects including many classes?

•Do we see a separate accept/reject dialog for each contained unique? A class list of every object in every symbol?

•We need a way to track/remember which instance(s) benefit from the changes.

•Multiple authors also need info about what is unique and why, and what not to change.

Something similar to VP overrides might work, but it gets convoluted during design changes if file contains lots of master uniques and lots of nested uniques. eg I might goof up, wait a couple hours for a render, then have to redo.

A color code for Resource Browser icons to indicate that unique instances of a symbol are present in the drawing would help (but not all uniques are same), and a way to cycle through and examine each instance in the drawing. Or do the uniques show up as separate icons in the RB?

OK lots to figure out.

-B

Edited by Benson Shaw
Link to comment
  • 0

I think instead of approaching it from the symbol level, it could be approached via the objects within the symbol definition. Objects within a symbol should have an additional attribute option: "By Symbol".

It would be similar to "By Class" but would take on whatever attributes the symbol instance is set to. Symbol instances could then be given different pen colors, for example. A symbol instance could even be set to "By Class", thereby making everything inside the Symbol listen to the class settings of the Symbol Instance. But it's all set via the objects themselves.

Does that make sense?

Link to comment
  • 0

By Symbol is a really cool idea. Needs some refinement.

•What happens to nested symbols? The new class of a contained instance could force that change on all other instances of that symbol.

•Some kind of disconnect would be needed to protect un nested instances from the new class.

•What is shown in the OIP and the RB? If class of an instance is changed to force new attributes to contained objects, does the instance name in the RB & OIP get a suffix or other identifier?

•The instance in the drawing should offer feedback that it is not original equipment eg different highlight color? or reshape handle color?.

By Symbol only solves part of the problem. Global change options will still be tricky if there are many "By Symbol" instances, especially if deeply nested symbols are contained. Attribute control is one aspect, but geometry changes, eg swap out nested symbols or add objects to the Master Symbol, could cause headaches to the altered By Symbol instances.

As Art V points out the current method is duplicate symbols with varying properties/objects and a naming scheme to differentiate them in the RB:

•Symbol1_RedClass_0Texture

•Symbol1_BlueClass_Brick

•Symbol1_NoneClass_Wood

To me, this old school approach is worth the effort. The naming scheme offers perfect tracking (I know what each one is on drawing, OIP and RB), and perfect global change control. Down sides include need for careful naming and longer symbol list in RB. But those downsides may also be necessary with a By Symbol scheme, too.

-B

Link to comment
  • 0
This seems to be a wish for one or more instances of a symbol to have unique attributes. eg the "Master" symbol will have blue lines and one or more "unique" instances will have red lines.

-B

Actually that is not what I am asking for. The symbol objects should not have attributes defined at all when set to "by class". The attribute properties should be controlled by the class properties on which the symbol is residing if the attribute is set to "by class".

The problem is caused by objects being assigned to a class, which by itself is ok. However, if the object is not part of a symbol and its attributes are set to by class and the class is changed then the appearance of the objects changes to the class settings of the newly assigned class.

Once objects are part of a symbol this no longer happens, while I want this to happen even if the objects are part of a symbol.

This request basically applies to symbols where all objects are within the same class and one, more or all attributes are set to "by class". The objects themselves should ideally not have a class attached to them at all so that the class in which the object is residing controls the "by class" attributes appearance.

I hope this is more clear. If not I'll create some examples.

Edited by Art V
Link to comment
  • 0
I think instead of approaching it from the symbol level, it could be approached via the objects within the symbol definition. Objects within a symbol should have an additional attribute option: "By Symbol".

It would be similar to "By Class" but would take on whatever attributes the symbol instance is set to. Symbol instances could then be given different pen colors, for example. A symbol instance could even be set to "By Class", thereby making everything inside the Symbol listen to the class settings of the Symbol Instance. But it's all set via the objects themselves.

Does that make sense?

Yes it does, and to some extent it is largely similar to what I was asking for, but it is also a bit more complex than I am asking for though it may have its uses.

Link to comment
  • 0
+1

-1

Did not really read what was demanded.

I meant,

if a class is set to use class settings,

assigning Objects into that class should be forced to take the class settings by default.

Maybe a warning/option that says :

Of 125 objects you want to assign to class "XXXX",

there are 23 objects with local assignments,

Do you really want to assign class attributes to these too ?

YES - CONVERT ALL TO BY CLASS

NO - KEEP LOCAL ASSIGNMENTS

Link to comment
  • 0

Its an interesting idea. Couldn't it be as simple as a checkbox in the OIP for symbols that says "Symbol class overrides contained object classes" and a symbol insertion option that turns this on by default when inserting symbols if you want it?

There are some more complicated ways to implement this concept but class management can already have its challenges in complex files.

KM

Link to comment
  • 0
Once objects are part of a symbol this no longer happens, while I want this to happen even if the objects are part of a symbol.

That's the power and beauty of VWX symbols and VWX classes. It's hugely advantageous. The contained objects can be, but do not have to be same class as the symbol. Attributes of contained objects can be controlled by their individual class settings, and the control is global through those various class settings. Symbol attributes are even adjustable via Viewport class overrides without altering the design layer conditions.

I do not want anything messing with my symbols without my permission. I especially do no want a default condition that automatically alters class or other properties of symbols or their contained geometry, eg during insertion.

But I do agree that a special condition would be helpful so that one or more instances of a symbol can have temporary unique properties (need to be able to undo the special). Eg insertion with all contained geometry displaying attributes of a designated class. Or for an existing instance, mirror the master class settings across all contained geometry.

Special insertion or other conditions would persist until the special condition is disabled or altered (similar to how font selection or text size works).

Operator has to be careful to know how and why symbol instances are behaving differently from each other.

-B

Link to comment
  • 0
  • Vectorworks, Inc Employee

I totally see the usefulness of this... but implementation will be super key for something like that. Many workflows would benefit from it but other established ones might suffer for different reasons.

Keeping an eye on this thread, if anyone has any other input, feel free to keep it coming.

Link to comment
  • 0

Maybe this is not exactly the same thing, but I think that we need the ability to set an object's class to "From Parent"

That way an object inside a group or symbol definition will automatically take on the same class that the Group or Symbol Instance has.

If the attributes of the contained objects are set to By Class, then the contained objects would use whatever class the container (Parent) is in.

I think this would solve a lot of the multiple class visibility issues that we see and make it much easier to use class attributes on objects such as notes. Consider a large block arrow with text inside. You might want the block and the text to be different colors to indicate different types of objects. Currently the best way to do this is to have multiple object each with defined colors. With the From Parent option, you could set instances of the parent to the red class, the green class and the blue class. each individual instance would then use the attributes for that class.

  • Like 2
Link to comment
  • 0
+1

-1

Did not really read what was demanded.

I meant,

if a class is set to use class settings,

assigning Objects into that class should be forced to take the class settings by default.

Maybe a warning/option that says :

Of 125 objects you want to assign to class "XXXX",

there are 23 objects with local assignments,

Do you really want to assign class attributes to these too ?

YES - CONVERT ALL TO BY CLASS

NO - KEEP LOCAL ASSIGNMENTS

This already exists in Vectorworks if attributes are set to by class, except that it does not show the x out of y number of objects but asks if you want to do this for all selected objects you are assigning a new layer. Unless you are referring to something else.

Link to comment
  • 0
I totally see the usefulness of this... but implementation will be super key for something like that. Many workflows would benefit from it but other established ones might suffer for different reasons.

There is no need to change the existing workflow options, it is "simply" a matter of adding an option where the "by class" attribute appearance is controlled by the class on which the object is residing even when it is part of a symbol.

Now the only options are the class at creation or the class at insertion.

This additional option should be set at creation of the symbol, it should not override already existing symbols unless you manually update the symbol to use this option.

Allowing this option at insertion of a symbol would probably cause trouble with some workflows as it would create inconsistency in behaviour of multiple instances of the same symbol and that is absolutely the last thing I want to happen.

Link to comment
  • 0
Pat has nailed it. "From Parent" is exactly what's needed.

KM

Almost... as long as it is part of the symbol definition at creation then yes I would agree.

If it would be an option for use at insertion then I would disagree as this creates a risk for different behaviour of multiple instances of the same symbol whereas I do want the symbol to behave in the same way for all instances, i.e. to have the "by class" attribute appearance to be controlled by the class on which the symbol is residing and for it to update to the class attribute properties to which it is reassigned.

Link to comment
  • 0
[quote=zoomer

This already exists in Vectorworks if attributes are set to by class, except that it does not show the x out of y number of objects but asks if you want to do this for all selected objects you are assigning a new layer. Unless you are referring to something else.

Maybe I deactivated the warning ?

I'm aware of this when ungrouping things but can't remember that warning when

changing objects classes.

Sometime I find objects later that don't have expected material or so and realize

that some objects are still set local. So I select ALL objects from time to time to

assign them by class again to be sure.

(like I do with convert to generic solids, which seems to not always convert all

possible elements if there are some 2D things in selection ...)

Edited by zoomer
Link to comment
  • 0

Maybe I deactivated the warning ?

I'm aware of this when ungrouping things but can't remember that warning when changing objects classes.

Yes, I get that dialog too when ungrouping, but I do recall that there is also a first time dialog when when changing classes but I could be mistaken with the copy/paste between drawings.

Because I set everything to by class by default I and disable the warning for ungrouping I get this dialog so rarely I'm not sure about all possible situations when this dialog shows up.

Maybe we could have an option in the preferences where you opt to get this dialog upon changing classes asking if you want to use the class settings or keep the manual settings. For people like us who almost always use the by class settings for the attributes this might be useful.

Jim, perhaps something new for the 2017 wish list? Or do you want a break for a day? :)

Link to comment
  • 0
  • Vectorworks, Inc Employee

Break!? Who needs breaks!?

[img:center]http://i.imgur.com/ChbT1Vd.gif[/img]

This thread is being monitored for a few wishlist requests, no worries.

And yeah! We have already started 2017 work here as well. It is always a little surreal releasing 2016... while still in the year 2015 and working on release 2017...

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Answer this question...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...