Jump to content

panta rhei

Member
  • Posts

    359
  • Joined

  • Last visited

Posts posted by panta rhei

  1. 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.

  2. 3. Distribute it to international vendors who are able to localise it, working closely with those vendors to keep the base app as usable and neutral as possible.

    4. Where international vendors exist that do not do localisation or only to a limited extent, NNA passes it onto yet another division within NNA that deals with localisation for international markets, before passing it onto the vendor (e.g. the UK).

    Spot on.

  3. 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.

  4. M

    Petri,

    Our distributors in many of our international markets do take it upon themselves to provide their users with sets of tools that more closely reflect their localized needs.

    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?

  5. 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?

  6. 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.

  7. 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?)

  8. 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.

  9. 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.

  10. IFor example, I want to be able to have multiple instances of the same symbol, set them on separate classes, and have each instance of the symbol take the attributes of its class.

    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.

×
×
  • Create New...