Has anyone tested to see if the newish model add-ins work in a shapescript ?
I have, and they do. It's not a practice I would recommend though.
For one thing it's probably pretty easy to crash EA this way -- mutual recursion and whatnot. Not to mention that the power of having stuff in-model is also a weakness: the model can be modified after deployment.
But more importantly, the whole Model Add-In feature feels very much like a dead end to me. I think it's more likely than not that a version or two down the line it will be quietly deprecated, EA style. Which means leaving it incomplete with a couple of glaring showstopper bugs in there, and when users complain tell them some other feature is now the
flavour of the month preferred solution, while leaving the documentation in place, making it look like the feature is main stream and fully supported. (For reference, see Required/disabled Technologies.)
If they do then calling a model addin that prepares your string should perform ok - given its just string manipulation, not looking up loads of data etc.
I think not. EA launches a separate process (sscripter.exe) for a Model Add-In (one for each or one for all, haven't tested -- for that matter, is it even possible to run more than one Model Add-In at a time?). I don't see how you can get anything remotely approaching acceptable performance this way.
By contrast, a DLL Add-In's code executes within the EA process, and even then, more than a dozen instances of a shape script Add-In call in one diagram is unusable.
So I'd say yes on the Add-In option to solve this problem, but no to the Model Add-In as an alternative. If the thing has to work in the wild, anyway. For a concept demo, I guess it could be OK.
Shapescript could be SO MUCH MORE!
Yes indeed. Why not make it an extension of (a subset of) SVG, with a couple of macros to access the model data?
/Uffe