Scripts "forget" template types after calling RunTemplate() on another file

General
1

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.

Script bug repro.zip (1.0 KB)

2

Thanks for the bug report. We have replicated this and we are working on a solution. We should have a fix ready for the next version. Cheers!

Graeme
SweetScape Software

1 Like
3

Good to hear!

Completely unrelated, but here’s another possible improvement. When you reorder file tabs, the tab dropdown adjusts accordingly:
image

However, the “run template on file” dropdown keeps showing the original order, making it ever so slightly harder to find the one you’re looking for:
image

It might also make sense to exclude .bt and .1sc files from this “run” dropdown, both for templates and for scripts.

4

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!

Graeme
SweetScape Software

1 Like
5

Thank you for considering it!

Coming back to the original problem, I found that a slightly different version of the script causes 010 to crash. Here’s a reproduction case:

crash.zip (1.2 KB)

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.

6

And another (seeming) bug:

pointer-reset.zip (1.2 KB)

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.

7

And another I just encountered. Given the following script:

enum TestEnum
{
    TestEnum_Entry1
};

TestEnum value = TestEnum_Entry1;
Printf("From variable: %s\n", EnumToString(value));

TestEnum array[1];
array[0] = TestEnum_Entry1;
Printf("From array: %s\n", EnumToString(array[0]));

The first call works, but the second fails with “Function ‘EnumToString’ did not receive a valid enum that could be converted to a string.”

8

Thanks for the bug reports. We are working on all these issues and should have them fixed for our next release. Cheers!

Graeme
SweetScape Software

1 Like