If a script opens another file, runs a template on it, then switches back to the original file, function calls that use types of the original file’s template no longer work - even though the values of that template are still available.
I’m attaching a set of files to reproduce this. You can use it as follows:
Extract the files somewhere and adjust the folderPath variable in script.1sc.
Open mainfile.bin and run the script on it. Notice that, while the first call to ProcessMainFile() succeeds, the second call fails with the error “The given type does not exist.”
Comment out the two RunTemplate() calls.
Run the script again and notice that this time, it succeeds.
The ‘Run Template on File’ drop down currently shows files in the order they were loaded and you are right that this can be confusing. The ‘Run Template on File’ list actually shows all open files across multiple tab groups, so we could display it as each tab group in order, or we could just displayed everything in alphabetical order. Maybe alphabetical would make more sense when there are multiple tab groups.
The ability to run a script on another script or template, or run a template on another script or template is rare, but it is still useful to have in certain cases. Maybe we’ll add an option for this? We’ll have to think about it more. Cheers!
Open mainfile.bin, apply the template mainfile.bt, and run the script mainfile.1sc. 010 will crash right after the first iteration.
This is presumably related to the behavior of FileClose() as described in the documentation:
Closes the current file. No file will be active after this function is called and use the FileSelect function to activate another file.
Indeed, adding a FileSelect() after the FileClose() fixes the problem. Still, crashing is a bit much, especially since the script reads mainFile.numSubFiles through a reference parameter and thus should be independent of the selected file.
This version of the script loops over the subfiles without crashing, but while the Printf() call logs two lines to the Output window, the FPrintf() call only logs one line to the dump file. Presumably its writing position jumps back to the start each time we open a file in another tab.