Jump to content

ericjhberg

Member
  • Posts

    581
  • Joined

  • Last visited

Everything posted by ericjhberg

  1. This is because the Sheet Numbers read as text and not as numbers, which is essential to include your prefix. I have run into this issue myself and I have a workaround... Open the Titleblock Manager (File > Titleblock Manager) Go to the Sheet Data Section Click on Manage Sheet Data Add a record field...Drawing List as a text style format This record will likely never be shown in the titleblock visually, but can serve to help you sort out which titleblocks go where in your worksheets Using a "Master Worksheet" designed to pull in all of your titleblocks, add a column for the Field 'Drawing List' and start to populate each sheet with the corresponding A, B, C... You can then redesign your two drawing list worksheets criteria to look for values that = A, B, C... etc. Hope this helps.
  2. I can't say it any better than those on this thread already have...you'll be greatly missed. Best of wishes to you! -E
  3. Already using one...doesn't work. This only happens in VW2018. Doesn't happen in 2016, 2017, or 2019. Its strange.
  4. Fair enough. I don't disagree. However, you fail to convince me that it, at the very least, shouldn't be an option.
  5. @John Meunier Not that I am aware of...but this is something, along with general Text handling, that VW desperately needs. ALL CAPS is industry standard for construction documents and has been forever. Needs to be implemented ASAP!
  6. @DonnaS Yes it does, though it is a somewhat limited suite. That said, I only own landmark and was able to design a complete (albeit basic detailed concept) structure with it. The walls, windows, doors, and the roof tool all work in Landmark. I just hope it stays that way.
  7. We do, but mostly they sit off to the side in the background and are used solely for organizing callouts. Occasionally we will use them for basic callout functions, but we primarily use worksheets to organize and build our legends.
  8. @Boh We use this system extensively and it works fairly well with very few snags. If you alter the 'Callout'.'Text' field from the worksheet for a callout with text that was defined from the database, it will break that reference to the database. This hasn't really been a problem since the database doesn't affect the callouts after they are created...rather the database becomes useful for populating callouts, but not necessarily for maintaining them. When using callouts as keynotes, there is another way to pull in the Keynote ID# that you may not be aware of. You can add a column, pulling in the field 'Callout'.'__Keynote Number'). Note that you cannot change this field from a worksheet, only by reodering the keynote legend. That said it is a useful tool. We actually use this system to build all of our legends in our documents. They are all based on the callouts, not on the objects in the drawing. It has been a great way to streamline our document creation. It should be noted that this workflow will likely become null and void once we get comfortable with data tags, but for the past few years it has worked pretty well.
  9. Done! Congrats @Jim Wilson
  10. I don't disagree, but we have found that worksheets have been profoundly beneficial for other reasons too. They allow you to control massive amounts of data in one location and can be turned into legends and other reporting tools if need be.
  11. @Jens Marr You can create a database header in a worksheet that will pull in all of your callouts. From there you can add columns for the Prefix ('Callout'.'Keynote Prefix') and Suffix ('Callout'.'Keynote Suffix') and adjust them from one centralized location. You can re-add or adjust the keynote prefix as you need. The tricky one is how to return the ID#. Thanks to @Pat Stanford, he put me on to the field ('Callout'.'__KeynoteNumber') to pull that in. Note you cannot change the number of a callout from the worksheet, that has to be done in the associated Keynote Legend by re-ordering the callouts.
  12. This one has been bothering me for a very long time! Since VW2018 was released, my saved workspace will not save entirely. Essentially I have a double stacked group of tools on the left side of the screen that I prefer. In VW2018, every time I open the software, it reverts back to a collapsed version of this sidebar configuration. This only happens in VW2018. It has never happened in prior versions, and it appears to be fixed in VW2019. If VW2019 wasn't riddled with bugs and we weren't pulling back from implementing it in our office, I wouldn't mind this persistent issue, but since it looks like 2018 will be my mainstay for quite some time, I am finally adding this bug to the list. I know this is a minor thing that doesn't really affect anything, but damn it is annoying. Annoying Workspace Collapse in VW2018.mp4
  13. @jg@swcm We have created our own custom plant symbols and libraries over the years. We don't particularly care for the ones VW "provides out of the box". That said, this is your chance to streamline your workflow. We have built a system of standardized classes that help us control the visibility of the symbol in both color and in black and white. We have generally found it most useful to create classes that control the following: Tree Outline (lineweight control) Tree Canopy (color) Tree Shadow - Special trick can allow you to control shadow visibility (on/off) by class Shrub outline (lineweight control) Shrub fill (color) Interior Linework
  14. Agreed. Unless the callout is a keynote, there is no central place to affect a change in all instances of a callout from the database. When it is a keynote, that universal change can original from the Keynote Legend. ....there is another way, but I wouldn't recommend it for this purpose. You can actually control the Text of a callout object from a database worksheet designed to pull the field ('Callout'.'Text'). We have made symbols of repeated paragraphs, notes, or other text that appears multiple times, but unfortunately there isn't a great way to keep a phrase or portion of text consistent.
  15. NO, but there should be! Text objects need dramatic improvement. It has been my #1 wishlist item for years, but they haven't done anything.
  16. @Jim Wilson Just an FYI...I am still experiencing repeated crashes in the VW2018 file that I provided you. Sadly I am used to the crashes, and there are too many to report each. Additionally, the 10-15 minute file opening time compounds my day when you have to reopen the file 3-4 times a day. That's almost an hour of lost time per day. If I report each crash and research diligently, that would take up an additional hour each day.
  17. YES! I have slowly been working on something like this using @DomC's nodes, but would know where to start with the Detail Callout Marker. Make so much sense.
  18. AND YES AND YES! Since when was it acceptable for users, purchasing the software, to become unwilling Beta testers? If I wanted to be a Beta tester, I would be. I want/need software that I know is going to work when I need it to work.
  19. THANK YOU JIM! That is the best explanation of our issues I have received in months/years. We feel like we are pushing the software and right now, it feels like it is definitely pushing back. Sometimes it feels like a lonely little island out here in the landscape architecture world of CA, but that is why this forum (and you specifically) are so important. From my interchanges and experiences, we are one of the only landscape architecture firms using VW to do almost everything (we left the rendering capabilities behind a couple of years ago) from conceptual through construction on projects of the scale as the one we have been discussing. My hope for both VW and for us is that the software's capabilities and design start to recognize this need and adjust/expand. There is a huge market there waiting for you if you figure it out.
  20. @Jim Wilson I'll just send you a link to a dropbox folder.
  21. There have been suggestions as to why there might be problems, including the origin issue, but no conclusions. I reiterate my above concern about origins...if you're asking us to change the way we do things, then please offer a best practice that accounts for all of the intricacies of the coordination issues we face. Don't just tell me that the origin is the problem, fix it. We are working on Windows. Where should I upload the files?
  22. @Aspect_Design YES!!!!! 1000% Yes! Revision clouds should come with data that can be used to propagate not only titleblock borders, but also worksheets. We are constantly asked to list out the revisions made in our plans. This would be extremely easy if the data was already there in the revision cloud. They should also somehow be linked with the Revision Marker Tool. Imagine if the Redline Tool, Revision Cloud Tool, Titleblock Revisions, and Revision Marker were all integrated into one magical tool. That would be the day!
  23. This was a different file...different problem in VW2019 than the problems we are experiencing with the 18-005_L-Project file. Unfortunately we have relied on this methodology to correctly coordinate with consultants who are using the X, Y coordinates (minus the georeferencing) for awhile now. Our problem has been with user origin control and how to manage that across a multiple reference file workflow. In the past we have had problems with origins aligning in different files across the project, essentially moving the project to dramatically different locations. At the time, our best practice was to forget about setting up an independent user origin and just always align it with the internal origin. I have been told repeatedly that working this far away from 0,0 is a problem in VW; however, I have to date, never been offered a best practice or adequate workflow that accounts for the need to correctly georeference files, work with consultants using real world coordinates, This represents one of the largest frustrations I have with VW. The software isn't developed to be compatible with real-world, large project workflows. It is heavily marketed as such, but in application, it poses problem after problem, and often no adequate solutions are provided. It's usually, "broken as designed" or "user error". I too was met with delay you speak of. I was never able to purge the file on my system in VW2019. When I converted everything back to VW2018 yesterday, it purged in 2 minutes. I can still send you all of the files, but now I have a conundrum...which version do I send. I have several in VW2019, but re-patching together all of the references will likely take me a half a day. The one I currently am running in VW2018 seems much more stable...still slow, but stable. Additionally, the multiple files represent over 5 gb of data. Where do you want me to upload those? Thanks for your time. I am glad to hear that bugs have been filed and that maybe, just maybe, someday VW2019 might be stable enough to give it another try. Sadly, I don't think it's there yet.
  24. 18-005_L-Project Thanks.
  25. @Jim Wilson Thanks for chiming in. I understand the directive. I hope that VW sees that perhaps the reason “it’s just started to get a little out of hand recently” is that many users are very frustrated with the current state of things (ie VW2019) and not just a failing social protocol. I will send the file, but it is huge and contains multiple file references, so I’m afraid the one file won’t paint a full picture. This particular file has been shared with no fewer than 5 VW tech and staff and to date no one can point me to why it is particularly cumbersome. We had it in 2019 but just yesterday saved everything back to 2018 because of a myriad of problems encountered with no solutions offered. I will send you the file later this morning.
×
×
  • Create New...