Hi Brian, *.htm files for commands in MoI are the same as HTML files that are displayed in web browsers, the upper-right area of MoI's main window basically has an embedded web browser there that loads the HTML content. You can also have script in that HTML content same as you can in HTML files that are displayed in a regular web browser. There are a few different ways that scripts can be declared on a web page, it's possible to have an event handler declared in something like an onclick="" attribute on a button but if you have some pretty big functions it's more typical to have those functions declared in a <script> block that you put in the <head> portion of the HTML page.
The command script (the .js file part of a command) can call script functions that are in the HTML page, the root object of the HTML page is available under moi.ui.commandUI , and any script functions declared on that page end up as global variables there, so if you have a function in HTML called blah() like this:
code:
<html>
<head>
<script>
function blah()
{
.....
}
</script>
</head>
.......
That function defined in the HTML file can be called from the .js file by: moi.ui.commandUI.blah();
I've attached an example where I've edited your Clothoid2ptDraft2b command to move a bunch of the script construction logic over into the HTML file which is then called in this manner from the .js file.
The script code that is declared inside of the HTML file will have fairly different performance characteristics than the code that's run in the .js file - that's because the HTML page runs directly inside of the main MoI.exe process, while a regular command's script file runs in a separate process: moi_commandprocessor.exe and it talks to MoI.exe whenever you make calls into any MoI object. The main reason for this inter-process communication is to make it harder for scripts to be able to crash or lock up MoI, with the script being in a different process it's a lot easier for MoI to forcibly terminate that script at any time without anything happening to the main moi.exe process.
Script code that you run directly inside of the main MoI process will have less overhead to each MoI object call that's done in it, but it will also be easier for the script to lock things up if it goes into a tight loop or things like that as well.
In the future I'd like to make a type of "script factory" mechanism that would make it possible to write some script that would run in a separate worker process but have in-process calls for geometry access and vector math type functions so that the script would not have as much overhead.
The way regular MoI commands are set up though the scripts are mostly used for control flow logic and not for doing heavy duty calculations directly in a script - heavy calculations happen in the geometry factories that are currently written in C++ and they have that kind of direct geometry access even though they run in a separate worker because any geometry that's being used by the factory is sent over to the worker process so that it can then access it locally as it does calculations on it.
So anyway basically right now things are not really optimized for the case of doing heavy calculations directly in script, but you may get some lower overhead for scripts that are contained inside of the HTML part of the command which is normally where the UI controls go. You can have script code in there as well though if you want by using <script> tags. Hope this explains a bit more of how things are currently set up to work.
- Michael
