Gilbert Osmond

I had a very interesting / concerning episode with annotations in a viewport. System: Mac OS X Mojave 10.14.5, MacBook Pro 15" 2017, internal display only. (No eGPU.) VW Designer 2019 SP4. Summary: Seemingly random/strange crash, followed by weird SBOD (beachball hangs), eventually seemed to be fixed by temporarily disabling network /WiFi while running VW. Unfortunately cannot reproduce or thoroughly document; sequence of events / attempted fixes too long & complex. Details: While moving a normal 2D object (just a simple overlay) in the Annotation layer in Top/Plan in a viewport, VW 2019 SP4 abruptly quit (entire app crashed out & disappeared, no hanging or delay.) This object had been added earlier in the day (a few hours) and was working as expected up to that point. (Move / adjust size / opacity / etc.) Upon re-opening the same doc, the app crashed in the same way. I figured the file itself had been corrupted. So, I opened a recent auto-created backup of the same file (~15 mins earlier) and got the same behavior. A hard crash. I tried rebooting and chucking out VW cache folders but that made no difference. I downloaded & reinstalled VW2019 from VW Service Select. That fixed the hard-crashing problem, but curiously, now these same files worked fine in all of the many (40 or so) sheet layers & viewports in them, but on the "problem" viewport, when I attempted to edit annotations, instead of a hard crash I would get a seeming SBOD (spinning beachball of death) hang. After poking around on the forums here I tried doing the "Refresh Library" command in the Resource Manager, along with turning off Wifi for a bit, and this seems to have completely fixed the problem. The viewport annotations in question now work as they ought to & there is no more "hanging."

It's a bit of a round-about path to get to my real underlying goal & wish here, but the reason I've inquired about this is that when I use a linked field (in the new 2018/2019-style "Title Block Border Settings --> Edit Style --> Title Block Layout" editing area,) I want to be able to link the text parameter "Title Block Border.Sheet Size Name" to a field in my Title Block and have that field display correctly when I select a non-standard paper size. For example, I do a lot of small US LETTER and US LEGAL-size drawings and details and I would like the "Sheet Size: " to appear as "US LETTER" in my Title Block, rather than having it default to displaying the actual measurements 8.5" x 11", which is what it does now if there is no named preset paper size corresponding to the actual measurements. So I was hoping to add a "US LETTER" and "US LEGAL" sheet size definition to the overall VW default paper sizes and thereby fix this problem. --- As a work-around I've been manually entering the sheet sizes in a custom-added field in the Title Block Manager on a per-instance (not per-style) basis but this is getting unwieldy.

Thank you, that does allow me to add page sizes in the Title Block Border Settings dialog box. What puzzles me, though, is that the new sizes I created do not show up in the regular Page Setup dialog box. Is there a way to edit this list of paper sizes as well? I already went in to Printer Setup... and selected "Any Printer," then returned to this screen & hoped to see the full list of paper sizes, but it only shows a truncated list. (Screenshot from Vectorworks "Page Setup")

Where can I add/edit/delete VW's default Sheet Sizes? For example, if I want to add MySheet X, MySheet Y, MySheet Z to the drop-down list in the screen shot below, how do I do that? I've spent 45 minutes reading VW Help, searching this forum, & digging through the VW system folders looking for defaults. Thanks in advance.

Bumping this feature-request. Trying to do a section viewport including a DTM and it's a complete fail. DTM portion is opaque & shows no sub-surface details, e.g. footings & posts for a fence in this case. Need option in SVP to control how objects appear when a DTM is included -- totally hidden (as they are now,) or totally exposed (showing only the ground surface line of the DTM,) or dashed-hidden-line render below the DTM surface.

Now that VW supports multiple views / windows / open files at once it would be nice to have a way to force referenced design-layer view ports to update in real- or near-real-time. As it is now, when I make a change in referenced file (say, moving the height of a fence panel,) in order to see the change in the other file with the DLVP in it, in the main file I have to do: Tools --> Organization..., then select the "References" tab, then select the referenced file, then click "Update", after which the changes propagate from the master file to the DLVP. It'd be nice to have a check-box in a DLVP for "Auto-update this viewport whenever the referenced design layer changes." Is there any work around for this? Editing the workspace doesn't work as it doesn't allow for auto-navigation within the "Organization..." modal dialog box, nor for assigning a shortcut to the "Update" button in that dialog box. EDIT: this should be posted in General -- moderators, please consider moving it. Thanks.

I've delved further into this issue. It appears to be an oversight in VW's development process, i.e. someone simply forgot to include the "Existing/Proposed" toggle in the parametric Hardscape object. - I called VW support & a tech reproduced the issue. - We tried to work-around by attempting to right-click and Edit the internal properties of the Hardscape object, but to no avail -- there's no way to display or edit the Site Modifier object that is presumably hiding somewhere inside the Hardscape Object. - He said he'd double-check with other support staff, then submit this as a feature request / functionality fix for a future update. Attached are screen shots: The Site Modifier object can be set to apply to the Existing, or Proposed site model. But the Hardscape object cannot. (!) The work-around is clumsy: Set the hardscape object to be a Slab (which does not modify the site,) then copy the hardscape object shape, paste it elsewhere, Ungroup it & remove any slope tags, then use Create Objects From Shapes... to create a Site Modifier object from that hardscape object shape, then configure the Site Modifier object slope(s), & apply to Existing/Proposed site model setting, then move the Site Modifier object onto (aligned with) the Hardscape slab object & group the two together. When dealing with 10 or 15 slabs across a model this is time-consuming & a nightmare, esp. if any of the Hardscape Object slab + Site Modifier groups need editing. Requires temporarily Ungrouping the group, editing the Site Modifier object only, regrouping, etc. Attached screen shot shows where the "Existing / Proposed" exists in the Site Modifier OIP, but not in the Hardscape OIP. I can't believe more people haven't complained about this. How does anyone sanely model an as-built site without being able to use Hardscape objects and have them apply to the existing site?

I am bumping this topic -- I'm running into the same problem, in a different project, 1+ year later. What am I misunderstanding here? Is there some reason why Hardscape objects can only apply to Proposed site model, rather than Existing site model?

SOLVED -- yes, somehow just that facet of the roof had lost its fill color in Top/Plan. Fixed as follows: - Go to Top/Plan - Select the entire roof (1 click) - Use Attributes panel to set fill to None. - Then set the fill to a solid color. - Then set the fill to a hatch. After that, the Class *tile* fill becomes properly visible again in 3D OpenGL view.

The dormer is "part of" the roof, i.e. it was added there automatically using VW's built-in dormer-creation feature. It is not a separate 3D object. Strangely, when I select the whole roof, change the fill to a solid color, then try to change the fill back to the proper tiled fill (i.e. what it looked like before,) I now get a *reversal* of the effect. The whole roof becomes transparent, while the dormer is properly tiled (!). ?? Still lost here.

Previously this roof was properly displayed, with the same tiling on the dormer as is visible on the rest of the roof. At some point recently (I'm not exactly sure when,) just the dormer went "transparent" and I don't know how to fix it. This happens in OpenGL and in Shaded Polygon modes. In Renderworks it renders normally and properly. How do I get the dormer faces back to the same texture / opacity as the roof? Trying to re-apply using the Attributes panel has no effect. Hints please? Thanks.

Fantastic new feature greatly improving the flow of usable information from the designer/architect to the client and/or other collaborators on a project. Teaser Tuesdays is a great feature itself -- far better to *show* new features in action, rather than just dumping a text-only list of bullet-pointed features that aren't seen until product release. Way to keep us all interested & keep our faith up for paying annual Service Select costs. (I mean that earnestly, no snark.)

With this feature + the multiple-views-simultaneously feature I feel reassured that my yearly Service Select subscription funds are being put to good use. It's neat to see advanced BIM, Energos, 3d point cloud & so forth, but these more basic every-day workflow features are just as important. Glad to see they're getting implemented.

Thank you, exactly what I was looking for. Case closed.

Still can't find a list of changes / fixes with VW2017 SP1.