Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About LarryO

  • Rank

Personal Information

  • Location
    Victoria BC Canada

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Has anyone else noticed that with VW2019 that the separators on the Mac platform have changed from forward slash "/ " to hyphen "-"? Also Date(2,0); VW2019 generates yy-mm-dd where as VW2013 generated mm/dd/yy on the same MacBook Pro. Did the function get tweeked to generate the same output regardless of MAC/PC platform? If so, would have been nice to also make the month and day always generate 2 digits. PCs generated hyphens and MACs forward slashes. I don't recall it ever being system setting sensitive but it was definitely platform sensitive.
  2. LarryO

    GetPtL (VW2013) not collecting point values

    I can't see how RunTempTool could work. One has to pass it a Function and GetPt and GetPtL can only be called from a Procedure. I experimented vstGetPt2D also choosing index #0, 1 and 2. Zero returns the world coordinate point for the PIO origin and one returns the second world coordinate point of the linear PIO. Two returns garbage, not the control point location. I do not think that these user interactive calls can work in a linear PIO. Once the PIO environment is created they crash and burn because they seem to be seeking information from the world environment that is somehow not available to them anymore. So it would seem that I am stuck with what I have or taking some lessons on creating a custom tool to collect three points then call the linear PIO and somehow pass the values onto the procedure. While still permitting the procedure to act alone in regenerating itself after OIP changes and dragged point changes. hmmm
  3. LarryO

    GetPtL (VW2013) not collecting point values

    Thanks Josh & Raymond for the assistance. I still have to tackle moving my control point into position so that it remains vertical to the origin in World space and making the code flip friendly. The latter I've done before so it will not be too much trouble. I still hope to figure out how to have GetPt retrieve values and pass them into a variable before the code finishes. It'll be such a pain if I have to deselect the tool every time to move the control point into position (it identifies the upper boundary of the pickets) and then re-select the tool to draw the next set of pickets. This is a functional result, but has limitations. Only works from left to right ATM. It still has fluff code in it and some clarity formatting was lost during pasting. Procedure Picketeer; VAR PIO_Handle,PIO_ParentWall,PIO_Record,hLine1,hLine2: HANDLE; PIO_WorldOrigin: POINT; PIO_Rotation,rOffsetDistance:REAL; iAccuracy: INTEGER; Quantity: LONGINT; PIO_Name:STRING; Bool1:BOOLEAN; cpLocation,cpDestination: VECTOR; {This Function may be required during improvements, leave in} Function HDuplicatePolar(H :Handle; Dist, Ang :Real) :Handle; { Same as HDuplicate() using POLAR coordinate input } Var V :Vector; Begin V := Ang2Vec(Ang, Dist); { convert polar to rectangular} HDuplicatePolar := HDuplicate(H, V.x, V.y); End; { Function HDuplicatePolar} BEGIN PushAttrs; FillColorByClass; FPatByClass; PenColorByClass; LSByClass; LWByClass; MarkerByClass; OpacityByClass; {initialize required variables' values} Bool1:=GetCustomObjectInfo(PIO_Name,PIO_Handle,PIO_Record,PIO_ParentWall); GetSymLoc(PIO_Handle,PIO_WorldOrigin.x,PIO_WorldOrigin.y); PIO_Rotation:=HAngle(PIO_Handle); {IF GetPrefReal(152)=1.0 THEN iAccuracy:=4 ELSE iAccuracy:=0;} {imp vs mm, currently not req'd} cpLocation.x:=PControlPoint01X; cpLocation.y:=PControlPoint01Y; cpDestination:=Ang2Vec(PIO_Rotation, PLineLength); Quantity:=0.5+(cpDestination.x+PPicketSize)/(PMaxGap+PPicketSize); {includes final picket which is replaced by next post} rOffsetDistance:=(PlineLength+Ppicketsize)/Quantity; {centre to centre picket spacing} MoveTo(0.0,0.0); {creating first picket} LineTo(0.0,NORM(cpLocation)); hLine1:=LNewObj; HRotate(hLine1,0,0,-PIO_Rotation); {orient first picket line vertically} hLine2:= HDuplicate(hLine1, -PPicketsize/Cos(Deg2Rad(-PIO_Rotation)),0); Hmove(hLine1,rOffsetDistance,0.0); {Move first pickets into place. Could have started at this location instead of orgin.} Hmove(hLine2,rOffsetDistance,0.0); {Easier debugging of flip & rotation issues} While (Quantity>2) Do {place remaining pickets} BEGIN hLine1:=HDuplicate(hLine1,rOffsetDistance,0.0); hLine2:=HDuplicate(hLine2,rOffsetDistance,0.0); Quantity:=Quantity-1; End; PopAttrs; END; RUN(Picketeer);
  4. LarryO

    GetPtL (VW2013) not collecting point values

    The pickets are only a series of lines on the slope of the rail. I group them when drawing them manually. So I am capturing 3 points and pre-setting picket diameter and max gap values. The nature of doing shop drawings, updating for site measures is that I created a tool which defines the measured stair with only two points and a few pre-set building code defined values; drawing in top and bottom rails that can be traced over or used as is. Then we manually place posts due to the variety of (un)suitable anchoring conditions, locations and styles that seem to occur within a single flight sometimes. And finally draw in pickets where required on a separate layer to make them print grey). So I am finally getting around to making a plugin to automate the task of calculating quantity and then spacing them equally along the incline of the rail. Hence my desire to simplify it all down to a three point task (2 steps) from what is currently about 12-14 steps if one does them in the correct order. I'm sure that the SetRField works as you say it does; I just have a problem mixing up strings and character arrays all the time. ATM I am trying to decide if I should Create the first line and copy along the incline or or draw along the axis and rotate them all into position. The latter is how I approached the stair tool because HDuplicate(objecthandle, distancevariable, # anglevariable d); fails. The angle mode indicator # does not appear capable of accepting a value from a variable. So much simpler if Polar vector variables were an option.
  5. LarryO

    GetPtL (VW2013) not collecting point values

    I've had issues with using a variable in the name location of SetRField so I've always typed it in. The thing is that the control point is not moving to the user selected point location. I suspect GetPtL is not capturing values during first pass. The control point remains at the default location set by the parameter default values. The exercise here is an attempt to have the control point set during the first run (placement) of the plugin and not have to drag it over to the correct location afterwards.
  6. LarryO

    GetPtL (VW2013) not collecting point values

    I would guess from what I have observed is that GetPt and GetPtL are not suitable for inside a Plugin object (VW2013). This will display the Message and draw the Line and request a point from the user. Bool2:=FALSE; IF IsNewCustomObject(PIO_Name) THEN Bool2:=TRUE; IF Bool2 THEN Message(cpHeight.y,'x',bool2); IF Bool2 THEN GetPt(cpHeight.x,cpHeight.y); MoveTo(0,0); LineTo(0,0); This will draw the Line and request a point from the user, but not display the Message. Bool2:=FALSE; IF IsNewCustomObject(PIO_Name) THEN Bool2:=TRUE; IF Bool2 THEN GetPt(cpHeight.x,cpHeight.y); IF Bool2 THEN Message(cpHeight.y,'x',bool2); MoveTo(0,0); LineTo(0,0); This will draw the Line and request a point from the user, but not display the Message. Bool2:=FALSE; IF IsNewCustomObject(PIO_Name) THEN Bool2:=TRUE; IF Bool2 THEN GetPt(cpHeight.x,cpHeight.y); MoveTo(0,0); Message(cpHeight.y,'x',bool2); LineTo(0,0);
  7. Some curious activity happens with this preliminary scripting. Testing units are mm. Message screen is displayed before closing plugin's default record initialization dialog. Message screen is updated to reflect changes in default record initialization dialog before GetPtL point has completed selection. GetPtL doesn't save value of point selected. Zero is being displayed as value stored in cpHeight.y And finally ControlPoint01Y is not being overwritten with the value in cpHeight.y. (perhaps cpHeight.y is NIL and not zero, but Message displays 0 and not NIL) What am I not understanding? VAR PIO_Handle,PIO_ParentWall,PIO_Record: HANDLE; PIO_WorldOrigin: POINT; PIO_Rotation,rTemp:REAL; iAccuracy: INTEGER; Class_Name,PIO_Name:STRING; Bool1,Bool2:BOOLEAN; cpHeight: VECTOR; BEGIN PushAttrs; FillColorByClass; FPatByClass; PenColorByClass; LSByClass; LWByClass; MarkerByClass; OpacityByClass; Class_Name:=ActiveClass; Bool1:=GetCustomObjectInfo(PIO_Name,PIO_Handle,PIO_Record,PIO_ParentWall); GetSymLoc(PIO_Handle,PIO_WorldOrigin.x,PIO_WorldOrigin.y); IF GetPrefReal(152)=1.0 THEN iAccuracy:=4 ELSE iAccuracy:=0; IF IsNewCustomObject(PIO_Name) THEN BEGIN GetPtL(0.0, 0.0, cpHeight.x, cpHeight.y); SetRField(PIO_Handle,'_StairOutline','ControlPoint01X',Num2Str(iAccuracy, cpHeight.x)); SetRField(PIO_Handle,'_StairOutline','ControlPoint01Y',Num2Str(iAccuracy, cpHeight.y)); END; MoveTo(0,0);LineTo(cpHeight.x,cpHeight.y); MoveTo(0,0);LineTo(600,0.0); {ResetObject(PIO_Handle);} Message(PControlPoint01Y,'x',cpHeight.y); PopAttrs; END;
  8. Sounds like a control point is the way to go. I'm spacing pickets between two posts of a sloping guardrail on a frequent basis. It is much simpler to graphically determine the height between the top and bottom rails than it is to calculate it. Same goes for the slope and linear path. We've currently got a reasonably quick manual strategy but it requires about a dozen steps for each panel, each time there is an adjustment to the guardrail.
  9. Thanks for a quick response. I'm wondering whether a control point might work in lieu of a third point during placement. I've not used them before so I will have to experiment first I guess. I can't seem to find the Wiki you mention. My google searches kept winding up at developer.vectorworks.net main page.
  10. LarryO

    Phantom Records

    Just speculating here, but could these be record definitions and not actual records. When you go to the data tab of say a symbol and there you find record definitions which can be associated/attached to the symbol by checking the adjacent box. When you search for records it will seek and find the ones attached objects and from there you can extract the stored data. But the definitions themselves contain no data other than their format and are stored in another place much like symbol definitions waiting to be copied and attached to some location on (or in) a layer.
  11. Has anyone got an example of a plugin which requires three points of input? Is there a means to limit the 2d path object to only three points of entry, without the user having to do double click termination? I wish to place posts along a straight line path and enter height during the placement. First point = origin / start point Second point = direction and distance(magnitude) Third point = height from one of the other points, preferably the origin
  12. LarryO

    Units...need more control

    I don't know much about the grade objects functionality, but with dimensions you utilize a dual dimension style, set the secondary units and suppress the display of the either the secondary or primary units. I've used this where both metric and inches were required in the document. Normally I'm only suppressing the secondary units; fractional inches require too many characters to communicate small values.
  13. LarryO

    Messages and Includes

    Do you not require a single period or double period before the slash. Single period representing the current directory and double period meaning go up one directory level. Also is the mac platform freed from activating Unix escape sequences (like \n ) when utilizing back slashes? You might need \\ to break the escape sequence. I'm no guru when it comes to Unix but I just read about this potentially being a problem when scripting. Of course one cannot span drives when using relative paths; only the active drive is accessible.
  14. This would essentially be a Boolean parameter for PIOs which does not look like a check box. It could have two script loaded images (tool resources?) to display in the OIP to indicate the state of the button and return TRUE/FALSE. The same concept applied to a Radio Button parameter. Each choice having the ability of displaying one of two images (no text or radio button). Default image = non-selected, Alternate image = selected option. This could possibly lead to additional functionality of being able to select more than one option. This could be achieved by passing indices or Boolean flags back to the script. A PIO script can easily parse the result via a case statement. Once UTF-16 is fully implemented there maybe sufficient glyphs available that a button outline with text embedded will be able to convey the desired thought. The outline or background would alter to convey select state. Please ignore if this is in the current version. This office is using VW2013
  15. LarryO

    Vectorworks User Interface Overhaul

    I certainly hope that the following is a non-starter. This concept of embeding functionality into a multi-purpose tool is a time waster. The ability to edit one's workspace environment is where this type of action is best addressed. Create a new palette for items that one perceives as functionally similar; drop items that your usage doesn't warrant access to, but please do not embed functionality into another selection tier that must be chosen before the tool can be accessed. Can you imagine having to select a pencil tool to draw something then a pull-down menu to choose between a line/circle/rectangle/double line/etc. where circle is the first and default selection because of alphabetical sorting of the pull-down. As it stands I am frustrated daily with the fastener tool which in VW2013 is the only means to draw structural bolts. The default is determined by a pull-down menu where the first item in the list (the default) is a socket head bolt (rarely if ever used in structural assemblies). Then you have to choose the corresponding structural nut. Which could have been a default because unless you are building a go-cart you would never mix non-structural with structural components.


7150 Riverwood Drive, Columbia, Maryland 21046, USA   |   Contact Us:   410-290-5114


© 2018 Vectorworks, Inc. All Rights Reserved. Vectorworks, Inc. is part of the Nemetschek Group.