Walls keep coming unjoined

[Sam stork]

We have a shared model and every time it is updated some of the wall joins come undone. Has anyone got a fix for this problem?

We have tried updating our Vectorworks to the latest service pack, it is VW2019.

Thanks

[Matt Panzer]

4 hours ago, Sam stork said:

Thanks Matt we will follow your steps and fingers crossed!

 

You're welcome, Sam.

Please note that, after following those steps, you'll need check and rejoin any existing open joins. Hopefully, this will be the last time you do this. 🤞

Please keep us posted on how it goes.

[JMR]

15 hours ago, Matt Panzer said:

@JMR,

 

I've spent quite some time trying to reproduce this and, so far, I have not been able to trigger it without editing a class used for the "Attributes Beyond Cut Plane" of a wall style. Are you sure you had everyone's changes committed before updating the wall styles to have "Attributes Beyond Cut Plane" set to "Object Class"? I'm thinking there may've been something lingering somewhere that threw things off.

 

Yes I'm sure, but I hadn't applied your suggested fix at the time the unjoining occurred - the file was in it's "native" state with the stock "Attributes..." class settings.

 

When I think of earlier instances, I'm 99% sure that we didn't edit the "Attributes Beyond Cut Plane" class - it's not something we'd have to very often in any case.

 

HTH

 

[Matt Panzer]

On 4/29/2019 at 12:08 PM, JMR said:

 

Yes I'm sure, but I hadn't applied your suggested fix at the time the unjoining occurred - the file was in it's "native" state with the stock "Attributes..." class settings.

 

When I think of earlier instances, I'm 99% sure that we didn't edit the "Attributes Beyond Cut Plane" class - it's not something we'd have to very often in any case.

 

HTH

 

OK. Thank you for the feedback. So far, I still cannot find another trigger for this issue. In any case, we believe the core issue is the same: A wall style is being flagged as edited without a wall replacement operation. This causes all walls of that style to be checked out, but not walls joining to them. This, in turn, triggers an attempt to rejoin them in the project file during a commit. This is where the joins fail - which is why they're never seen in the working file that caused the problem.

 

BTW: I'm updating my steps to help prevent lingering gremlins:

 

Until we have a fix, this is the only reliable steps to help prevent the problem:

    Note 1: This will not fix broken joins, but should prevent breaking more.

    Note 2: If using Design Layer Cut Planes, these changes will likely effect the attributes of walls that are below the design layer cut plane in Top/Plane views.

1.  Backup you files! Seems like a good idea...
2.  Save and Commit (and Release) all working files to make sure one person is able to edit all Wall Styles and Walls objects.
3.  In one working file:
   • Edit all Wall Styles and change the "Attributes Beyond Cut Plane" to "Object Class".
   • Save and Commit (and Release).
4. Delete and recreate all working files from the project file.

 

[JMR]

1 hour ago, Matt Panzer said:

A wall style is being flagged as edited without a wall replacement operation. This causes all walls of that style to be checked out, but not walls joining to them.

 

That might well be the case, however please note that eg. in the previous screengrab example in this thread, the opened joins consisted of the same wall style.

 

I can say with 100% certainty that the opened joins often consist of walls of the exact same style. This would suggest that not all the walls are checked out, even though they are of the same wall style?

[Matt Panzer]

38 minutes ago, JMR said:

 

That might well be the case, however please note that eg. in the previous screengrab example in this thread, the opened joins consisted of the same wall style.

 

I can say with 100% certainty that the opened joins often consist of walls of the exact same style. This would suggest that not all the walls are checked out, even though they are of the same wall style?

 

I do believe (and all of my tests show) all walls of the same style are checked out but, since no wall replacement occurs, things get unpredictable when committed to the project file. An obvious case where this would fail would be a T-join involving three walls of two different styles. Cases you're probably seeing about are L-joins between walls of the same style. However, I believe those cases could possibly be caused by a combination of edits made in the same (or other working files). I say this because the joins remain in tact in the working file that caused the problem in the project file. Other working files will see the broken joins. If If edits are made involving only some of the walls with broken joins in the working file that caused the issues, committing them back will correct only those walls. Edits made in other working files involving some of those walls could further confuse the issue. It could get messy fast.

 

Of course, I may be wrong. however, the first step is to fix what we can reproduce, then we can try to break it. I think it's quite possible that this one issue is the root of it all. Only one way to find out... 🙂

 

[JMR]

@Matt Panzer

 

Some more information...I checked all wall styles in the file, and they were all already set to "Object class".

 

The cut plane option is not enabled for any DL currently. HTH

 

[Matt Panzer]

Thanks for the information. Yes. There is more to the problem than that. We've been working hard to zero in on the problem and now have a good understanding of the root cause. However, fixing it could get quite involved. 

 

We're still trying to sort out what things to avoid doing until this issue id fixed. We will gat back to you as soon as we do.

[Christopher Graye]

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

[JMR]

Excellent, thank you!