Jump to content

Boh

Member
  • Posts

    1,567
  • Joined

  • Last visited

Everything posted by Boh

  1. Another, possibly better, but with it's own limitations, technique to repeat geometry over a number of levels in a multi story building is to use design layer viewports instead of symbols. I have used this successfully and haven't had the issues with wall heights. To do this you create a "base plan" and then create dlvp's of it, one for each repeating level. I would suggest putting each dlvp on it's own design layer and use the design layer elevation to control the height of the geometry so that the z height of the actual dlvp can stay at 0 in relation to it's dl. Ask for more detail if you are interested in trying this out. Cheers
  2. Yes the section line itself has to be the same for every defining section line. Ive used the data tag technique where I wanted to have the marker off the line due to crowded annotations so haven’t had to fiddle either the line I agree with you re viewport naming. Vw should have a better way of naming vps that use the sheet no, drawing number and drawing title. I rely heavily on a script to rename vps for the very reasons you outlined in you post above..
  3. When you say “link” I think you are talking about section elevation lines which “define” section vps. Ie the line length and location defines where the section cut is made. VW uses the term “link” where a section line is simply linked to the section vps sheet and drawing numbers. Ie moving the section line has no impact on the section vp. If you draw a section line and instead of creating a vp from it, where the section line will then “define the vp”, you can instead just link it to an existing vp. So for question 1 I don’t think you can “undefine” a section line from a vp but instead of ungrouping it you can trace another section line over it an in the oip and just “link” it to the section vp. Then delete the original section line. The linked line and markers can be moved around without changing the vp. For question 2. Yes the section line markers will all be in the same place for section lines which “define” a section vp. If you want section markers in different spots you could do what I suggested for question 1. Another option which I have used, and which might answer your follow up issue is to use a section elevation line style that has no markers, then use data tags as markers. Then only the section line itself will define the vp but the marker tags can be anywhere you want.
  4. I can't find a way which makes me wonder what the "Standards" folder is for specifically? The other folders contain default content that various tools can draw on. What tool uses the Standards folder?
  5. This is what I do and it's a great way to keep your class standards tidy. You could create a symbol with geometry in the new classes and export the symbol to the standards file. With a create symbol shortcut key it've very quick to turn a line into a symbol>locate symbol in RM>Export. Yes it would bring the classes in but, and I need to check, maybe not any hatches, textures etc associated with that class unless the wall used class attributes.
  6. Tools>Preferences Might be in the display tab. It’s a n there somewhere…
  7. I have encountered other bugs sections through DLVPs. I’m not sure if this is a bug though. Can you post or pm me the file?
  8. Yes! I've done that too and created a whole bunch of custom selection scripts for various common objects like lines, circles, spaces, text, etc etc and made them all commands in custom menus. Another advantage of making them commands over resource scripts is that scripts in the RM are file specific whereas commands are available to use on any file. One thing I do like with palettes though is that you can have them right next to where you are workin,g which is what I do when I am using them a lot, and when finished you can switch them off. I have a bunch of scripts in custom palettes in our drawing template files. Thanks for the reminder about the quick search function. TBH I had totally forgotten about both that and the smart options display. I'll have to try and start using them in my daily workflow.
  9. Yes quick ways to do repetitive tasks are definitely worth the time to set up! There are at least a few ways to make scripts in VW without having to know how to actually write them. When you make the script you need to stick them in a palette. If you don't have any custom palettes then VW will ask you to make one. I've made a few scripts to place objects in certain classes. This is one which will place selected objects into the "None" class. To customise it for other classes you just need to replace "None" to "Whatever is the name of the class you want to place the objects in". Procedure SetTheClass; CONST kCName = 'None'; VAR gh1 : HANDLE; Function DoIt(h1 : HANDLE) : BOOLEAN; BEGIN SetClassN(h1, kCName, True); END; BEGIN Locus(0, 0); gh1 := LNewObj; ForEachObjectInList(DoIt, 2, 2, FInGroup(GetParent(gh1))); DelObject(gh1); END; Run(SetTheClass); I You can use quick search toggle custom script palettes on and off. You would still need to click on the script you want. Hope this is helpful in your efficiency drive!
  10. Once you get to the "Attach Record" dialogue, as described above, put a tick next to the record you want to attach and with that record selected hit "Edit values" The data you input will now replace the default record field data and will be inserted into the file with the symbol.
  11. Not sure I understand what’s going on but I think you either need to make sure when you place a symbol you are getting it from the active file not the version in the workgroup which doesn’t have the updated record info. Or you’ve only edited the record info attached to symbol instances not the symbol definition. If you edit the info to the definition then it will be attached to the symbol when you insert it in your dwg. To edit or add info to the definitions right click the symbol in the RM and select “attach record”.
  12. This one is handy as it saves a lot of scrolling through the class drop down list in the oip. Another trick is to use scripts. I have some for commonly used classes that simply place the selected object in a specified class. Then there is also the custom tools command where you can create scripts to draw an objects and also have them placed in specified classes. Below is a bunch of scripts I created for drawing 2d details. All the objects take on the class attributes so it makes drawing details very quick.
  13. I use the eye dropper tool all the time for changing an object’s class. There just needs to be another object nearby already in the reqd class. I’ve even changed the shortcut key for it to ‘E’. Another way is in the nav palette. Right click on the class and select “assign to selection”.
  14. This is an interesting idea and one I haven't tried out myself. I'm sure there are others out there that work in this or a similar way who could provide some advice. I am wondering though if the plot files would be able to "read" data attached to objects in the design files? Can data tags in a plot file viewport annotation attach to an object in the design file? Can worksheets in the plot file report on items in the design file? Would referenced design layer viewports be used or old style layer referencing. If old style design layer referencing needs to be used to read data then does it save much in file size? What are the advantages with this if there are multiple people working on the project? I guess one person can be working in the plot file and others in the design file(s).
  15. There is an OzCad video that explains how to link spaces to WinDoor objects. And another showing how to list doors and windows in the same schedule. They might be helpful. They are available from the OzCad website
  16. So just did a test using the revised script to rename a single selected viewport on a file with ~40 viewports including dlvps and it took about 2 seconds, ...then a test on a file with ~200 viewports including referenced viewports and it took just on 1 minute...
  17. I’ve come across this before and the short answer is, as suspected, you would need seperate referenced dlvps for each condition. My workaround is to have a dedicated dl for each dlvp. You can then just duplicate the dl and adjust visibilities as required.
  18. So now you know just enough to be lethal! 🙂 I use these scripts all the time. It’s crazy vw doesn’t have an in built vp naming tool. I did notice the delay in larger files so will try the tweak you mentioned earlier. Thanks
  19. Sorry I didn't get this bit! How did you call up this record in a worksheet? I'm wondering if something changed between v2019 and v2021 as I've made data tags for title block sheet data records before but don't remember having this problem finding the record.
  20. Hey @Nikolay Zhelyazkov The other day I was trying to make a data tag that referenced sheet data but couldn’t find the records in the edit data tag dynamic text dialogue. Can you direct me? Thks
  21. Hey Melanie. Pm me the files. Will try tmrw.
  22. So my take out from this thread is that I've just realized how little I use the attributes palette as I only use it to occasionally tweak the attributes of already drawn objects which had all their attributes determined by class at creation. So going forward I think I won't even display it in my workspace and just use a shortcut keys to call it up when needed. More valuable screen real estate for the OIP (which will hopefully one day display the object attributes as per @lineweight's suggestion). 🙂
  23. Oftentimes vw users want to deploy the same methods they used in other software. That way of working was probably developed because it suited the way the other software worked -but may not suit vw. The challenge for you, being a new user, may be to figure out the best way for you to convey this sort of info in vw. I also do multi unit/floor developments with a lot of repetition of doors. As you do, I have symbols for the unit types. For the doors however I simply give all doors which are identical the same number. No floor or room info needs to be in the label as this is evident from the drawing title and unit label. In this way of working, with lots of repetition the schedule worksheet only needs to identify the different types of doors and how many of each type there are. So a hypothetical six storey hotel development that might have 12 units per floor with 4 unit types and say 3 doors per unit. I.e. 216 individual doors would only have 12 or less different types of doors that need scheduling. The inclusion of a “count” column in the schedule worksheet is all that’s needed to show the number of each door type. This is the way I figured out how to schedule doors in mult unit developments. Others will have figured out other, probably better ways that work for them.
  24. The room numbering could be made of two seperate text blocks. I.e. the prefix, linked to a user field space record, and the number, which should then auto increment. Put them next to each other in the label with the prefix right justified and the number left justified.
  25. I guess, as is often times with vectorworks, there is always more than one way to skin a cat. For my work flow using class attributes extensively and the "use at creation" setting activated allows me to ignore the attributes palette for about 80-90% of my work. In fact the default attribute palette settings don't matter at all to me. Having both "use at creation" and "by class" attributes palette defaults I think this is just a way of VW accommodating different workflows.
×
×
  • Create New...