Jump to content


  • Posts

  • Joined

  • Last visited


69 Excellent

1 Follower

Personal Information

  • Occupation
  • Location
    Santa Barbara, California, USA

Recent Profile Visitors

2,371 profile views
  1. This happens to me as well. I see this discussion started quite a while back. Has there been any resolution to this issue? On a related note, I was initially searching for posts involving an issue where some doors or windows simply won't accept data tags (in other words, they won't recognize any door or window data, and therefore won't light up red) when using data tag in the annotation layer of a section viewport. It's a small percentage, but it's causing the overall data tag workflow to fall short. Any tips, or general rules on what might cause some doors and windows to not accept data tags, when neighboring doors and windows (with the same style) work just fine? It seems random to me. Thanks, Matt
  2. I had been wishing for this tool before running into your post a while back, and was impressed by your particular solution. The ramifications of this proposed tool enhancement should not be underestimated. It would run deep and wide, and should really be looked at carefully. The complexities associated with integrating wall assemblies with both code requirements and finish requirements is unavoidable. By not addressing these complexities with a flexible solution, VW forces us to rely on incredibly complicated solutions instead. Just because something is complex does not mean it needs to be so complicated and difficult. Complexity + flexibility = less complicated
  3. @Jonathan Pickup, what exactly is "back referencing for details"? I'm not familiar with this term. Personally, I'm waiting for VW to address detailing in a big way. I'm thinking we need an entire "Detail Manager" system to deal with the many layers of complexity here.
  4. @Tom Klaber, You also forgot Walls with interchangeable assemblies! ...this is a game changer IMHO. As good an idea today as it was 3 years ago.
  5. sorry, not yet. I'm currently working on 2017-2019 projects and have not had the opportunity to begin anything in 2020 yet. I'll let you know when I begin exploring these new features, but I bet others will beat me to it.
  6. I think it's safe to say that this discussion should be put on hold until we all look into 2020's new Data Management feature, as well as the significant improvements 2020 has brought to Data Tags.
  7. Yes!!! Thank you for this one! I've been very envious of Autodesk's ESRI integration for the past couple of years. I'll for sure be putting this feature into practice on my first 2020 project.
  8. thanks for bringing this up @martinfdc! I have been trying to make greater use of custom records and worksheets of late, and am running into the same basic issue. My work around has been the use of housekeeping summary worksheets like the ones mentioned above. I've even done the "stand alone record supplement" idea that @Pat Stanford suggests. The problem is they're just workarounds, and not solutions that help us get to greater levels of automation insofar as our database management needs are concerned. Architects are overpaid and under-qualified to spend so much time on database management. The fewer steps the better. If I knew how to write my own scripts, I'd probably explore that option as a more automate-able solution to the worksheet workaround. I can imagine being able to select the specific symbol with the up-2-date record, and then run a script that finds all the identical symbols, and then updates their records to match the primary one. Or, alternately, i'd be happy to have the feature @Amorphous - Julian suggests be added to the 'Edit Record Format' box. But I think we can take it even further... It doesn't need to be just about symbols. What about any set of similar drawing elements that are intended to share the same record values (like polygons for example)? I would like to see another check box for 'Constant Value Across Matching Selection Criteria', that - once checked - allowed you to define any drawing object attached to a record in terms of a series of custom selection criteria. Then the whole set of similar objects would receive the same record values whenever a single instance was edited. This would essentially create a fully automated process in line with some of the work arounds mentioned above. Matt
  9. Despite the perfectly valid work around suggestions, I fully endorse the addition of a TRUE construction line tool. I used this all the time in AutoCAD, and greatly mourned it's absence when I switched to VW (6 years ago). Just study what ACAD has and copy this feature please! It's a lot better than the multistep class based guide system that VW supports. We need to be moving away from time spent managing classes in any way possible. Matt p.s. What's 3rd mode???
  10. Ok, here's what I mean... I've got a record that tracks all things related to Lot Coverage. One of the parameters in this record is "Type of Area". And one "Type of Area" is "Driveway or Parking" I've got a worksheet that breakdown all the Lot Coverage areas by category (aka: separate data base header row). One of the data base headers is "Impervious Vehicular Areas". To tabulate this category, I need to call up ONLY the "Driveway or Paving" value. Looking at the screenshot below, when I use the equal sign (=), it calls up ALL 53 "Type of Area" values. The correct answer should be 0, because there are no Driveway or Parking surfaces on this particular site. I can correct this by making 2 criteria entries relating to "Driveway or Parking". I add a "<=" row and then a ">=" row, essentially eliminating all values other than "Driveway or Parking". So this is why I suggested we needed an 8th boolean connector: "><", which is just a combination of the 2 separate connectors I'm currently being forced to use. So, maybe I'm doing something wrong, but based on my experience, the criteria process needs to be told what values NOT to include in order to isolate individual values from a list of possibilities. If you look further up the list of criteria in the screenshot above, you can see this same issue is apparent with my True/False (0/1) values. Instead of stating "=0" to call up only False statements, I actually end up being forced to use "<>1" to instead eliminate all the True statements from the list. To quote Tone Loc, Something's not stirring the cool-aid Ace. Thanks, Matt
  11. @Pat Stanford, what would really be helpful (maybe this is a wishlist item), is the addition of ONE more option in the list of boolean pull downs that get selected during criteria editing. Currently, there are 7 filter options: {=, <>, <, <=, >=, none} We could really use an additional 8th filter: >< ("ONLY equals") Which would be a way to override the automatic "and/or" determination issue I'm always wrestling with. Currently, if I have a long list of options for a specific criteria, and I want to narrow it down to a single option, I'm often forced to make an equally long list of criteria excluding each of the other options in the set I do not want to be included. This is because I'm stuck with an OR connective between criteria, when I really need an AND connective. If there were an "only equals" filter (><), this would serve the same purpose. Matt
  12. Seems promising, but does this relate at all to working through schematic options of an entire building concept, or is this just for prototyping individual components and assemblies?
  13. True this works, but this is exactly what we USED to do before the on/off switch for wall components was added, so this would really just be moving backward, and re-introducing an old work-around. I'd hate to have to settle for that. My vote is on moving forward towards a more refined system.
  14. Great point @Jim Smith. It might still be best practice to ID doors and windows directly on the model (DL). Same goes for anything else that is meant to display in many viewports. Advanced viewport settings can negotiate this fairly well. I hate to introduce extra classes, but perhaps in a squeeze, you can turn off the ID class from the design layer in order to add an alternative annotative layer ID class. It would be great if there were a similar function to "section line instances" built into Data Tags, which would allow you to simply "turn on" an independently controllable group of tags per viewport after the initial tag creation.
  15. Nope...that's not what's happening in my file. The criteria seem to be on some kind of "automatically reorganize" setting. Not only does it reset the boolean logic, it also automatically stacks multiple instances of the same criteria on the list regardless of the order in which they were entered (which isn't a problem in and of itself, but it may help explain what's going on)
  • Create New...