Jesse Cogswell

Objects that are attached to Walls (such as Doors, Windows, etc) are technically "contained" within those Walls. So if you hide your "Walls" class, the objects will be hidden as well, since their parent object is hidden. There are special rules around selecting embedded objects, as well. You can't select an embedded object if anything other than an embedded object is selected. Likewise, if you select an embedded object, you can't select anything other than another embedded object. Also, both the Wall and the embedded object must be able to be selected in order to select the embedded object. So if your Door and Wall are in separate classes and you have your Class Options set to Show/Snap, you won't be able to select the Door at all. To achieve what you are looking for, I would suggest using the Select Similar Tool. It looks like a "magic wand" in the Basic tool palette. Once selected, you can choose a wide variety of criteria. In your case, you'll want to select Object Type, then click on a Door object. All selectable Doors will be selected. I usually build presets for criteria by Object Type, Class, and Symbol Name so I can choose what selection type I want from the menu bar. And as a general rule, I almost always have my Class Options set to Show/Snap/Modify. Since symbols and plug-in objects can contain multiple Classes, having anything else is an invitation to frustration of not being able to select the things I want to select. The only time I change it is when I want to select "primitive" objects such as lines or text that I have in construction or guideline classes to delete them, otherwise it's Show/Snap/Modify all the way.

@LarryO While I saw a small performance increase from spacing out the hatches, the real issue is with your Lag Screw fasteners. For some reason VW has a really hard time rendering them in Dashed Hidden Line while inside Detail Viewports. In a post above, I found that if you Ungroup the screws and add the geometry with Model -> Add Solid, the Viewport rendering time dropped from 20 seconds to less than 1 second. It might be worth sending your drawing in to VW as a possible bug.

Unless I'm misunderstanding the wish, this is something Saved Views can already do, and is pretty much the only thing I use Saved Views for. Most of my Saved Views look something like this, with all view options unchecked, Active Layer set to Don't Save, and a group of Layers set to be visible or hidden and the rest set to ignore. You can't really make one Saved View as a toggle, so you instead need one for visible and one for hidden, but I find it to be pretty convenient. I usually only do Layers, with the way I use Classes I don't have to futz around too much with visibility, just setting visual overrides per Viewport.

I recently bought a Mac strictly for plug-in testing purposes. I was able to find a workaround for this annoying "feature". In terminal, type: xattr -d com.apple.quarantine <path to .vwlibrary file> For the path, I just did a click and drag of the BatchEncryption.vwlibrary file in Finder to the Terminal directly.

Fascinating. Going back to the original file, removing the Fasteners - (3D) class makes the Viewport instantly update, even with the overlapping polys (good find, @ashot). I don't have a ton of experience with the Lag Screw tool, and I don't recall ever running into this issue before, but the only objects using that class in the Viewport are the six Lag Screw - 3D objects in the M1 symbol. I went into the M1's Edit 3D Components view, selected the six Lag Screws and ungrouped them, resulting in each screw becoming a Sweep (shaft) and Generic Solid (head). I selected each head and shaft, used Model -> Add Solid to make them a single Solid Addition, then used Modify -> Convert -> Convert to Generic Solid to make each lag screw into a simple Generic Solid. Now each Viewport takes about a second to update. The MATERIAL - METAL New class didn't affect speed either way for me, though the material hatch isn't needed for these viewports since it only appears in the source objects of Extrudes, so you could probably make it Solid as a Viewport override. I think there may be something wrong with the Lag Screw - 3D tool when used with Dashed Hidden Line Detail Viewports.

I have a bit more time today so I have spent some time diving more into the drawing. These are the things that I found so far: On VW2026 on my Windows 11 machine, I could not successfully get a Dashed Hidden Line viewport to render with 3/E2, but I could get a standard Hidden Line no problem and pretty quickly. If I turned off the MATERIAL - CONCRETE class, it would take about 30 seconds but I could get a the viewport to complete the update. If I did a class override on the MATERIAL - CONCRETE hatch to a more simple hatch (I used the Cast Iron HF hatch), it would successfully complete. If I left the MATERIAL - CONCRETE class as original and turned off the Hatching class, the update would complete after 20 seconds or so. With these observations, I opened up the Model design layer by double-clicking the problematic Viewport and selected the Design Layer option. This opens the Design Layer with the same class visibilities that the Viewport is using. I think I have found your issue. You have two overlapping Polyline objects in 3D space, each with a hatch. One is in the MATERIAL - CONCRETE class, the other in the Hatching class. Because these are both occupying the same 3D space, it leads to something called "Z Fighting", where two objects are occupying the exact same planar space and VW can't tell which to render. It looks like this in Shaded view: When rendering in Hidden Line, VW seems to have little trouble with the overlap, letting the Hatching object win: But with Dashed Hidden Line, it tries to render them both, which is causing the hang. Here are the solutions: Turn off the Hatching class in the Viewport if it is always going to be cropped out. Delete the polyline object in the Hatching class if it is not needed. Use Modify -> Clip Surface to "clip" the Hatching polyline from the MATERIAL - CONCRETE polyline. Select the Hatching polyline, the run Modify -> Send -> Send to Front Select both polylines Run Modify -> Clip Surface In 3D space, move the Hatching polyline out from the MATERIAL - CONCRETE polyline by 0.1mm so that they are no longer occupying the same space. This allows both polylines to exist and the Viewport to update in Dashed Hidden Line: After moving the polylines away from each other, I was able to update all Viewports on the sheet. It took a little time (around 20 seconds for each Detail Viewport), but I think this has been your issue. If you run into any other Viewports that fail to update, be on the lookout for overlapping polylines. 9210 Constance House Sheet E2.pdf

Just tried this on VW2026 on my Windows machine. Took less than 10 seconds to export the PDF. I no longer have VW2024 installed on my machine, so I can't check that. 9210 Constance House v2026.pdf

I finally broke down and purchased a Mac for purposes of testing plug-ins. The issue in the Sync Worksheet to Record command plaguing Mac machines has been resolved. The updated version is attached and has been added to the Manager. Sync Worksheet to Record.vsm

One thing you might try doing is checking if the current view is Top/Plan using GetProjection(ActLayer) looking for a return value of 6. If not, save the current view with VSave, then set the view to Top/Plan using Projection, executing the draw code, then restoring the view with VRestore and deleting the temporary view with VDelete. Kind of dumb, but if it works it's a whole lot easier than trying to force a bunch of NURBS onto the right plane.

While I am very appreciative of losing the "Light Instr" prefix from the library symbols, I think the Equipment Summary Tool would benefit from having an option to choose which name is used, be it the Symbol Name, Inst Type, or Model Name. This would allow me less time devoted to making sure that all of the fields match for each of my fixture symbols so that my Summary information matches my Lightwright information. This could be achieved by a simple OIP drop-down menu for the Summary object itself. As for the Replace Fixture Type OIP button, it would be lovely if the pop-up at least filtered out Symbols that do not have the Light Info Record attached, so that I don't have to paw through every Symbol in the drawing to find my fixture type. I understand that this is a limitation of the generic Resource pop-up dialog, but it would certainly save me some time if it were implemented.

There isn't a way to do this natively in Vectorworks, though I don't disagree that it could be useful to add as a Symbol Option. One way you could approach this is to make a record format called "Don't Count in Worksheets" and attach it to Symbol Definitions that you don't want counted (and attach it to existing Symbols within the document). Then set your Worksheet formula to count symbols that do not have that record attached. This way, moving forward, when you create a Symbol Definition and attach the record to it, you don't have to update the Worksheet.

The function reference contains a section explaining which version the function was first implemented in. Any version matching or newer than that is completely fine. In my experience, Vectorscript has changed very little over the years, with relatively few "critical" changes. The bigger thing that you will need to be concerned with is that the scripts themselves will be locked to the version or newer that they are written in. This means that you will need to have VW2021 installed on your machine and be the copy that you write the script in the editor. If you edit that script in a later version, that script will be locked to that version. It's why I still have a copy of VW2019 installed on my machine. For menu commands or document scripts, this isn't a huge deal since you can copy and paste the script from one version's editor to the other, but it becomes a bummer for Plug-in Objects since you'll need to redefine all of the parameters each time, as @Pat Stanford pointed out.

I detailed the use of GetCustomObjectInfo last Sunday in the post above. It returns a boolean as a means of error handling. If you run the function on a document script or menu command, it would return FALSE. It's designed to be used by wrapping PIO specific code that requires the handles in an IF/THEN block, only executing if GetCustomObjectInfo returns TRUE. This prevents the PIO code from failing and potentially crashing Vectorworks. Some of the time, I use a throwaway boolean such as result:= since I know I'm running the function within a PIO. Or I'll use it in an IF/THEN statement for the first of the object handle, such as: IF GetCustomObjectInfo(objName,objHd,recHd,wallHd) THEN SetObjectVariableBoolean(objHd,800,TRUE); Which enables all text within the PIO to be handled by the Text menu, something I incorporate into all of my plug-ins that contain text.

Handles are the thing that I struggled with most when learning Vectorscript, but once it clicked, they got to be pretty straightforward. Handles are basically memory pointers that represent different elements of your drawing. Every piece of geometry, layer, class, symbol, PIO, everything, has a handle associated with it. This handle is what Vectorscript uses to determine what to manipulate. If you want to use SetFillBack to change the color of an object, you will need the handle of that object. Most of the time, you can use the GetObject function if the object is named (such as a symbol definition, class, drawing resource, or named object). Layers are the only thing that exists outside of the "shared namespace", which is why you can't have a class called "Door" while also having a symbol definition named "Door". In a more practical sense for what you are looking for, let's say you wanted to set the color of the triangle that your script creates. You would use the SetFillBack procedure to do so. To get the handle to your triangle, you could use the LNewObj function immediately after creating the triangle. You wouldn't even necessarily need to assign it to a variable, you could use LNewObj in the SetFillBack procedure directly, as in SetFillBack(LNewObj,0,0,0);. You would only need to assign it to a variable if you needed access to the object later in the code after creating something else, where it would no longer be the last new object. I'm sorry if I muddied the water with the "read-only" information regarding PIO parameters. For the script you posted above, it doesn't really apply. You can likely ignore the next couple of paragraphs and be perfectly fine (for now), but if you want to learn a bit more, read on. Let's say that changing a different parameter would necessitate forcing the includeTriangle parameter to false, you couldn't say PincludeTriangle:=FALSE;. I mean, you could, but nothing would happen. You would instead need to do something like SetRField(<handle to PIO>,<name of PIO>,'includeTriangle','False'); In this case, you would need a handle to the PIO itself. This is where the GetCustomObjectInfo function come in. You would need a string variable for the PIO name (such as "objName"), then three handle variables for the PIO handle (such as "hObj" or "objHd"), the parametric record of the PIO (such as "hRec" or "recHd"), and a handle to the wall the PIO is embedded in (regardless of whether it is embedded in a wall, I usually use "wallHd"). This is also a FUNCTION looking to return a boolean as to whether the resulting object and record handles actually exist, so you might need an extra boolean variable (traditionally this would be something like "result"). For the sake of example, let's say you had another variable that wanted to report on whether or not includeTriangle was checked. We'll make it a static text parameter called "triStatus", defaulting to "No Triangle" and changing to "Triangle Drawn" when includeTriangle is checked. The code would look something like this: PROCEDURE RandomGeometry; VAR includeTriangle, result:BOOLEAN; objName:STRING; objHd,recHd,wallHd:HANDLE; BEGIN includeTriangle:=PincludeTriangle; result:=GetCustomObjectInfo(objName,objHd,recHd,wallHd); IF(includeTriangle) THEN SetRField(objHd,objName,'triStatus','Triangle Drawn') ELSE SetRField(objHd,objName,'triStatus','No Triangle'); Rect(0,0,144,144); Rect(144,144+72,144+72,144); ArcByCenter(144,144,36,0,360); If IncludeTriangle THEN Poly(144-36,144+72,144+72+36,144+72,144+36,2*144,144-36,144+72);{Triangle} END; Run(RandomGeometry);

This post details how to get parameters from the Object Info Palette. Basically, you need to make your script through the Plug-in Manager rather than a document script, specify the type of the PIO (Point, Path, Rectangular, etc), then add the parameters in the Parameters tab of the Edit Definition dialog box. To access those parameters, you would need to place a capital "P" in front of the name of the parameter in the script. In your example, assuming you had a parameter named includeTriangle, you could say IncludeTriangle:=PincludeTriangle;. Keep in mind that this is read-only, you have to use the SetRField function to change an object's parameter values, which requires GetCustomObjectInfo to get a handle to the PIO and its parametric record.