Christopher Graye

No, not walls, slabs, or roofs, which are not plug-in objects, and for which the Attach Record context menu command was never present.

The Data Manager is certainly the most powerful way to do things like this, and it is our recommended workflow for dealing with project data, so I hope you will take the time to explore it if you have not yet. But we have also now done the work to properly implement the Attach Record context menu command for plug-in object styles. It will now work with all plug-ins (instead of just some), and it will also be able to attach records to existing instances instead of only to newly created objects (in other words, it will work the same as it does for symbols). This will be coming in Vectorworks 2024 Update 4. Thank you for all your feedback on this issue!

Can't you set some criteria based on the style, @JuanCarlos?

@KWiley, in any case, it would be very simple to write a script to do all of this as well. I am still looking into it, but things are moving slowly because we are all off until after the new year.

It should be possible to do this, though I am far from an expert on the Data Manager either, so I'll have to play around with it and try to figure it out. In the meantime, I am also checking into what would be involved with adding the context menu command back in such a way that it works reliably for all plug-in objects.

@KWiley, I think you can use the Data Manager to do the exact thing you are describing. Do you ever use the Data Manager in your workflows?

@KWiley, interesting. One possibility is for us to do the work necessary to make this work for all PIO Styles, including propagating the record to existing instances - in other words, make it work the same way as it does for symbols. But that still seems pretty limited. Isn't it a huge problem that you cannot make edits to the door style record after the fact and have the changes propagate to the instances? The same could be asked of symbols, too, but it seems much more limiting for PIO Styles.

The Attach Record context menu command is still there for symbols. It was deliberately removed in Update 2 for plug-in object styles, because it was never supposed to be there in the first place. This was brought to our attention when we got a bug report about about records attached to structural member styles not being placed on new instances. We had no idea this command was even in the context menu for plug-in object styles. It turned out that it got there because symbols and plug-in object styles share some implementation under the hood, and the code that builds that context menu was not properly distinguishing between the two. Since the records were not getting attached to the instances anyway, we just removed the command and thought that was the end of it. But apparently there is more to the story, because the records in fact were getting propagated to doors and windows from their styles, as mentioned in this thread. So we looked into it more, and some plug-in styles, depending on some technical specifics of how their corresponding tools are implemented, actually do the records, and some do not. There is no way for users to tell for which kinds of objects this will work. But at least some users have been using this for doors and windows. How exactly are you using this for doors and windows? The accidental exposure of this functionality only worked half way for objects for which is worked at all, so I'm surprised it was useful. For one thing, unlike symbols, when you attached a record to an object style, it would not be placed on existing instances. Also, when you edited the record fields on a style, it would not update the instances with the changes, so there was no way to make any meaningful changes after the fact. Basically, we have to decide what to do about this now, and I am trying to get an idea for how this was used in your workflows.

And which is creating that gray piece (that is long in the first image and shorter in the second)?

Hi Christiaan, what sort of object is inserted in the wall there? Is it a Vectorworks Window object?

Right, plug-in objects generate their own wall hole and wall closure geometry based on what makes sense for the current parameter settings. For symbols you have to provide these explicitly if the default behavior does not work for you.

Right - if you don't provide a wall hole object it takes the convex hull of the 3D extents of the object. The only way to get a concave wall hole is to provide a wall hole object.

The thing is, though, we don't know, in general, what kind of object is in there. It might be a plug-in object developed by someone to represent a door, but all we would know is that it is a plug-in object - there is no way for plug-in objects to tell Vectorworks, "I am trying to represent a door". This is another case where if we designed wall closures to interact only with our own doors and windows, we could have created a more focused experience. But we needed to support any plug-in object. That is definitely not correct. Possibly it was added when we were trying to do this and never changed later. Yes, this is where you provide the geometry the wall closure interacts with. This is necessary because there is no way to know which parts of the 3D geometry to take into account and which to ignore when it comes to the closures. So you just make it explicit here. If you leave it empty I think it creates a flat plane at the symbol origin to interact with.

Maybe, but if you are not actually putting a window in there that will be misleading. I think I actually wanted nothing in there all, because, first of all, I didn't want any detail at all to obscure the actual closure geometry the user is editing; and secondly so everyone understood that they were editing the closure, not the inserted object. This was a major point of confusion at first, because everyone was used to controlling component wrapping by editing the inserted object itself. But here what you are editing is the wall or wall style or, at the insert-level, the connection between the wall and the inserted object. So by de-emphasizing the graphics of the insert, I had hoped to make this clear. Matt, I think, thought we needed something in there so that the options about wrapping to the insert, etc. would be more clearly understood. This dashed gray rectangle is the compromise we came up with. And it has gone through some changes, too - I think it was initially much darker.

These preview controls were actually not even in the initial version of the feature. They were added later (I think in a service pack). I remember having the same thoughts as you regarding the text above the input fields, but for some reason I did not win that debate. I think it was deemed sufficient that the controls were inside the Preview group box, and that users would understand that those were just controls for the preview. But I don't remember exactly. You're right - it's because wall closures can apply to not only doors and windows but also symbols and theoretically any plug-in object that wants to opt into the system. So we needed to keep the preview vague (at least at the wall style level - as I said, it would be much better to show something closer to the actual insert at the insert level if possible). But there was actually another reason for this - performance. These settings are far too complex to try to fake up a preview that accurately represents what will happen when you apply them to a real object in a real wall, so we make the preview by actually creating a real object in a real wall and showing what the system really spits out. This entails some complex geometric operations with solids and sectioning solids, and it can easily get very slow if the preview object is too complex. We considered it essential to be able to update the preview without the user perceiving any delay, because having to wait for the preview to regenerate after each keystroke in the dialog would be extremely annoying. So keeping the preview object this simple also allows us to keep the dialog fast and usable.

This was an incredibly difficult part of the feature to design, because it has to be sufficiently general to work with not only our doors and windows, but also with every other door and window plug-in that exists, in countries where the settings are broken down completely differently and use entirely different terminology. This was the compromise that left everyone with something usable but was not ideal for anyone.

Basically, yes. It is something I would still like to improve if we have time, but that got less important with the new Vectorworks 2024 ability to define multiple wall closures for each wall/wall style. The reason is that that ability makes it far less likely that you will need to override wall closure settings for an individual insert. The intended workflow is that you will define all the closures you will need for a given wall style in the style itself. Of course there are always exceptions and one-offs, so we did not remove the ability to override the closure settings at the insert level, but you will notice we did remove the ability to override the wall style closure settings at the wall object level, because there is no real need for it, and having those multiple levels of overrides along with multiple wall closures would be incredibly confusing.

As Matt was alluding to, there is no way to indicate in the component or closure settings of a wall or wall style whether the insert location will be observed, because that is a choice made by each individual insert. In any given wall some inserts might be using the wall's insert location, some might be using the wall's closure's insert location, some might be overriding the wall's closure configuration with a custom one with its own insert location and using that, and some might be set to other locations individually. This can seem very complicated at first, but it makes a lot of sense once you figure it out, and you won't need to go digging into all these options every time. Think of it this way - a wall insert always directly controls its own insert location, just like it always did. You set that from the "Insert" field on the Object Info palette, in the familiar place. Additionally, any place you are defining a wall component structure (the main components or the wall closure settings of a wall or wall style), you can designate an insert location that makes sense and might be useful for that particular structure. But it is up to each insert whether it wants to use that or make some other choice for itself. The wall offers logical suggestions, but the insert itself is always in control, just like it always was. When you are editing a wall style, wall, or wall closure, all you are doing is editing those logical suggestions that the insert might or might not choose to utilize. That is why the preview of the insert object is generic in those places - because it is not any specific actual insert, but rather represents any possible insert. As Matt also mentioned, the one place this preview could actually be more realistic is in the Wall Closure dialog for a specific insert that is actually in a wall in the document. Since we have an actual wall and an actual insert, we could try to show the situation exactly as it really is in the document. I have experimented with this, and practically speaking it actually has some unexpected difficulties and works less well than you might expect in a lot of cases. But one thing we could do is try to set the the insert depth and insert origin preview options to automatically reflect the real insert as well as possible. In fact, we should already be doing this, I just haven't gotten it to work properly yet. But actually, the ultimate goal of this feature is to create a situation where you almost never have to go into the wall closure settings of an individual insert or dive into any of these settings while modeling. Rather, you set up your wall styles, you set up your door and window styles, and then you just drag them into different kinds of walls and they all get the right closure settings and insert locations automatically. We are not finished with this feature yet, and we've got some nice improvements coming up that should make all this even more usable.

I found the problem. It is fixed in Vectorworks 2023 SP4.

Wall, slab, and roof styles will definitely purge, but one thing to check is whether a style is selected in the preferences for that tool, because in that case the Purge command will not delete it. For example, if you create two wall styles, "WallStyle-1" and "WallStyle-2", and then you go to the Wall tool and select "WallStyle-1" in the tool's mode bar, then run the Purge command, it will purge "WallStyle-2" but not "WallStyle-1". And then any resources (materials, hatches, textures, etc.) used by that wall style will not purge. And then any resources used by those resources (hatches and textures of a material, for example) will also not purge. So that can leave quite a few resources unpurged. Could that be what is happening here?

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!

It would be good to have those eventually! How about for Vectorworks 2022?

Hello everyone, We have finally been able to find and fix this bug. See my post here for more information: @Christiaan

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

Thanks, Sam. We will take a look at this right away.