Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

3 Neutral

About VellumDesignBuild

  • Rank

Personal Information

  • Occupation
  • Homepage
  • Hobbies
  • Location
    United States

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Thank you, Pat. That edit cleared the error out of the formula, but at first, I could not get the equation to recognize which doors were pocket doors. I suspected that the configuration was not "pocket" since none of my pocket doors end up with different values. I tried 'slider' to see if the equation works and it did, so I knew the issue had to be with the name of the door type. I tried 'pocket.simple', 'pocketsimple' just guessing as to what the correct name is for that door type, and realized that I needed to include the space between "pocket simple' As easy as that was, it took me quite a bit of head-scratching to get it to work. The good news is that I also now have the POI script you created and shared, and that is working perfectly. The script did not drill down into the deeper aspects of the door configuration types, but does provide a huge list of the POI info needed for worksheets. All in all, I want to thank you for your help and time. Have a happy new year. @SMannVW thank you as well, you pointed me in the right direction. I think that the Mac vs PC criteria are slightly different, which is why your formula worked for you.
  2. Thank you Scott, I tried this method and the schedule did not populate correctly. I get #NAME? Any ideas?
  3. Does anyone know how to get a pocket door to account for the pocket portion of the door in the door schedule? Currently when I add a simple pocket door into a wall, the door schedule only accounts for the door slab, door jambs, and shim gaps... this is fine for swinging doors, but not pockets, since the RO width needs to account for the pocket, which is usually the door width +1 inches. For example a pocket door with a 2'-6" x 8'-0" door slab should have an RO width of 0.25 shim gap + 0.75 jamb +30 door slab +31 pocket = 62" total RO width. I have the a similar issue for the RO height, but I can account for the overhead track by using a z offest in the theshold dialog. Still... I wish there was a better and more accurate way to do that. For a pocket door, the RO hieght should be about 4" greater than the door slab size. Any help would be greatly appreciated. Software Versions VW2021 and VW 2020
  4. John, It sounds like you may have checked a setting box at one time that disables some features of the ungroup command. Go into our Vectorworks Preferences (Tools > Options > Vectorworks Preferences), and then into the Session Tab. In there, you can choose the Reset Saved Settings option, which will reset that.
  5. There should be a scroll bar on the right side of the window/tool palette. You can also use yor mouse wheel to scroll vertically in the window/tool pallete.
  6. Hello Ted. Glad so see that it works for you too. I sure wish you posted the solution. I am able to get the jamb down to the slab. see images below.
  7. Hello Ted. After looking for a solution to this same issue since 2001. I think I have stumbled upon a cleaver solution, which is working for me.😃 Here is my goal and what I needed to achieve. I think we were trying to achieve the same goal. I have a 36" wide x 96" tall interior door (these are the dimensions of the slab) with a 0.75" jamb and a 0.25" shim gap, VW calculated the ROs to be 38" wide x 97" tall... which is not how doors are made. Needless to say, GCs love our Nominal Size info in our schedules (very easy to order from) but the Framers in the field were very frustrated with the RO info in our schedules, which always undersized the door RO heights. Your idea of using a threshold made perfect sense to me, since we needed to account for the 1" air gap below the slab that is standard in the USA. Thresholds are added to the door height, not removed from the slab height. Straight to the point, here is the solution that is working for me. (VW2020) I changed my database header of my door schedule to the following: =('Door'.'ROHeight')+('Door'.'ThresholdZoffset') Then in the door object, I checked 'include threshold', set all values to 0 and made the Z offset 1" Then I re-calced my worksheet and it worked perfectly. And of course, here is the long story. The hardest part for me was trying to figure out what to put in the database header. I initially tried =('Door'.'ROHeight')+1, to see if adding a number up there would work. It did, but that added 1 foot to the RO height (not 1") and it applied to all doors. I switched to 1/12 to convert back to inches but it still added the value to every door, which was not my goal. But at least I got to understand the logic of how the worksheet was thinking. I then tired to use a one of the user fields to see if I could pad the number by 1", but the worksheet would just show #VALUE!. grrrr. clearly it did not like the equation =('Door'.'ROHeight')+(Door.UserFld1) and it took me a while to figure out why. The after about an hour of seaching, I discovered that ('Door'.'ROHeight') is a dimension field in the object where as (Door.UserFld1) is a text field in the object. You can't add numbers to text, even if the text is a number. Go figure. So then I looked back at the threshold info in the door object and figured some of those values should work in the database header, but only if I could find out what the heck they were called. I did a little forum searching and saw that Plug-in Manager offered some clues. Drilling down into the door object, I saw that there were some parameters related to thresholds that were 'dimensional' fields. I tried ThreshNose as a dimension type, and sure enough it worked, as did ThresholdZOffset. The Names are the same as the criteria for the database headers. All in all it took a few hours to figure it out, but your initial post really helped me look deeper for a solution. I went back to VW 2018 and sure enough it worked in that verison too, so I am a bit frustrated that it took so long to figure this out, especially knowing that a solution existed all this time. Thank you for the original post. Let me know if this solution works for you.
  8. That seems like a useful prompt, and one that would probably be easy to implement.
  9. Vectorworks got back to me and here is what they did to get things to ungroup. 😃 It seems like I set up a bad default setting at some point. After resetting the default, I was able to get things working again.
  10. 2D objects in the design layer. Simple objects like rectangles with fills and hatches. Old school 2d exterior elevations.
  11. I can replicate this about 50% of the time. Not sure where the bug is, but have just grown used to going into the group and copying what I need. then exiting the group, delete the group, and then paste in place. Huge time suck. Very reluctant to move projects to 2019. I was very excited for SP3, but still, the issue remains. I emailed tech the file to see what they say. 1. Draw a bunch of stuff. 2. Make a group of stuff 3. Copy the group 4. Paste the group 5. Try to ungroup group… not working. ☹
  12. This is still an issue with 2019 SP3. Still waiting to better updates before moving the office over to 2019. Less bugs with 2018, so I'd convert back down and work from there.
  13. Is anyone else having issues ungrouping groups? I have tried shortcuts and using the ungroup function from the toolbar but I can not get grouped items to ungroup. My current workaround is to go into the group, select all, copy, exit group, delete the group, paste in place. Ironically, I can ungroup exploded object/symbols. My issue only allies to groups I create. Does anyone know what the issue is?
  14. Jim, Thank you, I appreciate the dialog. Can someone post a example of a methodology in favor of the current callout behavior?
  15. Thanks Jim. There is another way to formally report a bug worth mentioning, which I found after making my initial post. http://www.vectorworks.net/support/bugsubmit I did just get this message from Vectorworks this morning after submitting the bug, see below. They say isn't a bug. They say that the callout is behaving as intended. If that is the case, can someone help me see the advantage to this behavior. In our office, we duplicated an existing keynote and then edit it. Unfortunately this causes havoc in the legend, But I am open to changing my methods if I can understand the benefit. I am always looking to improve our standards. ************ I believe this may be working as designed. Since the note was copied, both the description and the note text are duplicated. However, if you edit the note text, the 42 character option is disabled, to preserve the note description. If you create a new callout without copying an existing note, the 42 character option is enabled. Thanks. MICHAEL GROVES SENIOR TECHNICAL SUPPORT SPECIALIST ************


7150 Riverwood Drive, Columbia, Maryland 21046, USA   |   Contact Us:   410-290-5114


© 2018 Vectorworks, Inc. All Rights Reserved. Vectorworks, Inc. is part of the Nemetschek Group.

  • Create New...