-
Posts
3,302 -
Joined
-
Last visited
Reputation
2,004 SpectacularPersonal Information
-
Occupation
Architectural Product Planner
-
Homepage
www.vectorworks.net
-
Location
Columbia, Maryland
Recent Profile Visitors
The recent visitors block is disabled and is not being shown to other users.
-
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".
-
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
-
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.
-
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).
-
Right. That’s the “not ideal” part. 😉
-
Right. Not an ideal solution. However, if you save the originals with the same names in another file, you can import them back in (replacing the modified ones) after it's fixed.