DO11: How to init ScriptConfig.<property> as an array?

[steje]

I'm doing something wrong I'm sure... In a JScript that adds a new command, I've tried a few things to init a ScriptConfig property as an array:

initData.config.objOptions = ['A','B','C','D'];

...and

initData.config.objOptions = new Array(); initData.config.objOptions[0] = ""; initData.config.objOptions[1] = ""; initData.config.objOptions[2] = ""; initData.config.objOptions[3] = "";
...but all I ever see in the Configure dialog for the scripts' listing in Prefs is just a single line objOptions item to which I can assign a single value as if I had just declared it as a string. I'm not exactly sure how I expected to see the 'multi-line editor' behavior for the case you mentioned where the array is all strings, but I definitely didn't expect what I'm seeing.

What am I doing wrong and what should I expect to see in the Customize editor for script configuration options like this when 'properly' used as an array?

As an aside: I assume you implemented support for this property to be used as an array so that scripts could loop through a set of user configurable options rather than be restricted to only being able to examine individual properties explicitly by name.

If so, and depending on if I've misunderstood how to use this or not... is there any method by which you could allow the use of a VT_ARRAY type ScriptConfig. such that the Config editor for the script in Prefs would allow users to ADD additional values to the array for elements not explicitly initialized in OnInit? I could certainly pre-fill several placeholder elements as empty strings or something, and just skip past them in a loop if their length === 0. But having a more free-form ability would be pretty useful as well, and be ready for changing needs without having to edit the actual script code. The main use-case for such a feature would be to allow for future readiness of an unknown number of options (unknown at the time of writing the script that is) that would just be unwieldy to pass as arguments (if used in the implementation of a new Script Command)... Thoughts on this?

[Leo]

If so, and depending on if I've misunderstood how to use this or not... is there any method by which you could allow the use of a VT_ARRAY type ScriptConfig. such that the Config editor for the script in Prefs would allow users to ADD additional values to the array for elements not explicitly initialized in OnInit? I could certainly pre-fill several placeholder elements as empty strings or something, and just skip past them in a loop if their length === 0. But having a more free-form ability would be pretty useful as well, and be ready for changing needs without having to edit the actual script code. The main use-case for such a feature would be to allow for future readiness of an unknown number of options (unknown at the time of writing the script that is) that would just be unwieldy to pass as arguments (if used in the implementation of a new Script Command)... Thoughts on this?

I don't understand this part. It sounds like you want the script to allow the user to specify extra parameters which neither the current version of the script, nor the user at the time, knows the meaning of, but might be used by a future version of the script? But I think I must have misunderstood as that doesn't make sense. Maybe an example of how it would be used would clarify?

[steje]

If I had a better idea of how the first part is ~supposed to work, and whether how I ~thought it would work was correct or not, maybe I might have asked in a way that made more sense. I probably should have just waited to ask this second part since I still don't see how an array is supposed to work as one of these ScriptConfig properties.

Anywho, my expectation of using a ScriptConfig property as an array:

initData.config.objOptions = ['A','B','C','D'];

...was that we could have then reference the values of the array elements in any script functions in a loop:

for (i = 0; i < Script.config.objOptions.length; i++) { var ret = -1; if ((ret = strInput.search(Script.config.objOptions[i])) >= 0) { <do stuff>; } }
I might very well pre-populate some elements of the array with values that most users would probably be ok with, but otherwise want users to be able to add their own values for purposes that would depend on what the script needs to do with certain options.

As a real world example, take how folks have asked about TitleCase over the years... Now, never-minding how those threads often wound up as an entertaining debates over which chars, words, and such comprise different folks ideas of what the formal TitleCase standard is; at the end of the day, sometimes people have slightly different wants from one another. What I'm asking about would give users with no real scripting skills an interface where they can add their own values to modify which words and char combinations that could then modify how an adapted TitleCase script would behave.

I'm NOT looking at adapting TitleCase ... I just figured it would be a good example of how different users might have different needs that the script would be able to handle specifically withOUT needing to be rewritten in the future. To my comment before about pre-poulating elements of an options array; in a TitleCase example maybe that means I pre-fill all of the ~standard chars and words, etc... But for the folks who insist on capitalizing certain prepositions or whatever, they could add them into the Script Configuration dialog and then get their desired behavior. Without having to have it done for them directly in the script, or have explained to them how they'd potentially need to:

• extract an OSP file to get to the script(s)
• update what would have to be a global var Array so that it could be available to all functions in the srcipt
• know to increment the array index for each new element they want to define

All simple things for you or I, but for users who have custom needs but NO desire to dabble in scripting... having the ability to make such customizations in a UI would be a great boon. And I am indeed thinking of this more for use in scripts developed for 'other' users on the forums; whereas anything I wrote for myself I'd probably just open the script and make my changes directly in the code...

Is that clear - or do you want an actual example or pseudo-code?

[steje]

Bah... sorry for sidetracking here. Would definitely love to continue discussion on this angle. But to reset the thread, can one of you provide a correct example of how we would use this property as an array? The Scripting Reference says that when one of the properties is used as an array:

[quote="The Scripting reference"]a) all strings, in which case the config editor will show a multi-line editor,
b) one integer followed by strings, in which case the config editor will show a drop-down list[/quote]
...so I expected that if I properly initialized it full of strings or chars (which I guess my code is NOT doing properly) I might see a single item for objOptions in the Configuration editor, but with multiple lines of values (maybe each element value on a separate line in the multi-line editor). But not sure...

[Leo]

It's all brand new to me as well so I can't answer that yet. The docs are being written and will explain things in detail.

[steje]

Fair enough, I can appreciate that...

In the interim, consider the sample test script attached to this post... and the results from running the command it adds to Opus (Test_JScript) from a button:

ScriptCommand_test_jscript.zip (1.74 KB)

The log messages show that during OnInit, I'm able to get a valid type for the initData.config.objScriptVT_ARRAY property after assigning values to it as an array.

...but then once I reference them after initialization, the type for the property has been lost. Even then, maybe I'm doing something wrong in how I'm referencing the property, but I'm not sure what else to try.

[steje]

Once again, I get that some things are still being sorted out and what-not... I'm posting here as I learn more to illustrate what I now believe is an actual issue, and not just a result of me mis-using JScript syntax or object reference conventions.

I think there's actually in your JScript scripting host implementation with respect to how this property is implemented/imported when used as an array, whereas it actually works BETTER than fine in VBscript. Based on some issues I was googling about when first running into this problem, I wonder if you're doing some kind of typeof operation on the ScriptConfig properties when you import them since you allow the single property to be used as multiple types... but anyway:

I've whittled down my test scripts a little bit and dispensed with the global variable stuff I was playing with for control testing. Please consider the following test results:

JScript example:
ScriptCommand_test_jscript.zip (1.18 KB)

...as before, in JScript - you can see that between OnInit and referencing the property in the ~main script function - the data type has been lost. I added checks into the test scripts to avoid the 'Script.config.objScriptVT_ARRAY.length' is null or not an object (0x800a138f) error that gets thrown if I try to loop through the values that should be in the array.

Now compare that to the results of an equivalent test VBscript:
ScriptCommand_test_vbscript.zip (1.21 KB)

...lo and behold, the data type is preserved between OnInit and being referenced in the scripts ~main function.

But what's even cooler (in my mind) is that when working properly in VB, it's also actually ALREADY working exactly how I had requested earlier... such that users can add their own strings to the array (not just modify array elements defined in the script). The array was even declared static, with an initial size of only 5 elements... so I guess on import you're probably copying the array values into a global dynamic array to make available to all script functions (THANKS for thinking of that) and I wonder if something in your checks before doing so are what is going wrong in JScript?

[Leo]

Yeah, JScript has some issues with arrays which we weren't aware of until recently. We'll be addressing them in future betas.

[steje]

Ok, thanks for acking - thought I was just totally missing something obvious for a minute.

Stoked that the way it already works in VB is how I had hoped it could work with users being able to add new elements to the options array. Hope that ability remains when you guys fix up the JScript interface.

[Jon]

So it turns out that JScript arrays do not work correctly, at least in the way we need them to. So in the next beta we will be introducing our own "array" object (called Vector) that you can use interchangeably with arrays in Opus scripting calls. Native arrays will still work in VBScript but from JScript you'll need to switch to using Vectors for this.

[steje]

Cool, thanks for accommodating... I figured it had something to do with JScript not allowing pass bt reference and some screwball data type loss that seems to happen when passing sh!t around... The alternative is much appreciated. Can you say if we'll be able to use similar "array" like object methods with your Vectors though? The object specific methods supported by JScript was one of the major things that attracted me to JScript over VBscript....... but in any case, thanks for the accommodation! Really stoked about the scripting enhancements in v1!!!

[Jon]

Our Vector is basically a wrapper around std::vector and has most of its functionality.