twk 232 Posted October 6, 2016 Greetings, Anyone know the maximum size of characters a Parameter/Record field can hold? Needing a place to store a series of xyz co-ordinates from a user-defined polygon. And thinking to store it in a static text parameter of my pio. There's no way to foreknow the number of vertices as its userdefined. But the location of each vertex is crucial to my calc. Thanks Quote Share this post Link to post
JBenghiat 333 Posted October 7, 2016 There is no limit on the size a text field BUT you must retrieve the value with GetRField instead of the PParameter constant . -Josh 1 Quote Share this post Link to post
twk 232 Posted October 7, 2016 No limit! very interesting, shall trial it out when at pc. Thanks Josh Quote Share this post Link to post
Dieter @ DWorks 24 Posted October 9, 2016 There should be no limit, but there still is though.... Don't know if it's because of the calls, or the actual data storage, but I have had the limit with a plugin I made this summer... It's still 256 Quote Share this post Link to post
JBenghiat 333 Posted October 9, 2016 You are limited to what displays in object info and what you can set in the plug-in's defaults, as well as what you can access via the PParameter constant, but SetRField and GetRField allow unlimited storage. If in VS, any variables you use must be DYNARRAY OF CHAR and constants are still limited to 256 characters, so varName := 'Something longer than...256 characters'; will throw an error. For example, place a callout object on the drawing, and select it. Run the following script: PROCEDURE MyScript; VAR fieldVal :DYNARRAY OF CHAR; i :INTEGER; BEGIN fieldVal := ''; FOR i:=1 TO 300 DO BEGIN fieldVal := Concat( fieldVal ,i, Chr( 13 ) ); END; SetRField( FSActLayer, 'Callout', 'Text', fieldVal ); ResetObject( FSActLayer ); END; Run(MyScript); You will see the callout displays a string far greater than 256 characters. Next run the following: PROCEDURE MyScript; VAR fieldVal :DYNARRAY OF CHAR; BEGIN fieldVal := GetRField( FSActLayer, 'Callout', 'Text' ); AlrtDialog( Concat( Len( fieldVal) ) ); END; Run(MyScript); You can see that fieldVal retrieves a string of 1092 characters. -Josh 1 Quote Share this post Link to post
Dieter @ DWorks 24 Posted October 10, 2016 @JBenghiat, I use SetRField for the plugin instance parameter, and if I put anything greater than 256, it's get truncated. (I use Python). So I guess the unlimited storage only counts for normal records.... 1 Quote Share this post Link to post
Hippocode 22 Posted October 10, 2016 I did not test the size limit but have you considered user data instead ? 1 Quote Share this post Link to post
twk 232 Posted October 10, 2016 Thanks for the input guys, so far so good, following Josh's advice. 1. Have set up a plugin parameter as static text: __xypts; and generated xyz coordinates from the pio and stored it in this static text parameter. 2. Setup a the pio to draw a text object containing data from this hidden static text parameter, and all the data is getting read out beautifully. can't really go into what the pio does at the moment, but as you can see from the screen shot, all coordinate data is getting displayed from the hidden parameter. Characters I assume are well over 256. This is using the vs.GetRField call and not the P<parmaname> method. Quote Share this post Link to post
Hippocode 22 Posted October 10, 2016 If you ever run into limits you might look at User Data, but I believe it's SDK only. Still you could write a VS function to handle your implementation. Basically you can attach (structures of) data to any object handle which is very cool. I have a junction object that can have unlimited legs, each leg info is dynamically added to the object handle without using a record. If all you are saving are coordinates you might also consider dynamic controlpoints and or the combination with above. This also opens the option of simply moving any of those points if the control handle is visible end enabled. Quote Share this post Link to post
Dieter @ DWorks 24 Posted October 10, 2016 3 hours ago, twk said: This is using the vs.GetRField call and not the P<parmaname> method. Aha, so that could be the real problem! So P.... is cutting it off, and thus it's better to use GetRField for text fields... Hmmm. Need to test this and then add it as improvement to DLibrary! Quote Share this post Link to post