Jump to content

Christopher Graye

Vectorworks, Inc Employee
  • Posts

  • Joined

  • Last visited

Everything posted by Christopher Graye

  1. Hi cberg, This is a bug that will be fixed in the next service pack. It happened as a result of the work we did that creates true 3D subobjects for walls, allowing you to convert a wall to a group of 3D solid objects. Because those 3D objects are inside the wall, the tool was accidently picking into the wall and getting the solid object inside and modifying that. But when the wall is changed and the geometry is recreated, this accidental edit vanishes. Sorry for the confusion!
  2. It would be good to have those eventually! How about for Vectorworks 2022?
  3. Hello everyone, We have finally been able to find and fix this bug. See my post here for more information: @Christiaan
  4. Hi everyone, As you know, this bug has been extremely difficult to diagnose, and we could not even find a way to consistently reproduce it. But thanks to the help you have provided in this thread, we have finally figured out what is happening. We have a fix for it that we are testing now, and hopefully that should be available in Vectorworks 2019 Service Pack 4. However, I wanted to give you a little more information about it so that you can avoid this bug in the meantime. Unfortunately, the bug is not caused by doing any one thing, but by a combination of actions that result in a specific condition. To avoid this bug, the condition you need to avoid is indirectly editing a Wall Style by editing a resource it uses, checking out one or more walls of that Wall Style while not checking out all the walls they are joined to, and then doing a Save and Commit. For example, suppose you have a Wall Style called WallStyle-1, which has a component that uses a class called Class-1. Suppose you also have a wall of WallStyle-1 joined to other walls (either of the same Wall Style, a different Wall Style, or Unstyled). If you edit Class-1, that indirectly edits WallStyle-1, because it uses Class-1. If you then change the Caps setting of the wall of WallStyle-1 in the Object Info Palette, this will check out that wall. Then, the next time you Save and Commit, the joins between that wall and the walls it is joined to will be broken in the project file (but will continue to be fine in the working file in which you made the edit, which is why it was difficult to know the bug had occurred). To avoid this, you can separate your resource edits and your object edits into different Save and Commits. So, if you need to edit any classes, hatches, gradients, images, gradients, tiles, Line Types, or textures that may be used in a Wall Style, first Save and Commit, to commit any outstanding object edits to the project file. Then edit whatever resources you need to edit and Save and Commit again to commit those resource edits to the project file. Then you can continue to make object edits without a problem. Note that if you directly edit a Wall Style itself, it will check out all the walls of that Wall Style and any walls they are joined to, so the bug will never occur in this case. Once the fix comes out, you will not have to worry about any of this, and you can edit whatever you want and Save and Commit whenever you want. The description above is only important if you want to avoid the bug in Vectorworks 2019 Service Pack 3 or earlier. If you have any questions, please let me know. @Matt Panzer @Sam stork @JMR
  5. Thanks, Sam. We will take a look at this right away.
  6. Hi Sam, This is a known issue, but we have not been to find a consistently reproducible case yet. Do you have your file in a state where the wall joins are good, and then you can get them to unjoin consistently?
  • Create New...