NHJ

Took me a minute to find out how to set this up. Under Vectorworks Preferences. But I added the Snaps to the Smart Options Cursor and it's perfect. Pops up when I need em and vanishes when I dont. Better than before. Thanks!

I will try that right now. Great idea! I know overall it's a minor thing. Was setting about memorizing the exact hot keys as well. Will add them to the Smart Options as well.

So is there no option to have a floating Snap to Palette in VW 2022? I am just curious if there is a way I can get the Snap to Palette Back in VW 2022. I use two Monitors and now my Snap to Buttons are in the Far Right Monitor on the Lower Right, not an ideal. A Floating Palette Option for Snaps would be useful... Am I missing something or is that not possible in VW 2022?

Crap now I am going to go rotate one of these just for kicks....

Pat, Got it all to work as you said. Single Record for each Sheet Size. Different Graphic for each Sheet Size, but all using data from a single record (source) per sheet. Set up a different Style per sheet size. 11x17, Arch C, Arch D. But they all are referencing the same data record. Worked easy. Go figure! Lol, thank you. Andy. Eye Dropper Tool does work if you copy and paste 2 title block borders onto the sheet. The old one containing the sheet data and the new one (this time constructed properly, but with no sheet data because different attached record format) but I used the eye dropper to transfer the old sheet's record format data. It worked fine except for the Project Title, for some reason. But thats an easy fix because the Project Title Data is a single entry and it then applies to all the sheets in the documentation. Thanks again! I now have a set of title blocks that change and grow as the details within the scope of work on the project does the same. Which is what I was hoping for/thought I had made, but user error had me attempting to over complicate it, go figure.

Pat, Yep. As I was thinking this through I was wondering if that might be it. I did create separate record formats for each paper size so every time I was importing the next size title block it added the new record format for the data and was erasing the previous sheet data, basically started it over. Ok I will use a single record format for all the various title block sheet sizes. Then make each sheet size type 11x17, Arch C, and Arch D a separate TBB style but the record for each style will be a singular record format. It just will have its different graphic representations based on paper size. Now it's all starting to make more sense. FYI when I do this Andy I am going to see if I can transfer the Sheet record data with the eye dropper as well to the new single record format. So hopefully I wont have to enter the data a third time ughh, I will let you know if that works.Thank you both!

Andy, I will try that later on today. The record formats are the same, so it should transfer, I hope. Thanks, I will let you know if it works. Pat, I created Custom Title Block Border Objects and created custom records for each. The records each contain the same data, the graphic symbols are different for each sheet size. I thought about just scaling it, but not sure if the appearance will hold. Gonna test out these options and a few others, because my basic process is that I go from 11x17 in prelim/SD, to Arch C for DD, and usually Arch D ends up happening in the CD phases, so I need to spend bit of time smoothing out the transitions and being able to build on all the data as the project progresses. Doing this twice hurts me. lol I will let you know what I find out. Thank you both for the thoughts.

Is there any way I can go from Arch C to Arch D Size Sheet on a project, thereby changing to our Arch D Size Custom Title Block, and not have to re-enter each Sheets Title Data from scratch? DD was on Arch C Size set of 15 sheets and I have all the information entered for each sheet. The data is not changing just the graphic size of the title block. Why is the Sheet Data not Assigned to the Sheet Layer directly per sheet regardless of size? Am I missing something simple to not have to re-enter 15 sheets worth of Sheet Title Block information just because the graphics of the title block are getting larger? The client is adding services (which is great, they are trusting us and it means more $) so we are upping the sheet sizes are going from Arch C to Arch D to accommodate the request and additional schedules and reports being requested. Curious if I am missing something. Any thoughts would be appreciated. Thanks!

Curious if this is possible? Clients tend to know how to use a PS4 controller, now, and it would be great to let them interact with their Vectorworks Project Models that way. Mouse and keyboard or my Space Pilot Pro tend to intimidate and I like my clients to feel comfy and such things, they write checks quicker that way 😉 . Any idea if this is possible on a Mac, or PC? It would be a great add if they could fly around a finished model with one.

Floating License's seem to do the trick. Rhino allows you to install the program on as many machines as you like. But you purchase a certain number of license's which float in the "cloud," when you start the program, that machine its on goes and searches the licensee cloud server for your available licenses to open and run the program. Once you are using all of them, the other machines wont be able to open the program if someone starts it, not until one of the machines currently operation the program is closed and releases the license it was using. Works great so far. Seems like a logical way to go about it i.m.o. Searched this because I am about to purchase a new machine for operations and retire my laptop. So I was wondering how Vectorworks handled this... Seems I need to call and get their process rolling.

It seems a little strange with todays computing power to have Character Limitations when we are Naming Classes and setting up Working Files. I also do no see any practical reason why there is a limit on the number of Subclasses any one Class can have. It feels like legacy constraints from earlier Programing Conventions. It would be nice to see this open up a bit. Same should apply to removing limitations on Layer Naming Character Limitations. Though this does not seen as much of a bottle neck to work flow practices. That's just my 2 cents on that.

Good point. Def. could be that as well. But it would sure be nice to have more spaces, literally, available for naming and unlimited sub classing, not that we need a crazy amount... but leave it up to the user not the program. VW leaves it on the user to make sure their files are compatible and play well with other programs. Or perhaps even an option that we can turn on and off per file, for unlimited character lengths etc, and the user would take responsibility for it. Idk but I wouldn't mind seeing that. As you said, there likely are multiple reasons. But I always feel cramped with the amount of characters allowed right now, and to me it seems something left over from old school windows and or mac coding, but I am no an expert in those matters.

I have been curious for a while now, as to why there is a limit to the total number of characters we can use to name classes and Layers, as well as the total number of sub classes we can create? I am assuming this is perhaps a programing, file size reason maybe, but I do not see going forward why we need this limitation in the program?

I did get one to work and align last evening finally. But I had to create a texture from scratch using the brick shader and I made it so it worked and was to the exact dimensions for the project. Then I had to make a custom hatch for the bricks to the exact same dimensions and then adjust a few times within the resource browser to make it work. The logic to create all this was not very logical, or straight forward, but it works! Then apply the textures to the walls and adjust the texture offsets and such. However this all took a long time to dial in. about 4-6 hours. Not counting all the time lost trying the presets and textures and hatches provided. I am hoping I can remember and refine the process more and use this base brick texture with its surface hatch for creating more textures and surface hatches with better alignment. However I am not convinced yet that what I made is "fool proof" but it works for this project. That being said there was not logical connections between the texture and the surface hatch when editing them. I actually have the surface hatch off set from the brick surface texture w/in its resource browser settings. And somehow these two being offset in that environment makes it so the brick and its surface hatch pretty much align in 3D space. Not sure why its working, lol but its working for now. Kinda just eyeballed it until it was doing what its supposed to. And creating hatches from scrach, thats an interesting one as well. Not user friendly for sure. Anyways, here is what I came up with and its look in model space. Screen Shot 2019-07-14 at 12.48.48 PM.tiff

Same issue here with a current project. Either allow us to separately apply surface hatches and textures for rendering. Completely different set of controls for each. And then we can adjust them as needed. Or they should perform and align the exact same. Otherwise why have them associate? Very frustrating.