Hi Martin, so actually it's not that alert at all, I looked into it some more and it looks like your script is running into a "timeout" mechanism in the script interpreter, due to the continuously spinning while loop here:

	while (!moi.ui.commandUI.GetStart()) {		
	}

A loop like that is going to continuously burn CPU time and at some point the script interpreter notices that it's just churning CPU in a loop and bails on the script.

I should be able to disable that timeout mechanism, but in the meantime you should instead use an event loop for that kind of a thing, if you wait for a UI event that will pause the script until an event is actually generated, the method that you're doing now does not do an actual wait, it's called "polling" where it's just actively checking over and over and over again.

To do the event based method, replace that while loop with this:

	var dlg = moi.ui.commandDialog;

	while ( 1 ) {
	
		dlg.waitForEvent();
		
		if ( dlg.event == 'startbutton' )
			break;
	}

You can also remove the GetStart() script at the top of makethread.htm and also remove the onbuttonclick="" handler on the start button, it's enough for the start button to just have an id value, any control inside of the command UI area will generate a UI event with that id when pressed.


Note that there is still a loop, but that's only because it's possible for other events to be generated too like when other controls are clicked, you want to loop until you get the right event but by calling waitForEvent() on a "waitable object" (if you don't have a pointpicker or object picker then the "command dialog" object can work, it's a waitable object that represents the command UI panel) you won't be burning CPU, the script will actually suspend at that point until a UI event is generated, then it wakes up.


Also if you give your start button an id="done" , you can then #include "WaitForDialogDone.js" in your script and then use WaitForDialogDone(); which is a packaged up function that does that exact same kind of loop in it, it just looks for a UI event named "done" instead of "startbutton".


I've never seen this script interruption mechanism kick in before, so that was kind of mysterious but it was good to find out about it since there may be other situations where you're doing a whole lot of number crunching processing where you would need the script to crunch away in a tight loop for some time, so it's definitely something that I need to disable in the script engine.


- Michael