Jump to content

Petri

Member
  • Posts

    2,011
  • Joined

  • Last visited

Posts posted by Petri

  1. This is indeed interesting. The UK-based dissidents seem to have a very clear and relevant view on The Structure of the CAD Model, but the Home Team has, once again, dropped the ball.

    Apart from CAD-operator point of view and unless one is into Heavy Scripting, symbol folders are pointless. Purely a cosmetic feature: in a report of symbols, you can't have a column for the folder in which their definitions reside. Now, someone like yours truly could use symbol folders in reporting and such, but...

    (I'll reveal all my Trade Secrets immediately after NNA releases its objects and commands without encryption.)

  2. The issues are stored in a hidden record fomat named 'Issue Data'. The bad part is that there are 200 fields in the record format, four fields each repeated 50 times. The names of the first four fields are 'Note-1', 'Number-1', 'Date-1', and 'Approved-1'. Replace the -1 with -2 to -50 as appropriate.

    Dear me. This is extremely bad database design - shocking, in fact. Yours truly has a dynamic database system for versions; each revision just generates a row into the "Revisions" table - with more columns*, but then again, my system is intended for professional designers and big projects where 50 versions can easily be exceeded, when one considers the lifetime of a project from early sketches to as-builts. (A trade secret: two sequences of revisions. One "absolute", the other restarted by stage.)

    Anyway, I'm sure Lumberjacks designing McMansions are OK with NNA's system.

    EDIT

    *) More columns than four (50 x 4)! Not more than 200!

  3. I don't need a PIO inside another PIO. I need a PIO that

    (i) makes a hole in a wall in a way recognised by VW's IFC-export

    (ii) is parametric in the usual fashion, with all the normal features

    (iii) gets translated as an IFC door or window

    in this order of importance and without any libraries of "red symbols". In short: I want to be able to create door, window etc. objects that are, to the degree of accuracy of my choice, translated to IFC on one hand and to DWG/DXF on the other hand.

    ArchiCAD can do this. It may be that even NNA's doors and windows can, but that I cannot really subtantiate.

  4. Fundamentals does not have Plan Rotation, right?

    So, in all menu commands and tools, one needs to find out which VectorWorks the user is working with?

    This is getting complicated. I can't recall that something like this would have been submitted when the notorious "Industry Series" were introduced. The Rich Pledge was that they will provide additional functionality...

  5. The lasagne is in the oven, so I have a few minutes... OK, I cheated: I used tomato paste, instead of cooking the sugo from fresh (or even tinned whole) tomatoes and did not make the lasagne sheets myself. One of those days...

    PROCEDURE ResizeRectangles; { ? Petri Sakkinen 2007 }

    CONST

    { Constants are fixed values that can be used anywhere in the script. The value given implies the data type. }

    theChange = 12; { We have an integer; the value is half of the desired change of size, for reasons perhaps explained later. }

    VAR { Variables, well, vary during the execution. In addition to the useful variables, here we have a few redundant ones that I "declare" in every script. }

    x1, y1, x2, y2, x0, y0, dx, dy : REAL;

    obHd : HANDLE; { One, hmm, handles stuff with handles. If there is an object you want to deal with, first you have to get a handle to it. Thus, obHd. Could be objHd, theObject, theCat, theBlowerOnTheRight or whatever. Maybe "it".}

    BEGIN

    obHd := FSACTLAYER; { We are starting the handling from the FirstSelectedobjectontheACTiveLAYER... )

    WHILE NOT (obHd = NIL) DO BEGIN { ... and shall continue as long as there are selected objects on the active layer. }

    GETBBOX(obHd, x1, y1, x2, y2); { How big is "it"? What is The Bounding BOX? The coordinates of the top left corner and the bottom right corner are read and placed into VARiables. See: we needed variables! }

    SETBBOX(obHd, x1+theChange, y1, x2-theChange, y2); { Make "it" this big, will'ya. Now we retrieve the variables and set the corners. }

    obHd := NEXTSOBJ(obHd); { We're ready, so we'll "traverse" to the NextSelectedOBJect. When we said "FSACTLAYER", we established the list of objects we want to handle. }

    END; { No more selected objects on the active layer. }

    END; { Every beginning has an end and every silver lining has a cloud. }

    Ahh, the dinner is ready!

    EDIT

    False alarm. The bechamel had sheep's milk pecorino which made it to get brown too early and the smell of nutmeg did not really help... No, it's not ruined, but thanks for asking.

    Most scripts that handle things use the construct "obHd <> NIL", which is fine. I just find "NOT (obHd = NIL)" more elegant; besides, "obHd = NIL" can be nicely used in a REPEAT - UNTIL loop, which may come handy, too.

  6. Right.

    PROCEDURE ResizeRectangles; { ? Petri Sakkinen 2007 }

    CONST

    theChange = 12;

    VAR

    x1, y1, x2, y2, x0, y0, dx, dy : REAL;

    obHd : HANDLE;

    BEGIN

    obHd := FSACTLAYER;

    WHILE NOT (obHd = NIL) DO BEGIN

    GETBBOX(obHd, x1, y1, x2, y2);

    SETBBOX(obHd, x1+theChange, y1, x2-theChange, y2);

    obHd := NEXTSOBJ(obHd);

    END;

    END;

    EDIT

    Now, one could have theChange as a variable and get the value with a RealDialog, then divide it by two (theChange := theChange/2). But this was supposed to be a learning experience - constants are very useful.

  7. As I've said many times, one of the problems is that non-US users have to pay for content and PIOs that are of no use to them and then pay also for the local content.

    One way to work with the local distributors would be to provide cheaper versions without the useless content.

    No, Fundamentals is not the solution. Although it may not have much content, it is crippled as comes to adding the local content.

  8. Not quite sure what you are after... Because of public outcry and protest, I usually no longer post scripts here, but I think I'll make an exception this time and just face the wrath of the riff-raff... Yes, it is quite OK to have ? in such a short script, you nitwits, nincompoops and otherwise average VW users!

    Assuming that the rectangles are supposed to be 24 x 24 mm:

    PROCEDURE ResizeRectangles; { ? Petri Sakkinen 2007 }

    CONST

    theSize = 24;

    VAR

    x1, y1, x2, y2, x0, y0, dx, dy : REAL;

    obHd : HANDLE;

    BEGIN

    obHd := FSACTLAYER;

    WHILE NOT (obHd = NIL) DO BEGIN

    GETBBOX(obHd, x1, y1, x2, y2);

    HCENTER(obHd, x0, y0);

    x1 := x0-theSize/2;

    x2 := x0+theSize/2;

    y1 := y0+theSize/2;

    y2 := y0-theSize/2;

    SETBBOX(obHd, x1, y1, x2, y2);

    obHd := NEXTSOBJ(obHd);

    END;

    END;

    RUN(ResizeRectangles);

  9. The other option of course is to develop your own PIOs for doors and windows. This is done for the local versions in Germany/Austria/Switzerland and Australia/New Zealand.

    This is exactly what I have done. However, doors & windows need to be IFC-compatible and so far NNA has not been willing or able to provide any documentation or assistance on the subject.

  10. Naww... They can't make the fast & simple classic dialogs obsolete! (Or can they? In fact, they can. They can also make Modern Dialogs obsolete and replace them with undocumented & version-dependent NNA_Dialogs.

    FUNCTION vsmDialogXYZZY(a : INTEGER; b: LONGINT; c: REAL; d : REAL; e : REAL; f : STRING; g: STRING; h : CHAR, i : DYNARRAY OF INTEGER; j : A_VARTYPE_WE_DO_NOT_REVEAL_TO_YOU_SUCKERS_HA_HA_HA;): BOOLEAN;

  11. Indeed. And the onus of localization would be with the distributor, so Katie & co could blame the non-performing distributor for not delivering.

    It is my understanding that only some 40% of the market of VW is in the U.S. of A. (Whatever "market" means.) As the majority of new CAD-software licences will be sold in various developing economies (former Communist block, India, China etc), the "bias" is a threat to us existing users: if VW does not become a globally useful program, it will disappear from the global marketplace and just be what it essentially has already become: McMansionWorks, with 200 dormer window types and 300 variations of the American Gothic Window with Shutters and optional Magenta glazing.

    EDIT

    Yes, I know that the dormer windows were programmed by an Indian software company, to meet the demand somewhere: there are hundreds of Indian drafting services doing work all around the world. However, the demand for dormer windows is very, very limited outside the U.S. of A. I don't think I have seen any in China or India...

×
×
  • Create New...