Chris D

Dunno mate, never use it. Actually...I haven't got my head around this new-fangled Layer Plane / Screen Plane thingy yet.

....ducks for cover..

Agreed. E/N Coordinates plus Z spot-height (elevation) would be useful.

============ REVISED WISH ============ I'd like the new "Coordinate Point" mode of the Stake Object, introduced in VW2011, to have the following options: - Display of up to 3 decimal digits - Toggle to display E over N - Toggle to turn units display on/off Pretty please.

Miguel - thanks. The stake tool in VW2011 can now display coordinates! It even displays them as E and N, rather than X and Y.... Just one small problem....when you set it to use "Document Units" it doesn't follow the correct number of digits of decimal precision that you specify in your document settings. For instance, coordinates for setting-out in metric countries are provided in meters, to 3 decimal places (giving you the nearest millimeter*), but the object will only display 2 decimal places. *Millimeter precision is ridiculous, I know, but that's how we do it. EDIT 1: One other issue...it should have the option to toggle the N/E to E/N. At the moment it gives the Y value first, then the X value, which isn't standard practice. EDIT 2: Here is a screenshot of the tools side by side in 2011. One thing to note, as I mentioned above...the Vectorbits script no longer works in VW2011. [img:left]http://img259.imageshack.us/img259/4756/vw2011stake.png[/img]

Here we are again, indeed. This discussion was rather heated last time as I recall... I'm suggesting putting the line/fill attributes on the OIP because that's where I think they belong....with all the other attributes. In a big office, where following a class system is a necessity, it doesn't help to have the line/fill attributes on the other side of the screen from the class/layer attributes - they should be together. Now, granted, you should be able to tear this section of the OIP off, for occasional off-class working, or for those firms who don't need to follow a rigorous class system and tend to manually set line/fill so often that they need the palette handy. Maybe you could even agree on this? The problem with the odd little attributes palette we have at the moment is that it's impossible to place it sensibly at the top of the OIP....it doesn't even stretch!

All healthy discussion ;-) Maybe I only come here for the banter...

I've got a script. Manuel at Vectorbits kindly wrote it for me. It works OK but it could do with the kind of robustness you only get from first-party tools. It seems to be based on a symbol so it occasionally jumps into walls, and for some reason you can move the insertion point (very dangerous for a setting-out tool!). The problem with scripts too, is managing them....you never know if they are going to work with each new version of VW, and you have to manage them along with a workspace which includes a shortcut to call them up (users don't like script palettes...).

We get this problem occasionally, but we're on Macs too.

Better still, the Attributes palette should be merged with the OIP where it belongs, and the Constraints should be in the grey bar below the document window like in AutoCAD.

Are you trying to be offensive Petri, or does it come naturally? My firm has used nothing but MiniCAD/Vectorworks since we were founded in 1993 and we currently have over 50 licenses (some now unused due to redundancies). This means we have invested thousands and thousands of dollars with Diehl/NNA/NVInc over the years, so I think I have a right to contribute here. Your argument, as usual, is self defeating anyway. Why the hell would I spend my time asking for new features in FUTURE versions of Vectorworks if we weren't planning to buy them???

Who pays for my time here documenting Vectorworks deficiencies and making constructive suggestions to improve the program to a point where it is worth the investment to upgrade?

We still have some users on VW12.5 (a long story about the timing of the credit crunch)....one of whom received a DWG file yesterday that wouldn't import to VW2008...so I imported it in the evaluation version of VW2011, then exported it back as far as it would go from there...VW2008.....then opened it in VW2008 and exported it back to version 12.5....all worked fine....but could have been easier... Now if Vectorworks Viewer could be beefed up to import DWGs right up to the current DWG spec.....AND handle VW file conversion...that would be lovely.

How do you get the Stake Tool to display coordinates??? It seems to be a tool for displaying elevation in the Z plane.

All countries use coordinates to set out their buildings. We just call ours "Eastings and Northings" and though it refers to our National Grid we use the Vectorworks grid like anyone else. It won't cost NV Inc an awful lot to have an option to display E/N instead of X/Y or whatever you guys use... EDIT: The fact is, VW provides the very same tool for displaying Z coordinates (the 'elevation benchmark' tool), but not for displaying X/Y coordinates. The tool is missing.

I'm sure I've asked for this before, but it hasn't shown up in the program yet. We need an 'Eastings and Northings' tool. This is probably UK-specific terminology for 'Building Coordinates'. It's really quite simple, in fact we have a VW Plug-in for it already, produced by a third-party, but it's not quite right, and it should be a core part of the VW Architect program anyway. All the tool needs to do is read the X and Y coordinates of a locus point and display these coordinates as E and N coordinates. Like this: The Northings and Eastings object must also be 'live', like the 'Elevation Benchmark' tool, i.e. if the object is moved it must display the coordinates of its new position. For an explanation of Eastings and Northings in the UK, see section 3.1.5 on page 14 of this document. It's a good read, by the way... http://www.ordnancesurvey.co.uk/oswebsite/gps/docs/A_Guide_to_Coordinate_Systems_in_Great_Britain.pdf

You'll be lucky. We don't even have an Eastings and Northings tool for setting out building coordinates!

There are undoubtedly bigger single issues, but collectively the issues I have raised cost our company more time and money than anything else, by a large margin. In an ideal world we'd train all our users for say, 7 years, before letting them issue any drawings. But even then, I've been on VW for 7 years (after more than 10 years on AutoCAD) and I still make mistakes. I still move objects when I go to select them, I still paste objects forgetting to re-class them first. Most of my mistakes I spot, but some get through. Colleagues with lesser experience are letting more through. This isn't a lack of training...we induct all our users, circulate constant guidance and have refresher seminars, but we can't babysit our users. It's all very well us tailoring every VW installation too, which we do, but people have their favorite workspaces, which re-introduce rogue shortcuts like the dangerous command-9. Other settings, like nudge, simply can't be turned off. I still maintain that the product should be robustly foolproof, out of the box, and it is power users who should have to enable the heavy artillery.

I don't want to get rid of it, just have it off by default. At the moment you can't even turn it off at all - you can change the keystroke, but you MUST have a keystroke associated with Nudge. No choice in the matter. Don't forget that the cursor keys + a modifier key combo is used to move between layers - but if you get the wrong modifier key, you nudge an object instead! It's too dangerous to have features like this enabled on default keystrokes which are very similar to other commonly used keystrokes. I don't mean to sound fascist about these things, but the program should be robustly foolproof by default, with power users free to enable these features if they want them.

Robust Foolproofing Vectorworks is a powerful tool and in our 2D drafting workflow I find it much quicker to get things done than, say, AutoCAD. However, the origins of Vectorworks as MiniCAD betray it, when it comes to mission-critical construction drafting. It's very easy to manipulate any aspect of a drawing with a mouse-click or a keystroke, which means it's very easy to f**k things up too. One might argue "what does it matter", when you have backups at both file level and drive level - if somebody messes up a drawing, you just retrieve the backup. Well, that's fine if the bungle is obvious, but of no use if the if the error goes unnoticed and the wrong data is issued. I spend far too much of my time at work being the 'Red Adair' figure...being called in to our various workgroups to troubleshoot problems with Vectorworks files. These problems are always the same....file origins have been moved by accident, drawn objects have been moved by accident, objects are apparently 'missing', or our uniclass system has been polluted with rogue classes. Vectorworks needs more robust foolproofing, and here's what I propose: 1. Remove shortcut to 'move origin' Command-9 (on a Mac) should NOT be an default key shortcut to move a file's origin. WHY do you need to move the origin so often that it needs a shortcut? Moving an origin is a big decision and the way VW handles it (badly) means it can have major consequences, particularly for site plans. Putting the shortcut to move a file's origin directly adjacent to keystrokes for more everyday tasks has led to more problems for my office than I have space to recall here. 2. Remove ruler button to 'move origin' Just like the keystroke, there's a cryptic button in the corner of the on-screen rulers to move the drawing origin. People press these buttons out of curiosity without understanding the consequences. I want to be able to remove this button from the rulers. 3. Preference to disable drag-move and drag-copy Now that Duplicate is finally enabled by key-toggle (I key) on the Move By Points tool (Shift-M tool), we finally have the equivalent move/copy tools of other CAD programs, which require you to select an object and then perform a move/copy operation. Drag-move and drag-copy are quick and powerful, but I would trade that for the more foolproof stop-and-think method. It's all too easy to move an object when you mean to select it at the moment. You may disagree, that's why I propose it's a preference setting. 4. Nudge disabled by default Some bright spark always shows our new users this handy little feature called Nudge (shift and cursor keys). Grrr. If you want to move something, move it by the millimeter or snap it into place. Nudge has a use, on say landscape plans, but it gets abused. I would like nudge disabled by default in the the pre-loaded workspaces OR a preference that can disable it without having to edit a workspace. 5. Command History "What have I just done?" is a very familiar remark from new VW users. Did they just more something by accident? They're not sure...so they carry on drawing for a minute or two, before realizing that they probably DID move something. Of course, without a command history, theres no way to be sure....just keep hitting undo until they think they've put things right.. VW needs a command history for the last 10 or 20 commands, OR a Step Back list like Photoshop. 6. Enable layer-locking Yep, we've been over this before on these boards, but I still believe it is necessary to add layer locking as a feature. It's all very well having object locking, but all too easy to undo that while editing. Layer locking would allow site survey files to be placed on their own layer and locked in place. Object locking and unlocking on top of this, for the site design, would then have no danger unlocking the entire survey. Yep, I know you can grey-snap layers, but users change the layer-option settings all the time. 7. Class Filter for clipboard-pasting Clipboard-pasted objects are the main source of class-name contamination of files. Once a job-lot of class names are in a file it's an arduous task to go and prefix them all to group them. We need a firewall for the clipboard that intercepts objects and allows the user to manage the class names of the incoming objects. 8. 'By Class' settings...on by Default Why do the included template files default to having the 'by class style' settings on the attribute palette turned off? It's laborious to manually set each attribute to 'by class' every time a user starts a new drawing...so hey, guess what...it doesn't happen. Then when they can't manage their class colors in the viewport..they wonder why. Please ensure all template files have 'by class style' set as the default for all attributes. 9. Sheet Layer "Show all used classes" preference Even experienced users get caught out by this one. They've done the print run and are just checking the hard copies, when they realize that some of the objects from the sheet layer are missing. It's all too easy to switch to a sheet layer and forget to turn all the classes on that you've used for legends and keys. I'd like VW to have a preference that, when enabled, will automatically turn on all the classes used in a sheet layer whenever the layer is made active. 10. Fix the Grid snap constraint That little grid button on the constraints palette is a pain in the ass. Users THINK it just turns the display grid on and off (which it doesn't), when it is actually toggling the snap-to-grid. I don't know who uses snap-to-grid, probably a minority of VW users, but I'd like the snap-to-grid setting to have a button of it's own, WITHOUT a keystroke in the default workspace. Too many times have users found themselves not concentrating on their snaps and found themselves drawing to a random 3mm grid. I'm sure others will have foolproofing suggestions of their own to add to this list.

Us too. The Windows restriction also applies to government issued stuff too though...Excel spreadsheet calculating tools that include macros which only seem to work on the Windows version of Excel...

At the risk of going round in circles.... If IFC is too slow, and too limited in scope, then this is the alternative.

Is that the case though Jeffrey? It has been argued in this thread that IFC is no more than a glorified exchange protocol, and Robert even rejected the idea of a common file type. So is IFC really analogous to HTML?

I think this statement reveals that NV Inc is afraid of a common file format, in the same way Autodesk would be. I believe you are wrong, and not just from a user's point of view, as our lives would be infinitely easier, but also from a developer's point of view. Differentiation is derived by the software, not by the file format. As an analogy, we can all sculpt with identical blocks of ash wood, but those with the better chisels will have an advantage. Those who want a state-of-the-art wood-turning lathe will also pay more for it than those who prefer a basic sets of tools from the hardware store. Differentiation of BIM software that could manipulate a common file format would take the form of the tools available, their usability, their power, their automation, their customization, their localization (language and local practice) - many, many factors. Do I even need to point out that there are a multitude of HTML editing apps out there, all editing the exact same, open, standard*, code (*for the most part..). Sure, Dreamweaver is a big player in this market, but even small developers make money out of producing HTML tools for those who don't need and can't afford DW.

Sometimes, the ends justify the means. Is democracy always the right answer - two lions and a lamb voting on what to eat for lunch? I'm all for open standards, but sometimes you have to cut through the bureaucracy and just get on with it. I don't decry IFC. I decry how limited in scope it is and how slowly the navel-gazing is going.