storing x/y/z values into PIO's record

[LarryO]

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

[klinzey]

In VS you must have a parameter for every control point. You do have the ability to show and hide the control points in the document and on the OIP as needed.

You can do what you are asking using the SDK but not in VS or Python.

[MullinRJ]

Larry,

   Only a few days ago I was faced with the same problem and I wrote these lines to show/hide the control points in the OIP. It goes in event 41 (kObjOnWidgetPrep). The +1 is necessary because vsoParamName2Index() returns a 0-based index, but vsoWidgetSetVisible() is 1-based. Welcome to VectorScript.

            { Show/Hide ControlPoint parameters in OIP }
            WidgetID := vsoParamName2Index(PIOName, 'ControlPoint01X');    { the first CP name }
            for I := WidgetID+1 to WidgetID+16 do 
                vsoWidgetSetVisible(I, pshow_Ctrl_Pt_values);                        { hide ControlPoints 1-8 }
 

   Also, "show_Ctrl_Pt_values" is a Boolean PIO parameter (a checkbox) that I use to toggle the visibility.

 

HTH,

Raymond

[Miguel Barrera]

Before we had the ability to compare old values with new values, I stored the old values as a CHAR DYNARRAY. In some cases, where the values were points, I separated x,y,z with commas and separated each point with a semicolon.

[LarryO]

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.