LarryO

DBDocAddConn Connects a database to the document. I've ever used this aspect myself, so this may not fit your need. There is a ODBC class of database functions in the Vectorscript library.

It would seem to me with the limited info of the purpose that you are simply needing to use your existing PIO twice. Laying the smaller object on top of the larger one. I suppose you could use a tool to lay down the two instances and link them through unique data like a permanent handle concept so one instance can find and evaluate the data of the other. Or a tool that creates a plugin which monitors and evaluates two polygons. While tools can create two iterations of a PIO the result will be two separate instances of that PIO. Also if you deleted one of the data linked objects the other would be orphaned and possibly show wrong data or crash. More coding is required for such occurrences. FYI: Whether this is of use or not is to be seen, but your donut instance can be separated into two polygons by decomposing and then immediately recomposing them. Note the result is unperdictable if one or more of the definition points share the same location, ie the result is rarely two closed polygons.

Has anyone already reported that they cannot select the Note text of an ungrouped linear dimension string? Can only select via bounding or crossing box. Cannot select via single click, nor text edit via single/double click. Pasting a copy of the text onto a sheet or in a viewport, the copy will also exhibit this troublesome characteristic. VW2019 SP6 (64) Win10

For months now I've been annoyed with this behaviour. After being away for only a day a co-worker used my station to publish something and thereafter these little bird droppings appeared whenever I put together a pdf of drawings for review. The wording of that setting is certainly not obvious that it can change such behaviour. Thanks for sharing that info.

If I'm not mistaken the string values associated with a plugin are similar to the storage of default parameter values. They are stored in your application's workspace/ menu environment not the drawing file. This view is reinforced by the fact that there is no means to change the value from within plugin. While they could change from one Vectorworks installation to another that would be unlikely as the person who wrote the script would have to allow for every different variation. Such as having text strings for different language installations. The local VW reseller would be changing them in that instance before selling the regional version of VW to you.

ctrl up and ctrl down for VW for switching thru pages. and if mouse driver is application aware switch it to page forward and backward for browsers and windows file explorer. and similar for Bluebeam or Acrobat Reader. although if there are even more buttons than two thumb buttons, I think I would try forward delete and keypad enter if you are a left-hand typist on a full size keyboard. That way you don't have to release the mouse quite as often.

Thanks Josh, if they decide to update to VW2020 here I might take you up on that offer. [VW2019]

While there is the linear PIO template which displays the 3D origin, z-axis rotation and vector length; It doesn't display a WorkPlane angle. Is there a hidden special parameter name for a second 3D control point or WP angle? Has anyone seen an example of setting up the OIP for this? Are there guidelines for presenting an object in the OIP which has two 3D defining points? It's not flat to the world x-y work plane. Could it be the first or second example, or both or something else entirely? 3Dpoint origin(x1,y1,z1), 3Dpoint2(x2,y2,z2) 3Dpoint origin,rotation (about the z-axis), WP angle (from the world x-y work plane), vector length. Larry

Thanks Pat, I know you are with 99% probability correct. Today with a pre-defined 3D symbol that didn't contain the WF-3D PIO I was easily able to rotate it into the correct position. The concept of the environments inside and outside the PIO I have fairly down pat now. I created a stair and railing design tool about four years ago with the linear PIO template. I had that thing doing the flip and rotate dance all over the screen until I sorted out the relationship between an insertion point in the world origin and a PIO's internal origin. I may have to explore or rule out the possibility of a definition timing issue. When writing out a script for creating pickets in an inclined guardrail I had to separate it into a tool part and a linear object part. I simply couldn't capture the first set of control points inside the linear PIO. They had to be captured before creating the PIO using a creation tool. Aside from the WF-3D PIO, the original 3D symbol I attempted to rotate was defined inside the linear PIO. The PIO also places the instance which might not be created before the script attempts to rotated the instance. I forgot to put in a reset/regen. More testing required. Thanks guys for all the input.

Thanks Pat, I was making sure I fully explored Raymond's suggestions to see if I could find a work around. I have not had any issue yet getting the handle to the Wide Flange - 3D object. The issue has been getting one of the rotation functions to rotate it about the y-axis while it is inside the linear PIO that I've been writing this script for. Or converting devolving it from the Wide Flange - 3D object to the basic extrude for rotation. Failed on that front too. SymbolToGroup and Ungroup don't work on it either inside the linear PIO. I'm beginning to think that it is the linear PIO environment that is interfering the 3D operations. I tried to rotate a 3D symbol instead of the PIO last night and got nothing on the x or y-axis rotations, only on the z-axis. So I will probably have to write my own steel extrusion routine, because lengthening the extrusion in a linear fashion is the way to go with this. The current tool is too clumsy to create 3D structural assemblies.

Well guys, Julian , Ray, The fun continues. I was unable to convert an instance of a Wide Flange - 3D PIO to a group with SymbolToGroup() inside a linear PIO. (I ungrouped my linear parent PIO after it had finished and found the WF-3D PIO still existed.) I was also unable to rotate a 3D symbol about the Y-axis inside a linear PIO. I placed the Wide Flange - 3D inside a symbol, thinking that if I could rotate a symbol instance I could convert the symbol back to a group and ungroup that I could get the steel shape orientated in the direction of the control point. I am 100% sure that using LSActLayer is currently capturing a handle to the parent PIO and not the WF-3D PIO inside, which may rotate something other than the parent PIO once there a more objects in the layer. LNewObj does return the same WF-3D handle as the create custom object function. It's beginning to appear that the approach to tackling this little monster is to extract and import the beam data and create my own beam extrusion where the axial rotations can be set. Let's hope it is still possible to rotate or draw a polyline onto the y-z plane for extruding in the x direction. 🙂

The first goal after getting this Wide Flange laid down in a beam position in plan view is to be able to draw in one like we do lines. Drawing them out in linear fashion point to point. Springing up out of the ground plane as these steel shapes do they easily serves as columns or posts, but not so as beams and rails.

Hmmm, it does do a rotation but I'm fairly certain it's rotating the parent PIO and not the beam inside. Every time the PIO is reset it rotates to a new position, like when one changes the parent PIO's length either in the OIP or with the control point. I've never thought of a PIO being hybrid object like a symbol? Am I'm wrongly creating this 3D object in its 2D environment? EDIT: I don't think so. I'm leaning towards my earlier hypothesis that the 3D Rotation functions are looking to replace values in X and Y rotation parameters that don't exist or buggy pointers.

You know I think that part of this puzzle lies in this description. There being no X or Y rotation values to be replaced in a point object's format could be the underlying problem here.

Thanks, I'm still 😕 Adjusting for the missing zero Set3DRot(BeamHandle,0,45,0,0,0,0); I pasted in your text exactly. I tried it in a tool, a point, a linear and a palette script. All four produced a steel column at 0,0,0 rising perpendicular to x/y plane along the z-axis, not rotated 45° from vertical as was anticipated. Note that it does rotate about the z-axis, which is the location where I placed the missing zero value, in bold. So this responds Set3DRot(BeamHandle,0,0,45,0,0,0); but changing the value for the x or the y axis is doing nothing. I just don't get it. I don't really want to do my own beam oriented extrusions and lose the ability to pull data off their Wide Flange object. Oh well.

thanks Julian, that is definitely a DOH! Homer moment for me. I've tried this in both a tool and linear object testing the bracketed lines one by one, VW2019 BeamHandle:=CreateCustomObjectN('Wide Flange - 3D',0,0,0,FALSE); SetRField(BeamHandle,'Wide Flange - 3D','__series_2', 'AISC (Metric)'); SetRField(BeamHandle,'Wide Flange - 3D','__size_2', 'W200 x 22.3'); SetRField(BeamHandle,'Wide Flange - 3D','Length', '3000mm'); SetRField(BeamHandle,'Wide Flange - 3D','__current_series', '2'); SetRField(BeamHandle,'Wide Flange - 3D','__current_size_2', 'W200 x 22.3'); {Rotate3D(0,45,0);} {HRotate(BeamHandle,0,45,0);} {Set3DRot(BeamHandle,0,45,0,0,0,0);} {SetRot3D(BeamHandle,0,45,0,0,0,0);} {Locus(0,0); SetSelect(LNewObj); SetSelect(BeamHandle); SetView(-90,0,0,0,0,0); DoMenuTextByName('Rotate Right 90',0);}

Does anyone understand why it has to be so difficult to work the 3D steel shapes in VW? They all start as point objects extruded along the positive z-axis. I've tried to rotate the Wide Flange - 3D with all three rotation procedures Set3DRot ; SetRot3D ; Rotate3D (edit: and HRotate) and all I can accomplish is rotation about the z-axis. I went so far as to attempt to ungroup to see if I could rotate the extrude but neither ungrouping procedure HUngroup nor Ungroup works with this object. They both deselected the Wide Flange beam regardless of selecting Yes in the latter.

It sounds like your angle precision is set less than your orthographic grid's precision. Your precision for ortho would be minimum of one decimal place more than the smallest dimension you measure to maintain accuracy. Then your angle accuracy needs to be better than that and that accuracy is also relative to the distance from the rotation point to which you expect accuracy. If you are rotating your environment to angles other than whole degrees and you do this at 5 metres from the origin but expect accuracy to 0.1mm at 100 metres you have lost 5%(or maybe it's 20%) of your accuracy by doing the rotation at only 5M, unless your are entering the rotation value from the keyboard.

Correct me if I'm wrong, I don't use the referenced method very often, but aren't all the classes of the referenced file available to be turned off and on in the final document as subclasses of the referenced file name and or via the class setings of viewports? In which case they can be turned off and on via the class settings of a viewport instance. Create a duplicate of the viewport and alter the class visibility(s).

Yeah, I've not given up quite yet. While it would be great to use the SDK, first I would have to learn the terminology and idiom used to describe and operate in that environment. It was one thing many years ago to learn APL, Pascal, Basic+ and tackle a bit of PL1 and C+ but it is quite another I found out to find (and afford) appropriate compilers and environments, then install them in the manner that they work together to generate a properly formatted executable. In one instance I had purchased a copy of Metrowerk's CodeWarrior to learn more C++ after work only to have the product discontinued before fully understanding its environment. I never got to writing a single line of useful project code. Anyways, I was thinking that I might see what the limitations are of the static parameter as a storage medium. There is also possibly a means to create a worksheet and store info in it outside of the PIO, or maybe create symbol definitions and store each node's the control point location and object data as a line of text in a text object. It seems possible to retrieve any of these options and write out the data to a temporary external text file and then read/parse it back into a structured dynamic array. From there I can initialize a control point parameter for the first node in my beam and sequentially rotate thru the other nodes one by one with just the one control point parameter. Saving both the control point location and the node's object data back to which ever means is found to be most suitable. Now that I'm thinking of it, if a PIO can create a Symbol Definition instance it wouldn't be that difficult to attach a record and define the fields required then plunk the data in. It would be quite useful to have both the editable plugin instances laid out for display and linked symbols that can be assembled into a 3d model to check alignments of the connections and have the visual model. A lot of ifs. Conceptually I think it's possible with only Vectorscript. Time to begin a few tests! Maybe I'll be able to rework my beam layout tool into something useful.

VW2013 had a language guide that included defining structured variables and the compiler conscripts like $INCLUDE, $IF, etc. Looking for the location of the Windows version. It used to be a pdf in a VWhelp folder. on the Mac it was an app that was a cross between a web browser and an ebook. I guess I could dig up the 2013 version; not much is likely to have changed if anything.

Is there a means to store control point locations in the PIO's record in say a structured variable? The point of the question is to limit the visible control points to the currently valid locations. Locations where an object like a symbol has been linked in and is being tracked. Similar to a polyline vertex arrangement, but in my case end points and one of the possible multiple points between. The quantity of between points is variable, because having potentially 30+ control point parameters when typically only 16+/-8 will be required/used seems like a really bad plan. Larry

Looks interesting Pat, and admittedly much clearer organization than mine, hehehe. You allowed the user the ability to move the washer and nut but I couldn't find if there was a limiter in there to ensure the minimum two threads above the nut. Myself I have (for now) foregone entering the whole table matching thread count to bolt diameter and simply approximate the amount that must extend above the nut. I'm about 3mm over on 1" size and almost true at 1/4" size. Some day I may become inspired and work some more on this but for now I happy that today I have filled in all the size gaps up to 1" in 1/8" increments. I wasn't aware of the full size range when I began this wedge anchor until after I had hard coded the use of the first three characters to represent the diameter. Our shop doesn't use 5/16" and the engineer's in the area use epoxied rod more often than not for 1" and over. The other aspect with imperial stuff is that many times the sizes are nominal, which is possibly the case for the lengths associated with the 1" diameter material in this product. So this is just a close visual representation of one manufacturer's product. Perhaps when I get to creating a threaded rod with nut and washer options for both ends I will include a subroutine to accurately determine the two thread offset. In light of all the hatches and snippets of code that I have borrowed from various places over the past 25 years, attached is an updated working tool, sans icon. Past icon attempts have all failed miserably. Wedgie Anchor.vso

Thanks Guys, With your insight I have found the issue. Raymond, you were almost right. I'm not sure exactly how NNA does this but the first parameter chooses which list of values to display when the user activates the pull down (that part is easy) (example: regular hex nut = make visible and display the values in size_1, heavy hex nut = make visible and display the values in __size_2 and so on) but they then seem to somehow transfer that directly to the 'size' parameter. Their plugin only responds to values entered into the 'size' parameter. My bad it turns out is that I am replacing the "size" parameter with a decimal equivalent of the fractional value. ie: '0.625' instead of '5/8'. The latter seems to be what their script expects but somehow that didn't kill the script. It chimed instead and then possibly converted it to a real again internally and finished its task. The "__NNA_DO_NOT_CHANGE" I believe is NNA's way of saying to the various distributors to not localize the name into the regional language. I made a number of attempts to use those other parameters early on by hard coding in different values like '3/4' etc but their plugin script does not seem to check upon the value stored in those various parameters that hold the value lists, even after issuing a ResetObject(). It looks like I'm going to have to create a clumsy case statement to match up decimal values to fractional representation to shut the thing up. This is what makes all of this fun, isn't that right!? 😂 PS: Then again maybe not, I already have those in the initial selection process

Thanks, but no change and nothing popped up in a message window.