P Retondo

I submitted a bug for this behavior, maybe a couple of years ago. At least I'm pretty sure I did, so many bug submits I can't remember them all. Anyway, never fixed, so just hit the "X" key to activate the selection tool before trying to activate the rotate tool, it's a habit by now. Jim, whenever we say we would like VW to work with fewer glitches as a priority over new features, this is the kind of thing we are talking about.

Grant, I was unable to replicate this in v2015 or v2016. Something else must be going on with your file. When I group objects in an inactive layer, they are all reassigned to the active layer in a group also on the active layer.

+1 on the idea of scale-aware text and symbols for things like grid bubbles

MH, I don't think you are missing anything, I have the same problem. If someone has a solution I'd sure like to know what it is. Same problem often with arcs.

It would improve VW functionality if we could do these kinds of operations on all classes in a group by clicking on the group prefix, without necessarily having to expand the group and selecting each class individually.

MH, first check to see if in fact you have made everything "None." Select a class in the navigation window, delete it - and if it asks to reassign objects, there are objects in that class. They could be in a symbol or a group. The procedure to do what you want is actually simple. Open the class editing window, expand all groups of classes (right click on a triangle and select "expand all"), select all the classes you want to delete using "cntrl+click" to add to the group of selected classes, then hit the delete key. VW will ask if you want to reassign objects to another class. When selecting classes, don't select the "grouping" class name prefixes - if you do that, "delete" is grayed out as an option. Only select the final suffix of the class names.

Thanks for the response - not sure if these initiatives would solve the problem of updating source files, since if the workflow at hand is change source -> save source -> update target -> output .pdf, one would have to wait for the update to take place before being able to correct the sheet. On the other hand, if, as you implied in your post regarding optimizing data transfers to and from the cloud, the transfer were isolated to the actual objects changed as opposed to re-writing the entire file, then we would be talking about something! BTW, this problem is currently an impediment to structuring our files for a project. As you know, file bloat can occur when rendered viewports are maintained, and we want to retain them because of render times. The update issue makes it inefficient to break the project into multiple files, so the tendency is to minimize that, leading to said file size bloat.

Jim, thanks, it's gratifying to hear that NNA are taking a pragmatic approach. Needless to say, "do your work from anywhere" doesn't work unless there is huge bandwidth everywhere. Speaking of incremental saves, is there any way that algorithm could be applied to updating a linked file? In v2015, at least, it takes up to ten times as long for a large "source" file to update compared to actually saving the same file to my hard drive. Seems like if incremental saves and updates are a goal, the first place to apply the idea would be to updating a "target" file when a "source file" is edited. My 534MB design file (source) takes 10-15 seconds to save after changes. Updating the same source file in my target file takes 1 minute 28 seconds, to incorporate the exact same changes. That's approximately a 10:1 penalty for breaking a project into multiple files, which can be pretty time-consuming at the redmarks phase. I spend more time waiting for updates than making actual corrections to the sheets. (not that 10-15 seconds per save is in itself acceptable - should be a few seconds at most to save after adding a rectangle, don't you think?) PS: 3.47 GHz Xeon processor, 64 bit OS, solid state hard drive

My general experience with cloud-based computing is that it is not suitable to CAD because file sizes are so large the bandwith, especially for uploads, would make use unwieldy. My typical project can be upwards of 750MB, and with incremental saves every 100 operations, and frequent updates of linked files in a multi-file project - nightmare over the web. Bad enough having to wait over 90 seconds for a linked file to update in my sheets file just from my own desktop SSD. That alone makes it a non-starter for me, not even going to problems with fonts and other customizations. So the only use I could see is temporary archiving for use in another location or for basically transferring files, which I can do with Dropbox already. If NNA is thinking of moving to an entirely cloud-based operation like Google is trying to do with its apps, count me out! It'll never work. Anyone else have a contrary experience or opinion?

MHB, you are suffering from one or more bugs that change your Plane Mode preference. The one I experience constantly is that whenever I edit the clip object in a viewport, the preference toggles out of my preferred setting, "Screen Plane Only." I have set up a shortcut key to go to file preferences, and every time I edit a clip I have to go in and reset the preference. This is VW2015, I haven't done enough work with 2016 to know if that particular bug has been fixed. NNA, please track down these bugs and fix them! And BTW, I'm experiencing upgrade fatigue. I'd much rather have my yearly subscription in the form of service packs to add features - if the file format can be held constant, with a new executable issued, say, every 3 years. It's too much of a pain to translate all my resources, past projects from which I reuse elements, etc.

Thanks, Nic, I think it might be v2015 vs v2016. If it's a setting, I've looked at them and can't find any answers. I also get the annoying rectangle around the dimension text, which I see you don't have. I've resisted going to 2016 despite owning the licenses because of all the reported instabilities. Jim, if you're monitoring, first priorities for me in future updates and development: reliability, speed. Everything else tends to be bells and whistles if those are not solid.

Thanks for the interest, nplache, I discovered that dimension text doesn't display in wireframe rendering mode. I rendered in OpenGL, and they now display okay.

Anyone know how to get a 3D dimension drawn on a design layer to appear properly in a sheet layer viewport? I get the witness lines, but the text is a blank box.

Christiaan, thanks for sharing your window and door method. It works, but it's not parametric. Have you ever tried playing with Marionette or scripting to construct a parametric symbol? If I ever have a few days, I'm going to give that a try, based on your system. NNA would do well to look carefully at this example to see what a modern parametric window/door tool should be capable of doing. Constructing something with Python or VS is all well and good, but way too many VW elements are script-based and, hence, execute way too slowly compared to compiled core program elements.

Will is absolutely right, this could be easily written into VW with something similar to "constrain to working plane." For those unfamiliar with the problem, when snapping to objects in a 3D view, 3D objects can appear to move in the "screen plane" when they are actually moving backwards or forwards as well. When I want to "move by points" in a 3D view, I construct a rectangle snapping to the two points, drag the rectangle to a white space area, and perform the move by snapping to the corners of the rectangle to be sure I'm not inadvertently changing the location of the moved object with respect to that normal axis. I would love to be able to do that simply by pressing a constraint key.

I go even further than Peter - the section viewports are so far from graphically acceptable, and take so long to render, I only use them for the background information, and then only sparingly. For the actual section, I use the good old 2D section legacy tool to get geometry, and draw the section on a design layer old style. That's the only thing that really works, and it takes less time than screwing around with the section VP, and a lot less time than drawing in annotation space, which in past versions of VW at least was maddeningly slow. We tried converting the section VP to lines, then scaling up (x48, e.g.), but 2D section is just faster because of re-render slowness.

MH, you have a great idea. To have maximum flexibility, it would be ideal to be able to choose units on a per viewport and per dimension basis. It is possible to do what you want with the following workaround involving a custom dual-dimension style: 1. Create a dual dimension style for your document 2. Set the dual dimension units you desire using document preferences (e.g., primary ft&in, secondary in) 3. When you place a dimension, go to the OIP (Object Info Palette) and change the style to your dual dimension, then set the option for that dimension to "Dual view: Secondary Only" from the dropdown list. That dimension would display in inches instead of ft & inches.

I'll add emphasis to that request re: education support. The single greatest drawback to using VW is the scanty base of trained users as potential employees. It's made me think more than once about switching to ACAD, the cost of training and the lack of choice in the potential employee pool is daunting.

Tom, thanks very much for tracking that down. Many hours were spent dealing with this problem. It's up to VW to fix this very avoidable issue. I remember when rotated plan was being developed, and I pleaded with them to isolate the rotated plan concept to avoid this very kind of problem. To no avail. What is rotated plan? In essence, it's rotating the screen view and orienting orthogonal tools to the rotated coordinate system. If they had just focused on that instead of messing with geometry fundamentals, none of this kind of thing could have occurred.

Had this issue in v2015, reported it as a bug back then, but what exactly causes the shift is still a question for me. Do what Alan says - reset all your origins to the internal origin. Once I did that thoroughly, the issue has not re-occurred. Don't give in to expedience by moving the referenced viewport to correct the problem, it just gets worse. Tools-> Origin -> User Origin -> "Set User Origin to Internal Origin". Jim, unless this is fixed it makes setting a user origin a dangerous thing to do in any file which is part of a multi-file project. I can only imagine what it would do in the new project-sharing environment. As a general comment, often-repeated and probably just as often resented by VW engineers, I would much rather have NNA spend coding time making all these basic tools rock solid than have some new (probably not really useful) trick feature. Just add some code to the function that moves the origin to prevent it's being moved without notifying the user and verifying the intent. That way, whatever obscure combination of events calls the function, it can never be executed without "authorization."

All good ideas so far. Navigation is sometimes an issue - like, just now, I went to the site from the link in an email notification, but had to log in. After logging in, there was no way to get back to this thread except through the browser back-button, and that page didn't know I had logged in. Just being able to navigate back when browsing using a dropdown list of "recently accessed threads" would do wonders. (Yes, I do know the browser "refresh" button forces the site to acknowledge I'm logged in.) The organization of the discussion groups - it's a long list, and there is a lot of crossover and confusion about which category a thread should live in. I own but don't use Spotlight, but often issues brought up by Spotlight users are relevant to Designer as a whole (for example). I think a database approach might be better, where the website manager enters keywords for each thread so the user could organize and search the site by a list of keywords. That might help with Gilbert's comment, so when a current thread shares a keyword with an older thread, it could be easily referenced.

Jim, real estate appraisers have little apps that take measurements directly from a bluetooth-connected Disto EDM, and even turn 90 at each measurement to draw a crude plan. Seems like it would be both relatively easy and a huge selling point for VW to come up with a more sophisticated version of this capability. As it is, I now export measurements realtime via bluetooth to Excel, then post-collection manually translate measurements and notes to VW geometry. Even with that level of crudity, the system is about twice as productive as the old sketch / measuring tape / hand notes system, and a lot more error-free. I also take measurements with a total station, then export NEZ files to Excel -> survey stakes. Seems like that could be looked into as well, surveyors have small hand-held computers with software that translates total station measurements on the fly into CAD.

Kevin, I don't even remember what version of Minicad we first had. It was the first CAD program I dealt with professionally, in the transition from hand drafting, and we jumped right into 3d immediately to model custom day care furniture. BTW, a lot of people don't realize that, as in the original Minicad, screen plane objects are truly 2d - they have no Z coordinate (or maybe that is faked now, who knows what is in the code!). What is especially useful about them is that they make it possible to transfer geometry from one view to another with simple copy and paste, in much the same way as we used to project sections and elevations from plans in the days of hand drafting. I think this hybrid 2d-3d design environment was part of the original unique genius of Minicad / VW, and is much undervalued by some folks who are used to straight 3d programs like Sketchup, Form Z, etc.

Must be a 2016 thing. In all previous versions, a dialog box comes up when creating a symbol with a check box asking if you want to change all layer plane objects to screen plane. For those who aren't aware, the original VW (MiniCAD) and in versions of VW up through a few years ago, there was no "screen plane" / "layer plane" dichotomy. In fact, every 2d object was what we now call a "screen plane" object, and anyone who has the experience indicated by some signatures on this thread has long experience with using screen plane objects, even if they didn't know that's what they were! This was historically a big difference between VW and AutoCAD, where all 2d objects were actually 3d - basically, what we call "layer plane" in VW. I use virtually nothing but screen plane objects, even though I do a ton of work in 3d. I find it incredibly useful - think of it as a layer of trace on your screen, where you can draw and think in 2d with respect to the view on the screen. I actually think it was a mistake to embark on this "layer plane" notion, instead of enhancing the 3d objects we already had. But this is the VW we have - it would help if certain operations did not inadvertently toggle the preference for screen vs. layer plane. Every time I edit a sheet layer viewport crop, my "screen plane only" option switches to "working plane only," and I have to switch it back (this is 2015). Hopefully this bug is fixed in 2016, I'm just starting to use the new version. For anyone who doesn't know, you can choose "screen plane only", "working plane only," or "screen plane or working plane" in VW preferences / plane mode tab. PS: if you want to make sure moving a 3d object in a 3d view does not change location with respect to the screen normal axis, just draw a screen plane rectangle between the points you want, set it to the side, and between the corners of the rectangle. Just one of many useful screen plane object tricks.

Here is Will's construction to find the arc fillet in the "S" curve case.