Christiaan

Have to agree with Petri. Looking beyond American borders would be high on our list.

Of course not. I thought I'd been very clear that it is in fact crucial to our workflow. The extra Classes that I'd need to create in order to retain this v12 functionality in v13 are what is redundant. As an example, open the attached v12 file in v12. You will see that the components are one colour in the Design Layer (red) and one colour in the Viewport (blue) and that the outer lines of the wall are thicker than the component lines. Now convert and open the same file in v13. You will see that the wall component colours are now missing, so our v12 files no longer look the same once converted to v13. The logical solution to this bug, in my opinion, is to add the ability to set Class for each attribute in the Component Attributes editing window.

Unfortunately, from comments I've seen, the view at NNA appears to be that third party renderers are seen as a threat to RenderWorks rather than value-adder to VectorWorks. From this I can only deduce that RenderWorks isn't seen as being able to compete with other renderers on its own two feet, and I'd have to agree. Until the view above changes?and there are signs that it may?you won't get NNA talking to third party render developers. All we can do is keep applying pressure I guess.

Yes and yes. In terms of management I would expect one to dynamically affect the other. So if you click the check button to set by Class overall it would switch all three Attributes to Class. If you then change one of the Attributes manually to another value the overall button would uncheck and the other two Attributes would remain set by Class.

Katie, you never answered my question: what problem is going to be created by adding use "Class" to the style, line and colour drop-down menus in the Component Attributes window? Until you can answer this you have no basis upon which to make the above comment.

Sorry if I've snapped at anyone on this. I'll take the blame for not explaining lucidly from the start but it's got rather tedious talking round in circles. And it's annoying to be told by someone who doesn't understand the issue that my problem is not important and that I'm moving the goal posts. If there's anything I've ever been right about on this forum it is this topic. I don't have a hat but if I did I wouldn't be eating it. If you can't understand what the problem is by the time you've read through to this point then just give up and trust that I'm right and you're wrong. I fully expect the engineers who get my bug submit to understand the situation and I hope that it's expedited.

Okay, now you're just being plain ignorant and a pain in the ass. You really think we just use one wall type in our office? The fact is we have multiple walls, each of a different colour. This isn't moving the goal posts. This is reality, something you clearly have no regard for. I had also already explained this fact above, before you posted your "solution". Not that that makes any difference; you're clearly not interested in actually comprehending what I have to say. Furthermore the file I posted has only one colour in the design layer for both components and outer lines. And red in the Viewport, for both components and outer lines.

If you bothered to read and understand my posts, which you clearly don't, you would already understand my short term solution (6 posts up): http://techboard.nemetschek.net/ubbthreads/ubbthreads.php?ubb=showflat&Number=89061&page=0#Post89045 P.S. Understand what has been written before throwing patronising insults. The goal posts haven't moved, just your glacial understanding

It's not a solution. It doesn't solve my problem. 1) You've added a Class 2) I would need to add a separate component Class for every wall colour we have, which is about 6 (as I've already stated above).

No, because then all components of different wall types will be the same colour, i.e. the colour of this single component Class you propose. They will need to be black because we won't be able to override them in Viewports, and generally if we're overriding colours in Viewports we want them to be overriden to black, while leaving a boundary line red for instance. It's not black that's the connection but the fact that we will have to set the colour manually instead of by Class. It's just that we will have to use black for the reason above. Then download the wall I attached to a post above and try it with that one to see what I mean. That would be a fair point and maybe worth an additional bug submit, except that they're one in the same thing. NNA are not going revise v13 to automatically create new Classes for me when I convert a Wall Style now are they. To overcome this problem all they need to do is add Class settings to the attribute drop down menus.

Me too. And if you choose to manually change one of the attributes while that option is checked I would expect it to automatically uncheck while leaving the other two attributes on Class setting.

Yah, the penny is starting to drop. Welcome aboard.

The outcome of it all for us is that our wall components will have to be black so we can set the line thickness separately and not populate our Class structure with stupid superfluous Classes that will help only to confuse matters for our users (and in fact if you bring our v12 Wall Styles into v13 this is precisely what happens). It's a crap situation because it means our walls won't be as easy to differentiate as they are when using v12, which means using v13 will be more prone to mistakes and delays. And I would hope NNA fix this problem quick smart because now I have to explain to the boss, who just coughed up a pretty penny to upgrade, why we have effectively lost the ability to differentiate walls as easily as we could in v12. I have to say I don't care if it's working as designed. For us this a bug, pure and simple. When we open our v12 files in v13 our wall components are no longer coloured as they were in v12.

You're wrong again (about just "one additional" class). Read my post above. And it's four people now. And more to come probably when people eventually understand the problem.

In fact this is actually incorrect. If I want our wall components to be the same colour as our walls (and set by Class) I would need to create a separate component Class for each wall we have (i.e. External, Internal, Separating Party Wall, Separating Common Wall, Partition and RC Concrete) because each of our walls are a different colour to help us ensure we place the right walls in the right situation.

Not so much lost functionality, but lost capability. We can achieve the outcome I need in v13, but we can't do it in a proper manner as we could in v12 (i.e. by using attribute controls to control attributes, rather than using classes to control attributes).

I've now submitted this as a bug.

For the love of god, the next person who repeats this should sit in the corner of their office and say to themselves 1000 times, "I will read a thread properly before making suggestions". I know you can use an extra f**king Class to achieve this functionality. Am I a complete moron when it comes to explaining things? At least you admit that we have lost a capability we had in v12. I don't want to create an extra Class simply to control the line thickness of components. Creating Classes simply to control attributes is stupid. I just want the capability we had in v12. And we can have this capability by simply adding Class setting options to the line, style and colour drop down menus, something that should have been there in the first place.

The components. In the Edit Wall Style window edit the overall "Wall" to "Use Class Attributes. This will mean the outer lines and the components will use class attributes. Then you can edit the line thickness of the components manually to be different from the outer Wall line.

You're wrong. In v12.5 you can set the colour by Class and the line thickness manually. You can't have this combination in v13 without creating a new Class.

Well, between you, me and VectorGeek, that makes 3 people in the whole world who understand this little problem.

boxjoint, in the Edit Wall Style window you will see a list of components you can edit. At the top of this list is "Wall", which controls the outer lines and the overall Class of the wall. You can edit "Wall" to be one line thickness and then you can edit the other components to be a different line thickness. And all these lines can remain on one Class and therefore have their colour set by Class, negating the need to create extra Classes simply to control attributes.

Katie, I think you need to stop and read what is actually being said on this topic. In the very post you were responding to VG pointed out that creating a separate Class is not the best solution in his opinion. Why then tell him he can do it with a separate Class? He clearly knows this already. We just shouldn't have to resort to Classes to control such attributes. That's what Attribute controls are for! I note that I've not been required to send you a chocolate fish or eat my hat!

Actually, in terms of controlling component line colour and thickness, without creating new Classes, I just want the flexibility we already had in v12.

No it doesn't because the component lines will be the same thickness as the wall's outer lines. Exactly, therefore we've lost a capability we had in v12. i.e. to control component line colour by Class while controlling line thickness manually, without having to create extra Classes.