Jump to content

Symbol Inheritence?


Recommended Posts

Petri - Huh? I'd like to be able to quickly change the attributes of a symbol by simply moving it to another class. I'm just a newbie here but it looks like if I want to change the attributes of a symbol, I need to edit the symbol (by double clicking,) move the elements of the symbol to the new class, and then close the symbol editing window. Is this not correct?

Petri - parametric object? what about all of the existing VW symbols?

Pete - the viewport thing gets me closer but still seems laborious. I know that I'm being too ACADish but I don't understand why some objects take on class attributes (2d shapes and lines, doors, and windows) and some don't (symbols.) I'm just not looking forward to reworking all of the (thankfully many) symbols that VW provides to suit my lineweight preferences.

Perhaps I'm being short sighted. VW is MUCH better (and faster) than ACAD at many things. It's just not better at this one. I just hope that once I get fully up to speed that I will be able to produce better design work faster with VW - I really don't want to go back to ACAD or my PC.

Link to comment
Petri - Huh? I'd like to be able to quickly change the attributes of a symbol by simply moving it to another class. I'm just a newbie here but it looks like if I want to change the attributes of a symbol, I need to edit the symbol (by double clicking,) move the elements of the symbol to the new class, and then close the symbol editing window. Is this not correct?

This is correct. Now, should you want an intelligent object that can transform itself (ie assign its components to other classes or do something similar you need a parametric object. Perfectly doable.

Petri - parametric object? what about all of the existing VW symbols?

They are not parametric objects. The McMansion objects supplied with the program do not have capabilities you seem to require.

I really don't want to go back to ACAD or my PC.

Do multi-layered AutoCAD blocks inherit the properties of the layer they are placed on? (I know very little about AutoCAD.)

Link to comment
The McMansion objects supplied with the program do not have capabilities you seem to require.

Given that I work on "McMansions," those capabilities would be quite helpful.

Do multi-layered AutoCAD blocks inherit the properties of the layer they are placed on? (I know very little about AutoCAD.)

In ACAD, any object in a symbol that was created on Layer 0 that has it's attributes set to ByLayer (equal to by class in VW) will take on the attributes of the layer (read class) on which the symbol is inserted.

Link to comment

You can also use groups to do what you want, they can adapt the classes attributes.

The way VW uses symbols is much much better than the way ACAD uses blocks. If you want some doors to be demoletion and doors that should stay, they should look different and should have a different symbol.

If you use different symbols, you can count the numbers of them with a worksheet.

A symbol is 'something' that is always the same, but you need different times. If you need to have this but with parameters, then you'll need to make your own parametric objects.

It's just the way of using blocks and symbols is different. Just forget how you draw in ACAD, because it's not the same.

Link to comment
In ACAD, any object in a symbol that was created on Layer 0 that has it's attributes set to ByLayer (equal to by class in VW) will take on the attributes of the layer (read class) on which the symbol is inserted.

Right... What?

So... You want to be able to create complex, multi-classed symbols that lose the graphic attributes of the classes of their components when they are inserted?

EDIT

Let's try again.

You want to create symbols that contain components in a number of classes. When you insert such a symbol, all components should inherit the appearance of the class of the symbol instance.

Is this correct?

Edited by Petri
Link to comment

NO - I want to create simple symbols that can take on the $*!*ing attributes of the classes that I place them on just like every other $*!*ing object in VW so that they don't look like $#!^ when they print (e.g. place any VW refrigerator symbol next to a line of cabinets inserted using the cabinet tool - line weights are totally different.)

let ME try again.

I'd like to have the option of allowing classes to control the attributes of symbols so that they act more like most other VW objects and so that it's easy to maintain visual consistency and printed output.

Link to comment

I doubt you will like the end result of this, but here is another option. The attached script will go through and modify every symbol definition in a file to insert as a group rather than as a symbol. You can then go back and change the class of the inserted group and it will ask if you want to convert all of the sub-objects. Click the Yes or Yes Always button and the objects inside the group will be converted to the new class. If they were set to take the attributes by class, then you will see the attributes adjust also. The second script will go through and change all of the objects of a group to use class attributes.

WARNING!!! The following script will permanently alter your drawing. There is not Undo available. Please use with extreme caution on a backup copy of your drawing. The recommended usage is to create a new "Library" file that contains the symbol definitions for each of the symbols you want to modify and then run the script only in that library file. If you run the script in a file that contains existing symbols (such as door leafs), it is likely that those objects MAY BE DAMAGED. NO WARRANTY IS EXPRESSED OR IMPLIED. USE AT YOUR OWN RISK. SHAKE WELL BEFORE USING. TAKE WITH FOOD.

Ok, if you still want to try, here they are Copy the lines between the ===== to a blank VectorScript window.

Script 1

=============

Procedure SetSymbolsToInsertAsGroups;

{Copyright 2007, Coviana Inc}

{Pat Stanford , pat (at) coviana.com}

Var H1: Handle;

Begin

H1:=FSymDef;

While H1<>nil do

Begin

SetObjectVariableBoolean(H1,127,True);

H1:=NextSymDef(H1);

End;

End;

Run(SetSymbolsToInsertAsGroups);

================

Script 2

================

Procedure GroupedObjectsToByClass;

{Copyright 2007, Coviana Inc}

{Pat Stanford , pat (at) coviana.com}

Var H1:Handle;

Begin

H1:=FSActLayer;

H1:=FInGroup(H1);

While H1<>nil do

Begin

SetFillColorByClass(H1);

SetFPatByClass(H1);

SetLSByClass(H1);

SetLWByClass(H1);

SetMarkerByClass(H1);

SetPenColorByClass(H1);

H1:=NextObj(H1);

End;

End;

Run(GroupedObjectsToByClass);

Link to comment

One important thing to note about converting Symbols to Groups is they will lose their hybrid nature. ie they can only be either 2D or 3D. Which you end up with is determined by the view you are in when you eexecute the Convert Symbol to Group command. If you are in Top/Plan View you will end up with the 2D component. If you are in any other View you will only get the 3D component.

Link to comment

Bill's right about how ACAD blocks work, and there's just no exact equivalent in VectorWorks. There are workarounds, but I think it's worth mulling over a wishlist item to NNA about coming up with something that will give more meaning and power to the class assignment given to container objects.

With ACAD blocks, the attributes of some (not necessarily all) objects within a block can be overridden by assigning the block instance to a "layer" (= VW class) in the same way VW objects take on class attributes only if they have been created with the "by class" options selected.

It strikes me that if there were a checkbox option on a symbol, whereby the user could choose to override member object attributes according to the class assignment of the symbol container object, that would do the job without creating a conflict with the normal way that classes can be modified in a Viewport. This would only operate on those objects and those attributes with "by class" selected. You could call this idea "optional inheritance."

Link to comment

I would like to see this on the VW wish list, but without a checkbox. What's the problem with just doing it the way AutoCAD does? Any symbol object assigned to the None class AND set to inherit class attributes would be subject to class inheritance. All other objects on other classes or with specific attributes assigned would be unaffected.

No need to add more toggles, buttons, or whatzits.

Matt

Link to comment

Matt, if I understand you correctly, that would create a conflict. Of course, there is no current option to have an object "inherit" a symbol's class attributes, so I'm assuming you mean that the object's attributes are set to "use class," and you want the meaning of that to be "use the symbol's class," not the other class NNA assigned to the object.

If you ask an object's attributes to be overridden by both the symbol object's class and by the class override in a Viewport (N.B., these classes are different, otherwise we wouldn't be talking about the inheritance concept), there would be no way for the program to sort out which one has priority. Or, at the very least, there would be a conflict with the desire of those users who don't want the ACAD behavior to prevail, and have set up their systems to work with the way VW currently behaves.

Think about this: a line in a symbol has class "A," and is set to dash style "by class." Class A has a solid linestyle (no dash). Under your inheritance proposal, if the symbol is assigned class "B" with a short dotted line, the line would become dotted. But suppose that in your viewport you have defined a class override whereby class A is set to a long dotted line. Which dash style will the line receive? It has to be determined to be one or the other. If it automatically receives the short dash, that frustrates the desire of users to have the viewport preference apply.

On the other hand, if you mean to suggest that there be a new attribute option, for a symbol member object to "inherit" its attributes from the class of the symbol container, then that might be a workable alternative to give the user a choice. It would add a button in a different location, I hasten to add, and it wouldn't give us the nuanced control to assign some attributes, but not others, the inheritance behavior. Having another setting for every attribute for every object would be too much.

Link to comment

Why would someone use a symbol where all of its components look the same? That's the point of VW symbols!, They can have components of different classes, for you to create very good symbols. You can turn of some classes and the symbol looks different.

It's just that ACAD blocks are way too limited. They could only use 1 class (ACAD layer) when I worked with it.

If you see this limitation, then you'll see that VW has a more complex way of working with symbols.

I also think the problem is the way some users work with VW. I see many architects work with VW like with ACAD, and that's not the way it's supposed to be.

PS: I must also admid that the option to inherit the symbols class to its components could be handy, but when NNA should implement it, I would like to see it on the info pallete. That way you can turn it of or on when you need it to. Not Like ACAD, where once created, it will always inherit or it will never.

Link to comment

Your asking something that's not possible. You only want the none class to inherit the symbols class attributes. (which is absurd)

The problem is that not in every translated version the none class is 'none'. So the none class is just like every other class in the document.

Or you want to inherit the attributes to all components that uses 'by class' or none of them.

Link to comment

Matt, thanks for going to the trouble to create a graphic illustrating the specifics of the idea. To limit the operation of the override to "none" class is an interesting idea, although as DWorks points out, it's not the only way to go. But having the Viewport override settings supercede might void the usefulness of the whole idea, since Viewports on Sheet Layers are the current method of choice for many (but certainly not all) users when it comes to output - which is where the graphics count most.

For me, this inheritance feature would have to be a user-controlled option, not a default or automatic thing.

I don't know that this is impossible. AutoCAD programmers were able to do it, but given the structure of NNA's code it might be difficult.

Link to comment

Actually there is precedent in VW for this type of behavior. In drawing borders if the text in the base symbol for the drawing label has attributes set to by class, you can select the drawing border, and change the fonts from the text menu.

It's obscure, annoying the first time one sees it, and probably not great interface design, but it does work.

Link to comment

Parametric objects can indeed be made to adjust themselves to their class & inherit graphic attributes, so there are many precedents. I have written several PIOs that have this behaviour.

Symbols, however, are another breed. Notwithstanding, I have used (and may any day use) symbols in a manner where this inheritance might have been beneficial: a typical situation is "condition classification" of any existing elements.

There'd be no damage done if a symbol definition could have a toggle for this: "Use graphic attributes of the instance's class". I'm just not quite sure how useful a symbol including components in 10 or 15 classes be under such conditions. ("Not sure" to be interpreted literally here.)

Basically, I prefer to have symbols that unambiguously represent real world objects (and vice versa: when I think of the real world object, I know that there is only one virtual counterpart for it.) The "Replace" button in OI works quite nicely...

Link to comment

Recalling that Logic gates take one or more input bits and transforms them into one or more output bits: OR, AND, NOT, COPY

Based on the above discussion and Threedot's excellent graphic> http://www.52topicyear.com/VW/SymbolInheritance.pdf

To avoid changing the well established Class, Group & Symbol protocols the only remaining option appears to be a use of the COPY logic.

In other words when a User 'B' desires to modify the Class attributes of a Symbol created by User 'A', the Symbol Instance is then Copied in place by VW using the Class attributes assigned specifically by User 'B' ... whereas the User 'A' Class attributes of the Symbol Instance... then... become invisible to User 'B'.

This simple solution utilizing the existing structure avoids the thorny Class 'reassignment' problems along with the possible corruption related to assignment of the Groups between conflicting Classes.

To implement this functionality in a multi-User environment each User must login prior to using the program so that VW knows what to do with the Class if>then attribute assignments.

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
Reply to this topic...

×   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...