Scripting: issue and suggestion
Hi. I am using scripting extensively these days. One can do great things with scripting. Here I spot an issue and give a suggestion for improvements:
– model.matrices returns a list of matrix views located at the root level in the model browser; matrices nested inside folders are not returned.
– Scripting manager and editor: the editor gives no feedback about coding errors, unlike the scripting console; when there is a syntax error, the action is disabled or the function set is not available. It’s tedious doing development and test in the console then copying and pasting into the editor. It would be nice having the same error message at the bottom of the editor which you have in the console. I suggest also adding a “Run action” button next to the “Hotkey” button, in order to speed up action execution during testing.
Regards
Thanks, Ben, for your informative answer. From an end user’s point of view, I cannot grasp the relevance of the “sandboxing” choice. In traditional spreadsheets, scripting allows one to do many things which are useful for automating computing tasks as well as preliminary procedures (copying and importing text files, move or copy content among open worksheets, etc. ). Quantrix scripting is more powerful and robust in many aspects, and is improving constantly. However, sometimes I feel that the constraints imposed by sandboxing are a limiting factor for the completeness and consistency of the scripting environment.
Maybe I am understating possible interferences with the correct functioning of Quantrix. Anyway, I am confident that collecting a wide range of use cases may help clarifying what would be the best match.
Kind regards,
Hi Luca,
The issue with model.matrices sounds like a bug. I will see about getting that fixed.
I also agree that the error reporting for actions and functions is a bit lacking and I will raise the issue of how to improve it. With respect to running scripted actions while editing, you may not be aware that you can use Ctrl+Enter (or Cmd+Enter) to run a scripted action from its editor window, the same way as you do in the console. Perhaps this could stand to be more clearly documented, but meanwhile I think it should resolve the issue of convenient testing of actions.
Lastly, the “quantrix” property. The property was deliberately removed, and I will do my best to explain why:
All the methods available on “quantrix” pertain to managing multiple models: creating them, opening them, closing them, choosing the one that is currently active from among those that are open, etc. This functionality was included in the original plan for scripting because we thought it would be convenient, without giving much consideration to the broader implications. However, we later felt that the number of problems it introduced outweighed the value it offered.
First off, the intended purpose of scripting is as a lightweight tool to automate things within a particular model. The ability to manipulate multiple files is potentially too broad even though it may seem useful in certain circumstances. More importantly, however, there are functional problems posed by this feature. The most significant one is that creating and opening models can result in errors because scripts run within a sandbox environment with reduced privileges, and the necessary filesystem access may not be permitted. It is difficult to remedy this issue without reducing the security of the scripting environment.
We want to be attentive to the needs of our customers, and if there were great demand for a reinstatement of the “quantrix” property, we might consider it. However, we would prefer to first investigate the problems that are prompting such requests and consider alternative solutions.
Regards,
Ben