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.