Custom script section can provide new functionality, but they share the same dependency and limitations of the the script section from which they are called to execute. This means the script section that executes the custom script section is a script section that is or can be executed for each instrument in the portfolio without the need for the LoadSymbol function, then the custom script section will share that access. If the calling script section only executes once each for each test.currentDay, that script section will be required to use the LoadSymbol function to have access to an instrument.
To get a broader understanding of how the script section calling the custom section will condition the custom script section, please read the details on the Instrument topic page were each of the standard script sections are listed as having native instrument access, or are script section that only execute once for each test.currentDate and need special access to instruments.
Custom script section variables share access to the calling script section. This means that variables with the same name in the script section that calls the custom script section will have an impact on the values in the custom script section, and also in the calling script section after the custom script section has completed its execution of its scripts.
This means that it is possible to contaminate or share data between the two script sections. This is also true when a script section calls another custom script section. There can either be contamination or sharing of data that may or many not be intended.
To prevent unintended contamination of variables, use variable names in a script section that are not going to be used within any other script. One simple way is to use a prefix or suffix in the custom script that is added to any of the variable names so as the variable name will be unique to the custom that specific custom script name.
In a custom script section named "Field_Count", all the variable names have a suffix attached to their name using the two primary characters in the custom function name:
' Determine the Size of the String
It is unlikely that a string_length variable would be created in a standard script section to make it unique because variables can be limited in their data scope reach by how the variables are declared. Custom script sections by default are limited in data scope reach by how they are declared. However, that scoping reach includes the script section that calls the custom script because the process of how it is executed once called. In simple terms, when a custom script is called it is not any different from how the same code would work had the scripting in the custom script section been typed into the script section that executed the custom script.
Why then do we need custom script sections?
Custom script sections allow us to write code that can do a task that we don't have as a normal function. By creating it as a custom script section we can write the code once and then use it many times.
Once a custom script has been created it can then be used many times because the custom script section can be placed in an Auxiliary module that is easily attached to a system list. A custom script section can also be Right-Clicked, Copied, and then Pasted into another blox for use in that blox.
How many custom script sections are allowed?
There is no known limit, but there is a restriction when it comes to a custom script section name. Each custom script section in a system must be different from any other custom script section in that system. This is necessary because the Script Object's Execute function will search the entire system list looking for the name used by the Execute function. If you have more than one a custom script with the same name and it isn't exactly the same code, then the results you will get might not be what you wanted because the search process looks and then uses the first custom script section it finds with the name given to the Execute function.
Edit Time: 2/25/2018 10:55:38 AM
Topic ID#: 642