Kool Aid

A user is expected to show all changes in her dimensions. The quick solution was to establish a Dual Stacked dimension standard and push all current dimensions into the leader of the secondary dimension. This has to be repeated for all issued sets ? and must not be done during a revision round ? but seems to do the job. Filtering (only changed dimensions to be flagged) should be added and another command for toggling the display of the sec. dims. may be needed, but it is a start. If someone else wants to continue? PROCEDURE PrepareDimForChange; { ? Petri Sakkinen 2009 } CONST altStandard = 'the name of your double dim style'; VAR obHd : HANDLE; dimString : STRING; PROCEDURE PrepIt; BEGIN dimString := Concat('[', GetDimText(obHd), ']'); SetObjectVariableString(obHd, 27, altStandard); SetObjectVariableString(obHd, 24, dimString); { leader } SetObjectVariableString(obHd, 25, ''); { trailer } SetObjectVariableBoolean(obHd, 23, FALSE); { display of dim off } ResetObject(obHd); END; BEGIN obHd := FSActlayer; While Not(obHd = NIL) Do Begin If (GetType(obHd)= 63) Then PrepIt; obHd := NextSObj(obHd); END; END; RUN(PrepareDimForChange);

A user wants to put revision marker symbols into viewports, to tally them for each sheet & version. Oddly, these symbols are on layer ?none?, ie. annotation objects do not belong to any layer. Is this a Good Thing? What purpose does it serve?

I've probably lost it somehow? I'm not saying that the improved rectangle wouldn't be at least a tad difficult for those of us who were used to the peculiar behaviour of the old one. The 90? issue: now, let's assume I'm rotating my rectangle in interactive mode. For some reason, it happens to end up in the said angle (and especially with a rotated plan, it very well might, unintentionally.) Would I want the width and height change places when the angle changes from 89.99? to 90?? I don't think so! However, the Rotate command could be re-engineered to accommodate the quite reasonable wish by our square colleagues. I just tested the theory with my old custom rotated rectangle PIO and a custom 90? rotation command. Worked very well! I'm confident that the 20-line command could be made to work with native rectangles as well and fairly confident that NNA could do this, too, Then we'd all be happy! EDIT Well, there you go! With native rectangles it was even easier: PROCEDURE RotateRect90; VAR obHd : HANDLE; rHeight, rWidth : REAL; BEGIN obHd := FSActLayer; rHeight := HHeight(obHd); rWidth := HWidth(obHd); SetHeight(obHd, rWidth); SetWidth(obHd, rHeight); END; RUN(RotateRect90);

Orso, Orso? I'm yet to see what the new stair tool does, but, without prejudice, I have great faith in German engineering and am looking forward to using the new stair tool.

Well said, Christiaan! In my tools, I have dialogs only for very specific uses: access to certain resources (mainly symbols and wall styles) and obscure settings that no-one really needs, but have to be there since I always have to expect the unexpected. We hatess dialogs! They're bad interface!

Well I am not talking about 3D. We use them for the ends of handrails in 2D. Losing a feature doesn't make a lot of sense IMHO. V-G Good point ? thanks! I have to borrow a feature from my Buffer Zone tool into my Double Line tool. The buffer can have round ends already, but it does not have the offset feature of the double line.

Ahh, no: not really. It just turns out that the North Pole is a rather big area as comes to usefulness of ?integrated products?. Occasionally I want to refer to the 78% of users who live in North Pole instead of U.S. of A. In fact, even some citizens of USA feel to be living in my region.

Right, OK, OK. There just are countries where irrigation is not particularly common or needed and then countries where it cannot be used because of water restrictions even if you have it. What people ?want? is in the latter case rather irrelevant. But I have to confess that largely my scepticism is based on experience: NNA has been phenomenally successful in creating ?industry solutions? that are totally useless outside the U.S. of A. The core technology they tend to get at least almost right, but most the tools (?Integrated Products?) in at least Architect and Landmark simply cannot be used eg. here in the North Pole. What these tools produce cannot be used in contract documentation, not to mention the actual design process. Anything bigger or more complicated than a house and a house lot is simply beyond their capabilities. The NNA integrated business model is, however, such that the majority of users are forced to buy the useless stuff just to get the useful core technologies.

Possibly. The US is a rather tiny market for VW. The industry practices there are not necessarily applicable elsewhere. Yet, you want the majority of VW users to subsidise you. Why irrigate in the first place? If you need to conserve water, you simply don't.

Oh, so do I! I can easily imagine a situation in which eg. Tekla Structures helps the structural engineer to determine the reinforcement of structures of an olympic Vvenue, an opera house or a bridge. Suburban architects designing houses without engineers? Suburban engineers doing Computations for carport extensions? Ah, well!

Daresay, irrigation is not a key question: there are plenty of countries where that is not an issue at all. Then again, in other countries it is of huge importance ? but in those countries (eg. Australia), the landscape architect should minimise the waste of water and provide design solutions that don't require irrigation.

Good point, Christiaan.

Re: Curtain walls, but with broader applicability. Can we please have the ability to embed walls in PIOs in such a manner that other PIOs (doors, windows or whatever) or symbols could be inserted via the standard UI to these walls.

I am indeed. Walking the dog this afternoon, I realised that a wall behaviour could quite easily (?) be added to a designated part of Curtain Wall object. After all, there are already several specific behavioural components in PIOs. However, there are also issues related to user interface and (lack of dynamic) data structures that are unsatisfactory in this respect. Take even a 20-storey high curtain wall? My perspective here and now is that of a programmer, but when I am a user, I would desperately need the ability to insert at least (non-standard sized) doors into curtain walls ? which in my world are not necessarily glazed at all and seldom only glazed. (Doors, in my world, can be made to any size.)

But where's the BIM? The sad fact that even A or B cannot create curtain walls in a sensible BIM-way is not an excuse. In fact, it is an opportunity! Now, code for this would have 90% of the code needed for insulated precast sandwich elements and vice versa? Oh, shucks! I forgot the pathetic IFC, void of complex lexical/semantic structures??

Even so, modeling every rebar is pointless. Even in a modest 10000 m2 5-storey building there are tons of reinforcement. A section, a type; for beams and columns maybe a plan and an elevation, but typically the same beam or column is used tens of times.

I did it again: I dimensioned witness lines! Wish 1: Witness lines should not be snappable. Wish 2: Objects in any user-defined class should not be snappable. Option to both wishes: When dimensioning is concerned. But rather without this option.

The Main Censor Mike M Oz has AGAIN deleted my message, so here we go again (this time I was clever enough to have a copy): What help? No-one here can help you. This plug-in is faulty. It does not work. Even seeing the Error Output makes no difference, since there's nothing you or anyone else can do. The plug-in in question has an internal problem caused by bad programming by NNA. I know a thing or two about VectorScript plug-ins since I have over programmed over 300 of them for my own system. (I'm pretty sure one of the moderators will remove this message as he, for reasons beyond my comprehension, feels the need to prevent the Awful Truth to be told. But then again, why else would he be a moderator?) Mike, Mike: how many rounds do we need? (I took a copy of this, too.) And, Mikey, Mikey: I've sent the message you censored as a private message, too. Surely even you won't dare to censor private correspondence? EDIT 2: Yes, that last paragraph has also been sent in private messages and email.

This is an interesting subject! Users of DTP & pure graphics programs seem to prefer (won't discuss the reasons) the ?click and hold? approach and that indeed appears to be the mainstream method. So, the choice depends; consistency between applications or not. (I prefer not: horses for courses.)

There are ?non-functional? variables in quite a few VS calls. An Authority has a host of examples in which they are called ?ThisDoesNothing? or something similar; another Authority a set of variables called IntJunk, RealJunk, StrJunk etc. It's not as bad as it sounds? In the history of VS/MiniPascal, there are more than enough of examples of ad-hoc calls that do not have the potential of added functionality. Your concern may be just a case of a not-yet-implemented feature. With any luck, NNA might finally comprehensively document the relevant alternatives: the various Prefs and ObjectVariables. After all, the progam knows the selection box size and can change it. Us mere mortals are just not allowed to know how it is done. Not in MiniPascalCallBacks or VWPluginLibraryRoutines? Well, hurry up then, Mr. NNA: we want access to all settings like this. When do we want it? Now!

I don't think they have even 1% of the code. Walls that accept openings (doors & windows) are fundamentally something completely different than curtain walls. But please tell me that I'm wrong!

A lot of VW users couldn't care less of the Residential Code of New York State. Approximately 99% is my guess.

?Events How to enable the extended plug-in properties and handle script specified events. By Charles Chandler.? http://www.vectorlab.info/index.php?title=Events Plenty of examples. ?Extended Properties Using the Extended Properties features, more behaviors are available to VectorScript objects. Before you start using these advanced features, you should understand that PIOs that use them are three times more complicated than PIOs that do not. The nice thing about "regular" VectorScript objects is that you can get decent results with a minimum of effort. You may not be able to get exactly the behaviors that you want, but what you do get, you get easily. ? Maybe Mr. Chandler exaggerates a bit, but the complexity (and, I'm afraid, unpredictability) is an issue to consider. If you can live with a less-than-perfect user interface, a Boolean parameter to bring up the dialog would be much easier to implement. EDIT But, hey, it is doable! Even I've managed to get a PIO or two to occasionally have and use buttons. Knowing nothing about your program structures, but assuming a thing or two: the ?main? sections have to be restructured. There are caveats: my favourite one is that responsiveness to the Text menu (obj var boolean 800) has to be in the reset loop although it would be logical to require that only in the init section.

Wonderful, admirable, fascinating! OK. We have a scale issue here: I've never designed a house, so I have no idea of the requirements. The engineers' drawings of beams, columns, slabs, foundations etc. I've dealt with have been remarkably detailed and largely beyond my comprehension, especially as comes to pre-stressed elements. I couldn't build even a dog house?

No, it is not. Unless the Architect is also a Certified Structural Engineer and does all the computations etc. in the project, he or she should NOT show such things in his or her drawings, otherwise he or she may become responsible for them. EDIT Or, even worse, responsible for discrepancies between his or her drawings and the Engineer's drawings: a situation which buys the Contractor a new Porsche.