Matt Panzer

The By Style/Instance settings are controlled by the style and cannot be changed at the instance level. To change them, locate and right-click on the style in the Resource Manager and choose the "Edit" content menu command. You should see a very similar dialog for the style. You can toggle the style "arrow" icon buttons between By Style and By Instance. Once you change a setting to By Instance (and click OK to save the style's settings), the style will no longer control them and you can go back and edit the instance in the document and set it as you like. Note: When the By Style toggle buttons contain an icon that looks like an open book, that parameter is controlled by the catalog and cannot be changed (other than by choosing another item from the catalog).

The errant lines issue is a bug and looks to be fixed for 2024 Update 5.

Hi Matt, This is because there are a lot of complex needs in walls and each feature added must know how to interact with all of the other features. Adding stacked components might not be that difficult by itself, but then you must be able to define wall closures for all component structure combinations the wall has. And there's the question of what do you see in Top/Plan. What about wall joining, etc, etc. It all can be done, but it's not simple. AI is an interesting tool and has its uses but I don't see how it could help in this area anytime soon. I'd love to be proven wrong but I'll just leave it at that. 🙂

A lot of the settings of the default content are set to By Style (to make them easier to manage via the style). If they're set to By Style, you will only be able to edit them through editing the style and all instances will take on the changes. If you want the ability to set them per instance, you will need to edit the style and set the parameters to By Instance.

In a nutshell, Vectorworks is used in many regions around the globe - each having different needs. As you can already see in this thread, many users put different wishes higher on their priority list. We're always looking at these many needs and need to make hard decisions to prioritized them. While I agree are framing tools are in need of considerable improvements (and it is important to us), there are other many other areas that need improvements as well. I realize it can be frustrating to not see a feature you've wished for not get addressed for a long time (I was a VW user for over 23 years) but there's only so much that can be done with the resources we have.

I have not heard anything bout this one lately. I would recommend upvoting and commenting on the two wishlist forum threads @Tom W. linked to above.

Not that we’re actively researching this but, if we did add it to the wall, it would most certainly be an option you could choose to ignore.

We have previously discussed the idea to integrating framing and other repetitive objects into walls, slabs, and roofs but have not explored details of how this might work. I do think it makes good sense to have it integrated so the framing is automatically when changes are made. Of course, we would have to take performance implications and user interaction (for editing framing) into account. While this is not something we're actively exploring, I'm sure we'll be revisiting the idea in the future.

This is the best I can do to get around the issue: ScreenFlow.mp4

I do not see a fix in for this yet. I'll try to bump this up to see if this can be addressed soon.

We're not seeing these issues with Vectorworks and Mac OS 14.4.1. Have you tried repairing your install using the advanced options in the updater? The updater is located in the Vectorworks 2023 Updater folder in the Vectorworks application folder.

I agree more is needed with the improvements that have been made since then. I'll see if anything is being planned...

Weird. The link was to another thread for the title "Representation of Window Sills in Masonry Walls 2D/3D". Search for the in the forums and hopefully it'll come up that way. Actually, that thread is very short but links to another much longer thread titled "Representation of Window Sills in Masonry Walls - 2D".

@rDesign, Strange. I have not seen that happen before. Please let me know if you can see this message. Here’s my last message in case you still cannot see it:

There is a coffee break that came out just after wall closures were first introduced. While some things have changed since then, I think it still covers the basic concepts pretty well. One notable change is the profile offsets we’re moved from the insert to the wall closure settings. https://university.vectorworks.net/course/view.php?id=2021

You’re welcome! I agree that you’d expect a user defined 2D component to be saved with the style when created from the object. I don’t think this would be intentional but it might be due to some technical limitation in the current style system.

The issues with corner windows are a known bug. The reason using wall closures give different results in the sills is because window sills and door threshold automatically fit themselves to the shape of the wall closure. While this is a big improvement, implementing the door and window handing features in 2024 required major code changes that caused this issue that still needs to be resolved.

Actually, you can Edit the 2D Component for a Style and make it By Style in the Plug-in Object Style Options. As you stated, it will cause them to remain static and will not update with parameter changes.

Right. I was thinking something along those lines Yeah. Controlling these per viewport and possibly per object per viewport should be considered. We did consider adding per object per viewport overriding of 2D component when the task was first designed but wanted to limit the complexity until we had good use cases. Having a complete feature is important but we have to be careful not to over design things that users never want to deal with. We can always add features but taking them away later is not so easy without potentially changing files brought forward from previous versions.

I would say this is unintended behavior but I also don't think the mixing of world and page scale symbols is officially supported either. I do, however, see why you want to do it and wonder how we might be able to better solve the problem in the future. If there's a way to reproduce the same display/zooming issue with more typical cases, I think it'd warrant a bug report and get more attention.

Set the document unit precision much higher than 1 decimal place then edit the hatch and you’ll see the offsets are not what you think due to them being rounded to the document unit precision. That is what’s causing the problem. Once you’ve corrected them, you can change the precision back as needed. BTW, I believe the hatch offsets can be corrected without changing the precision by selecting each one and retyping it in. This will replace the actual values (that are displayed rounded) with the correct value. It’s a little weird doing it this way because the value you’re replacing looks the same (do to the rounding) as the new value.

Ah, right. Thank you for bringing this up! I agree that this is a bug and submitted one (VB-202822).

This is not currently possible.

Right. That’s the “not ideal” part. 😉

All I’ll say is that you’ll see this addressed very soon. 😉 As for adjustments to classes panes, that is another thing for another time…