Kool Aid

Let's take a step back, shall we? What do you mean by ?architectural modeling?? Visualisation or modeling the actual building as it will be built? VW is a CAD-program, with a focus on the latter. Form?Z is a generic 3D-visualisation program, with a focus on the former. Different worms for different cans. Even if you are to to be part of actual architectural design & documentation projects, the workflow may be such that only dumb visualisation is required; for this Form?Z would, I believe, be vastly superior. Should you, however, be involved in preparation of the ?real thing?, Form?Z is, I believe, useless. No, not useless, but a cul-de-sac.

File/Batch Convert? first. After that, the Resource Browser favourites may well need to be re-established, unless you successfully copy the old Preference file to the new location. Sorry: I have no idea what that location might be in Windows. Nor do I know whether the copy operation can be successful. Worth a try? EDIT What nonsense! The new libraries must be in a new location, otherwise the old VW version loses the links. Preferences are kept in an XML-file, which is plain text. Search & replace the folder path!

So do I. Unfortunately, somehow I think we're not going to have it. It appears that a VP is not a ?true? object (although I'd love to be proven wrong!) and thus lacks behavioural means required for this. (Just spent the best part of yesterday making new viewports?)

some people prefer lifestyle products. Oh yes, we do! Our lifestyle is such that we do not want to have any hassles with our computers nor do we want to know anything about them. We expect them just to work, like refrigerators, TVs and other appliances. We're beyond the Fascination of Crank Starting our cars of any colour after Adjusting the Throttle, Fuel Mix and Ignition, too. We're grown-ups, you see, sipping our Mint Juleps on the Porch while Kids play with their PCs, shaking our graying heads on the Innocent Pleasures of Childhood.

I can't make it change? It just is there? So, yes: seen the behaviour, can't fix it.

Ahh: a spanner in the VectorWorks? How wrenched! Looks odd. Have you added Tool Sets? Have you, by any chance, quit & restarted VW? (I notice that you are a Mac user, so having a program running for weeks and months without quitting is not particularly extraordinary.) After a relaunch and then using the workspace editor would be the next step. Re-installing after that, methinks. (You won't lose too many, if any, settings in that.)

As far as I know, VW can convert long/lat coordinates to Cartesian coordinates only when importing ArcView (=Shape) files. Furthermore, AFAIK, these conversions are not necessarily universal: many countries have one or more specific Cartesian coordinate systems and zones. Should I go and buy coal to fire up my last working G4 Mac with an ancient MapInfo in it, I could ascertain this: when exporting to a Cartesian coordinate system, there are tens of options. Our friend Professor Trimble from the Dominican Republic has made it quite clear that VW cannot utilise GPS data. I have no reason not to believe him.

Fair enough ? but the DTM engine works just the same way regardless of grain or input method. The whole idea of the DTM is that you get an interpolated, triangulated (TIN) surface. GPS? I don't think so, at least without middleware.

No, I want the PIO (VSO) to control its own wall break ? as advertised. In certain circumstances the PIO in question can have a capped wall break, in others, capping ruins the 2D. The circumstance is based on a number of parameters and conditions. The related calculations return correct values, but the advertised function (ObjVarInt 124) does nothing.

Forgot to mention: the current DTM-module cannot handle concave terrains. Either the results are plain wrong or the system crashes. I just tested with the afore-mentioned data set with reversed z-values. Crash, boom! The old one could. Obviously, they do not have concave terrains in the McMansion-country.

I've got a reasonably fiddly terrain: 3635 points. Tight? Well, it covers over 30 hectares, so not really tight. The contours are at 1 m interval, so the max elevation is 25 m (the site is at shea sore.)

It seems it does not work in a useful way for most projects: the LOCation is not limited to layers visible in the viewport.

Charles, It's not a parameter but a pop-up widget. I assumed that this ObjVar would set that wicked widget and change the behaviour of the PIO, but that does not seem to be the case.

The Create Report command is the easiest way to learn the formula syntax. In fact, to generate the formulae altogether, since the syntax is just a tad user-unfriendly: ='Record Format'.'Field Name' Copy/paste fortunately works.

Well, well. Interesting? Since a VP must technically be an Object, a Crop should be able to be made to automatically inherit a (derived) name. I think I'd prefer a reverse logic, though: eg. the first or last argument in the name string omitted (for the sake of report clarity & international applicability.) Meanwhile, this does open possibilities in the form of vectorworksarounds via scripting. Thou bringest good tidings indeed!

An excellent wish! Thus, it shall never be granted. Although Mr. NNA could perhaps build such functionality on the extremely useful and indispensable LOC -criterion. The Crop is a LOCation, after all. (LOC: if a ?shape? object (poly, rectangle, circle etc.) has a Name, a worksheet can query objects that are inside it. Say, one's rooms are named polygons: their inventories can be reported.)

OK. Found a vectorworksaround. The user is not amused. I have to find a way to embed the functionality into something? Why can't worksheets have attached scripts as Shaved Seets do? Open a worksheet and a script is run. Tell you what: I'd have many uses for that! But for the time being: Workaround script

Since objects in a viewport (annotation) are not on any layer, it seems that the only way to get them reported is to have a data record which is populated by a command. PROCEDURE ViewPortName; { ? Petri Sakkinen 2009 } PROCEDURE GetIt (h : HANDLE); VAR theViewport : HANDLE; vpName : STRING; BEGIN theViewport := GETVPGROUPPARENT(GETPARENT(h)); vpName := GETNAME(theViewport); MESSAGE(vpName); END; BEGIN FOREACHOBJECT(GetIt, (INVIEWPORT & (S='Your symbol'))); END; RUN(ViewPortName); Luckily my frustrated user I referred to elsewhere already has a record for revision data, so she only needed to add a field for the layer/viewport. Instead of messaging, the real thing writes the vpName to this ?Location? field. As a solution: satisfactory; as a need: nonsense! (Or whatever expression Nero Wolfe might use. Phooey?)

I mentioned this in passing some time ago, but now the situation is becoming acute. The ObjVar is supposed to control the wall break (full, half or none & caps) of a PIO. So SetObjectVariableInt(h, 124, 2); Message(GetObjectVariableInt(h, 124)); returns the value set by the user in the OI, not what the script says. Users can't be expected to remember that this must be changed in certain circumstances generated by parameters. Has anyone had luck with this? (No, I haven't submitted a bug. They, according to a reply once, ?do not support custom scripts. Yes, I even tried #126, which supposedly works on symbols.)?

This time I make an exception to my standing rules & procedures and give free advice to NNA: My title block object utilises a document-wide record (project data), which holds, among other things, the title block information that in 95% of cases (i) is shared and (ii) covers the required shared information. (The 5% can be attributed to strange projects and even stranger workflows.) If NNA does not have a similar facility, too bad. Maybe they should get an Architect on staff?

To be precise, layers have their own name space. All in all, I frequently get caught in this a situation, despite my ?rigorous? naming procedures. One of these days, a user will excplicitly name something either ?Zaphod? or ?Heart_of_Gold? and some of my menu commands cease to work? I wonder if this works: PROCEDURE What_is_in_a_Name; VAR aRose : STRING; BEGIN aRose := STRDIALOG('What is in a name', 'rose'); ALRTDIALOG(CONCAT('The rose is of type ' , GETTYPE(GETOBJECT(aRose))); END; RUN(What_is_in_a_Name);

Yes, there is. If a file is used to generate several drawings, the user wants to be able to list & count revisions by sheet/drawing. As she has been doing before. And all this is beside the point: the irate user (since 1988) has just changed her workflow and that's been a disaster. The whole point of the exercise was to get rid of the need of having symbols in different scales. Yes, mea culpa: I recommended the upgrade. Yes, we have used various queries, but ones requiring explicit layer names are not acceptable: they would totally defeat the purpose of viewports, so she has wasted all this money in VW upgrade. (Few, if any, other new features are of any relevance, since she uses a fully customised system by yours truly.) Heaps of pain, no gain. I'm beginning to see the point in having old versions kept compatible with new OS versions? NNA's new features are worthless, but one may need to buy a new computer nevertheless.

A much easier and more productive way would be to set up a class with graphic attributes that are ?Used at creation?.

In my experience, reallocation generates a Warning in the Error Output file, but I haven't experienced any crashes. Unless some of the unexplained, but recurring, crashes that seem to be caused by event-enabled PIOs in ?Compile in EACH invocation? -mode are in addition related to reallocation.

Yes, but if I have one or more symbols embedded in (ie. belonging to) a PIO, the layer can be listed in a report. How can my user get a listing of her revision markers by sheet/layer? If she can't, is there a reationale for this inability? I am starting to have serious doubts about the VP implementation. They are not real objects, so PIOs cannot effectively communicate with them. They are not Groups, either, because objects ?belonging? to them are not on layer. And so on. For a fundamental software design decision there must be a reason, a rationale. What might be the rationale for the non-functionality of viewports? Didn't anyone state the problem of the viewport properly? The lesson of the airplane lies in the logic which governed the enunciation of the problem and which led to the successful realization. When a problem is properly stated, in our epoch, it inevitably finds its solution. ? Le Corbusier: Vers une Architecture