panta rhei

Actually, not quite so. If the plug-in has been created with VectorScript, one can change the value lists of pop-ups & radio buttons, even when the script is locked. This may have unexpected consequences, if there is something related to these hard-coded in the PIO script. One can also assign a default class to the object, not to mention default values to be used in new files. Unfortunately, more and more of NNA's plug-ins are created with the C++ SDK API and the user cannot change anything.

Actually, the whole concept of a grid bubble tool is fundamentally wrong.

Haven't been hiding it, but it is quite serious stuff for serious projects of volume and complexity. If you have a central city block or two to work on (planning, urban design, feasibility), it could be worth the very serious cost and steep learning curve.

Spot on.

Goodonyamate!

Haven't you heard ...? We are in a severe Liquidity Crisis and need to borrow more $$$ from Finland, et al. in Ahh, we'd be more than happy to lend you a fistful of dollars..

A good reason to start to use the Move tool (or whatever it is called), which is, despite some bad user interface decisions, much more powerful. Not as good as the one I've created, of course.

Can't be done. There is no ODBC-facility in VW. (Open Data Base Connectivity.) However, theoretically an equivalent system could be done on the Macintosh platform with FileMaker Pro, which in any case is far superior to Excel as a drawing register. I have for quite some time tried to find time to test the theory: Sheet Layers demolished my old centralised drawing register system within VW.

Indeed they do. The issue is that non-US users (according to Sean Flaherty maybe a couple of years ago this means two thirds) have to pay for the US-only tools and content. The (only?) useful features of VW Architect (compared with Fundamentals) in Finland are wall styles (the mechanism, not the styles provided), rotated plan, DTM and two-way worksheets. However, we have to pay for door, window, stair, space, ceiling grid, elevator, escalator, column, roadway, parking spaces, property line, issue manager and so on. And then we have to buy the local tools to replace those. Without the mentioned stuff, surely VW would be a good deal cheaper? In effect, non-US users are subsidising the US (architect) users quite heavily. Without our money, the extra price for Architect would be maybe twice what it is now. Why can't Americans pay themselves for the features they need?

Sounds OK to me. You may, at least in future, wish to have another file for 3D buildings, if any & if not supplied by others. The image prop 3D-plants that come with VW are quite nice and alone a justification for working in 3D.

Conceptually/theoretically I think layers would be a better mechanism for this than classes and then you could use layer colours.

Ahh, great minds... Let's decompose then!

Well, your proposal has no relevance to the majority of users. If anything, I'd like to see VW's tools be less US-centric & McMansion-focused.

Fancy that. So, in 2007, Apple was installing 12 years old technology in one of its top product lines.

It breaks references even for a one-person operation. In a larger firm, it can be a total disaster, with many people happily working on a different copy of the ?current version?. Almost verbatim: I've seen file nimes like ?Job Drawing Current Latest Updated Jack? Is Jill with her VW supposed to know what & where the latest version is? Or to know to ask from Jack?

It is irritating, isn't it! However, reading between the lines (apologies if I misunderstand, but it's long ago since I last read this sermon here, so perhaps it is not wasted even if it is not applicable to your office): ?Saving as? is in general bad practice. We all need to do it from time to time, but it should never be used to create the ?current version? of a file. The current version of each stage should always retain its name & location. Archive copies are made in the OS.

Pat, I don't actually want to count worksheets but to do things with them. SNAFU, but now sorted out. It's just so irritating to RTFM and then find out that it is BS. Petri

It seems that the criterion for worksheets does not work. Eg. MESSAGE(COUNT(T=SPRDSHEET)); returns zero regardless of the number of worksheets. I guess I have to walk through the name list... Again...

Quite a few people here seem to have problems with Vista...

Thank you very much, Ray! Got it to work. Some puzzling questions still remain. In a polyline with more than one arc, there seems to be the curvature issue for each. Oddly enough, it also seems that if the polyline is clockwise, all works fine here in the lab at least. (Fortunately I have a ?reverse direction? command in my kit and this solves the situation.) Another one is that if the radius is ?illegal? (too large), the polyline data contains the specified radius and there doesn't seem to be a way to inquire the radius actually applied. (Maybe I have to decompose a copy, check the radii and adjust them?)

Ray, Brilliant! I've wondered what these structures could do for me, but now I see it. I have quite a few plug-ins that use bubble sorts ?by reference? (ie. I sort by a value, but actually use another array reorderd by the sorted one.) Thanks! Petri

To all questions: I would think so. Point number would be easies as a seemingly arbitrary number (running sequential number in the creation order of objects.) By description you mean what? Implict (END or VERTEX) or somehow explicit (entered)? Curves... Here we have a problem. 3D-poygons do not have curves, only straight segments.

I thought this would be easy... A user wants to place a stake (with x/y coordinates) at the centre of each arc in her polylines (plenty of them...) The calculations seem to depend on the curvature of each arc (the famous clockwise conundrum revisited), but I can't figure out what triggers the dicotomy. Here's what I am trying to get: dx & dy values like this (see attachment): The code looks like this PROCEDURE CentrePoints; VAR obHd : HANDLE; clockWise : BOOLEAN; t : INTEGER; x, y, dx, dy, a, aR, a1, a2, r, d, l : REAL; v1, v2 : VECTOR; BEGIN obHd := FSACTLAYER; GETPOLYPT(obHd, 1, x1, y1); GETPOLYLINEVERTEX(obHd, 2, x2, y2, t, r); GETPOLYPT(obHd, 3, x3, y3); v1.x := x2-x1; v1.y := y2-y1; v2.x := x3-x2; v2.y := y3-y2; a1 := VEC2ANG(v1); a2 := VEC2ANG(v2); a := ((180-ANGBVEC(v1, v2))/2); aR := TAN(DEG2RAD(a)); d := r/aR; l := SQRT(r^2+d^2); a := DEG2RAD(a-a1); dx := l*COS(a); dy := l*SIN(a); LOCUS(x2-dx, y2+dy); clockWise := GETOBJECTVARIABLEBOOLEAN(obHd, 652); MESSAGE(clockWise); { if FALSE, this works } END; RUN(CentrePoints); and works when the clockwiseness is False. Also, I may be on the wrong track entirely.

I don't believe it is necessary to rewrite everything again at one go. If I understand correctly, the advantage of object-orientated programming is that replacing objects with better ones is relatively easy (compared to old techniques.) The problem, I think, is that many of these ?Odds and Sods? are more ?features? than useful functions. The reason for this is that the expectations of existing users and the criteria of prospective ones focus mainly, if not solely, on price. Unfortunately many people think that if they need to spend even nearly as much money in VW than in competition, they'll be better off buying AutoCAD, Revit or whatever.

I'm not quite sure if I follow, but ? for better or worse: 1. No. A symbol definition does not have (graphic) attributes of its own and an instance (or components of one) cannot inherit those of its class. 2. However, such inheritance (and more) is possible with parametric objects.