Matt Panzer

Ahhh. Good to see you now have it working! 🙂

Are you sure the "Use Hinge Marker Class Attributes" option is selected? If so, can you send me a file showing the problem?

@martinfdc, This appears to be fixed in Vectorworks 2019. What version are you seeing this problem in?

@martinfdc, This appears to be fixed in Vectorworks 2019.

You're welcome, Benson! I agree that that it should be more intuitive to use. We are aware of the problems in the interface and are exploring ways to improve them. There are a few things at play that make this somewhat challenging, but improvements can be made.

@Wes Gardner, Shhh! I'd rather not have people knowing about me being a door-to-door salad dressing salesman. 😕

Hi Henry, Can you send me the image file privately? Also, please tell me what version of vectorworks you're using (please include the service pack number).

No problem, @JMR If you see the problem happen again and can somehow reproduce it, please do let us know.

Thanks @jblock @JMR, There is a slab still in the file causing the problem. It looks like the slab may have had some odd section plane geometry cached with it? The first thing I try when I see things like this is to "bump" (reset) the object. Typically, I simply move the object by (0, 0) to trigger the reset. Doing that fixes the problem. See attached video: ScreenFlow.mp4

Good to hear! I'm thinking it could've been some odd viewport caching issue that was fixed in a service pack but somehow lingering in your file. I'm totally hooting in the dark here... How old are you? Some things eventually get worse. 😛 No problem! If it ever resurfaces, let me know. Thanks for the update!

@JMR, Could you enter a bug on this with the file? Try this (keep a copy of the file if you plan to submit it with the bug): Turn off the "Save viewport Cache" document preference Save the the document Revert to Saved (this should reopen the document with no viewports cached) Update the viewport Turn on the "Save viewport Cache" document preference (assuming you want it).

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.

You mean the upload process stalled at 40+ MB? How big is the file? You should be able send quite a bit larger than that. Also, you could try deleting unrelated layers and purge in a copy of the file if you want to trim it down in size.

Hover your cursor over my name above my picture and you will get a popup with my information. In the popup click on the "Message" button and drag the file in the message window that comes up. That message (and file) will go directly to me.

I just took a look and do not see it available for Spotlight users. I assume it because the majority of projects in Spotlight do not hav that many pages? In any case, I'll run this past the Spotlight folks to see if this is something they might consider adding.

Hi Christian, Can you send me the file privately so I can take a look?

The subdivision tool creating hollow object in section is an issue. Hopefully this will be corrected in a future version. I miss Jim W right about now.... @Matt Panzer is there someone who can speak to this? The geometry a subdivision produces is a mesh. This would cause it to show as hollow with the clip cube (as all meshes do), but it should show solid in section viewports (as long as it's a closed surface). You may ask why we don't convert the geometry to a solid within the object. The answer is simply due to performance issues.

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... 🙂

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.  Backup you files! Seems like a good idea...  Save and Commit (and Release) all working files to make sure one person is able to edit all Wall Styles and Walls objects.  In one working file: Edit all Wall Styles and change the "Attributes Beyond Cut Plane" to "Object Class". Save and Commit (and Release). Delete and recreate all working files from the project file.

Edit its components (via Object Info palette) and set their top to be relative to top of wall.

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, 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.

@JMR, Great! Thank you for the files! I'll take a look and let you know what I find.

@JMR, Interesting. I've not been able to reproduce this with any edits to classes used for wall components. Did you have the walls (or their design layers) checked out before this happened? If not, were you prompted to check them out after editing the classes? Do you have a copy of the file before this happened? If so, can you send it to me? If not, can you send it in its current state?

Thanks, Mike! You can imagine why this problem seemed so random and happening to users that weren’t doing anything with walls. It took a lot of time, persistence, and help from some engineers to isolate this one. Well worth the effort!!! 🙂