Thomas Wagensommerer

I would like to suggest 2 improvements for dimension lines: 1.) It is nice that we can enter the length for a dimension via the object info palette. However there is a 50% chance the newly entered information is useless, because we dont not know in advance in which direction the dimension line will change. How about adapting the line length widget for dimension lines? 2.) What do you think about activating the 2D reshape tool for entering in-between points into a chain dimension?

Yes, the "Move" command in VW 2009 is great, as well as the "Set Position" tool. I am a great fan of those improvements and I appreciate the good work that went into the release of VW 2009. But I also miss the old "Set Position" Button, because it worked from a position zoomed far out of the drawing. For the new "Set Position" tool you have to zoom way in and measure precisely, which is very good at times, but is generally a big time waster. May I suggest an even better way to set the position of a symbol in a wall: This should work just like the position widget for a rotated rectangle. (See screenshot) You could easily see and enter the distance of 9 points from their respective corners in a wall. This should be sufficient for 90% of all "Symbol in Wall" positioning needs. In these cases there would be no need to activate a separate tool. We would also get rid of the Button in the tool palette, because the information is always visible. If you need more flexibility you could still use the new "Set Position" tool from the tool palette. For even more power there could be the posibility to place loci inside the symbol or plug-in object in order to mark the 9 points which are referenced by the 9 locations in the widget.

The new "Set Position" tool is nice, but it is no replacement for the old dialog. Please Nemetschek, please give us back the ability to simply enter the position of symbols by number. Moving something around is not the same as entering the position for it. If this were the case, we could get rid of the object info palette entirely, because we have the "Move" command anyway. Why take away functionality?

Computer, harddisk and user wide awake. Yes, re-downloaded the installer and rerun it.

Mac OS X 10.4.7 - Does not work either.

Needless to say I shut down everything.

Please could someone look into this issue... The 12.0 Install CDs didnt work, the 12.01 Upgrade didnt work for me and now the 12.5 Upgrade does not work either. By the way: this did not happen on a single esoteric system configuration. I tried it on several different computers in the office, ranging from G4 to Core Duo, and I also tried everything else: single user mode, fsck, firewall off, extensions off, network on, network off, clean install, secret hack from the internet....

I am also having the same problem here. By the way, I tried every single tip and hint given in the whole forum and the installer simply does not work...

What about typing 17..5 - The double dot could be matched to '

Are there any news about the offset function?

3D Objects do not look good in plan view. What I do very often: To construct the 2D part of a hybrid symbol out of the hidden line rendering of the 3D part. I wish there was a vectorscript function, so we could do this for a PIO as well.

Can we have the functionality of the offset tool as offset function for Vectorscript? This should be easy for NNA since the tool already exists. See also this discussion.

It should be possible to select more than one symbol inside a wall.

The Move an Duplicate commands should recocnize if there is a symbol selected inside a wall. Then these commands should work within this context and duplicate or move the symbol inside the wall.

Katie, thank you for your research. If I need a rotated rectangle *now*, I draw a polygon. It is absolutely true this polygon takes somewhat more storage space than a rectangle. After the user interface is improved, the same polygon in the shape of a rotated rectangle will still use the same storage space as before, but it behaves nicer towards the user. As I said before, internal storage is not changed in any way, only the user interface is improved. There is no difference in the way these objects are drawn and redrawn, but yes, they are treated differently. P Retondo, obviously the array of 9 radio buttons in the object info palette should be aligned to the rotated rectangle. Yes, there is a considerable effort in programming required. No, I cannot imagine the rectangle becoming a kind of symbol that has to be "entered?. I dont think there is additional knowledge required by the user. Quite on the contrary, the current behaviour of rotated rectangles is counter-intuitive and not expected by the ?non-expert? user. Perhaps one of the VW-gurus can comment from the programming point of view? [ 04-18-2003, 04:56 AM: Message edited by: Thomas Wagensommerer ]

There is absolutely no additional computing power needed for screen redraw, since internal storage is not changed. Only if you select a polygon the computer would need 0.001 sec to calculate if this polygon is actually a rotated rectangle. If the computer recocnizes it as rotated rectangle it would give you height, width and rotation angle in the object info box instead of polygon and vertex info. With the selection tool active you would get selection handles specific to rectangles, not the bounding box you get now, which is useless for rotated rectangles. If you drag, orthogonality is not destroyed. If you choose the reshape polygon tool you would still get polygon and vertex info in the object palette. If you drag, you can move individual vertices, orthogonality is destroyed. Its as simple as that. [ 04-18-2003, 04:56 AM: Message edited by: Thomas Wagensommerer ]

-- AutoCAD treats rectangles in its core code -- as you describe. As I understand it, VW's -- code is different, and rectangles are a -- separate class and therefore do not inherit -- polygon behaviors. True, I know that. -- Since it's easy enough to convert a rectangle -- to a polygon in VW, getting polygon behavior -- is reasonably convenient. True more or less. Rectangle -> Polygon is easy, but Polygon -> Rectangle is not so easy. What I suggest is automatic conversion in both directions . Just in the moment when conversion is needed. No questions asked, no dialog boxes shown, no pulldown menus involved, no scripts broken. -- What I think you are neglecting is the fact -- that, compared to AutoCAD, VW's rectangles -- are much easier to use -to resize and -- create. The opposite is true. I am *stressing* the fact that compared to AutoCAD, VW's rectangles are much easier to use -to resize and create. What I am suggesting is, that rotated rectangles could be as easily created and resized as conventional VW-style rectangles. -- This ease of use flows directly from the -- different way in which VW has organized -- their basic class concepts True, but has nothing to do with rectangles and polygons. -- and asking them to change it to make -- rectangles a subset of polygons might not -- be logical. Not true, at least in my opinion. I am talking about geometry here. All rectangles are polygons, some polygons are rectangles. The ideal program should know about this fact and act accordingly (Neither Autocad nor VW do it properly.). This behaviour should actually be more logical. -- To add a rotation attribute to the rectangle's -- definition might be feasible and useful, but it -- may cause lots of problems when it comes -- to converting old files to the new system. Not true. The rotation attribute should be optional. All rectangles without this attribute would not change at all. (Neither storage, nor code, behavior, object creation or modification, user interface, etc...) We should not expect any difficulty converting old files. When saving a new file in an old format all new rectangles with rotation attribute would be converted to polygons, so we should not see any difficulties either.

There are two sides of the problem: 1.) User Interface 2.) Vectorscript How can we improve user experience without breaking most vectorscripts? Rectangles are a subset of polgons. Thus rectangles should accept all modification tools and procedures polygons do accept. If needed they are converted to polygons without further notice. (No dialog box telling you cant do that to a rectangle.) Some polygons are rectangles. If a polygon is rectangular (rotated or not) it should silently revert itself to a rectangle and accept user input (stretching and resizing) just like any other rectangle.

The point is: In the past, when storage capacity and calculation power was limited it made sense for the user to adapt to the way the computer defines objects. (A rectangle is something defined by two vectors and it has always vertical and horizontal lines.) Nowadays we should expect the computer to treat objects as we expect them to behave. (A rectangle is defined by four ortogonal lines, and it does not matter how it is rotated.) Again there is no reasonable argument for an object to loose its "rectangleness" when it is rotated, aside form issues of backward compatibility.

The rectangle should have its rotation angle as an *optional* third parameter. Rectangles without rotation angle are treated as before. There is absolutely no additional storage capacity needed and only infinitesimal calculation time. It is expected behaviour that an rotated object does not change its type and there is no excuse for loosing rectangleness forever. This is also true for constrained and unconstrained dimension. These should be the same object type with a checkbox in the object info palette for the constraint.

Why do we need a wall styles tool at all? Why did NNA create a wall styles tool instead of improving the wall dialog box? This way more complexity is added instead of putting all those features in one place where they belong.

Can we add a reasonable offset function for Vectorscript to the wishlist? This should be easy for NNA since the offset tool already exists.

Can you call the offset tool from within Vectorscript?