ScriptInclude vs ScriptStart vs Sub Procedure vs etc, etc

[Simon_Aldworth]

Hi,

Could I ask for some help on determining when is best to use each of the various ways of arranging code into separate repeatedly used chunks?

My problem is partly due to not fully understanding this help page: https://zone.ni.com/reference/en-XX/help/370858P-01/comoff/scriptinclude/ or the equivalent one for ScriptStart. The comparison table at the bottom doesn't provide much clarity for me.

Essentially, I use a collection of scripts for analysing data from different tests. Whilst there's a lot of re-used code, I prefer to keep the code for each test separate from all the others. However, within each test there is still repeated code so it makes sense to put this into a suitable format for repeated use.

Part of my struggle is to understand the scope of variables in relation to ScriptInclude and ScriptStart. For example, one of my pieces of processing code needs to repeatedly call another chunk of code, which to date has been stored in a separate script. This separate script will produce results stored in variables that are needed later in the calling script. At the moment, these variables are declared at the top of the separate script.

Because of that last point, I thought that it was correct to use ScriptInclude so that the main script would 'see' the results variables. However, when I call the separate script for the second time using ScriptInclude nothing happens - the script doesn't run. Noting that the above help page says you should call ScriptInclude only once (why?), I changed my code to use ScriptStart for all subsequent calls after the first one. Following this, the main script fails after the second call of the separate script because a further script called later on doesn't 'see' the variables produced, presumably because I'm calling that later script with ScriptStart. However, I can't call that later script with ScriptInclude because it's been called once before.

What about sub procedures? Should I consider using them instead? This would make a neat single script with all the code in one place but it would be very long and harder to navigate.

So, I'd be grateful for a lay mans guide to understanding the principal benefits to ScriptInclude and ScriptStart (lay terms are important!), and some guidance on where I should be declaring the variables I use.

Many thanks, Simon.

[Brad_Turpin · Accepted solution]

Hi Simon,

If inside VBScript_1 you call the ScriptStart() command with the file path of VBScript_2 in the argument, then VBScript_2 file will run in a NEW VBScript host, after which that new VBScript host will exit memory and the rest of VBScript_1 will continue to execute line by line in the original VBScript host that it started in.

If at the top of your VBScript_1 you call the ScriptStart() command with the file path of VBScript_2 in the argument, then all of VBScript_2 will execute at that moment as if it were inside VBScript_1.  This means that any executable code will run right away, but also that any variable assignments will be known to VBScript_1 and any Sub or Function or Class declarations will be known to VBScript_1.  Thereafter in VBScript_1, any time you call one of the Sub or Function or Class declarations in VBScript_2, it will execute as if those declarations are in VBScript_1.  At all times only one VBScript host is used in this scenario, which is why the variables and parameters can be passed back and forth between content in VBScript_1 and VBScript_2.

It sounds like you want to use ScriptStart() once at the top of your VBScript_1.  Then you just need to call its Subs and Functions as if they were declared in VBScript_1.  My recommendation would be to have ONLY Subs/Functions/Class declarations in VBScript_2.  Think of it like a VBScript library that you can include into any VBScript_1.  This way when you call ScriptStart(), no commands will execute that "do" anything, because all the code in VBScript_2 is wrapped inside a Sub or Function or Class waiting to be invoked explicitly by name later on in VBScript_1.  If you find this gives you trouble, please post the code in question so we can advise you.

Brad Turpin

Principal Technical Support Engineer

NI

[Simon_Aldworth]

Hi Brad,

Many thanks for your reply. Having made a quick review of your post, I wonder if I could ask you to make a quick check of it? I'm wondering if there are times when you intended to write ScriptInclude but wrote ScriptStart instead?

If I interpret it correctly, then it turns out I did as you suggest: I put all my secondary pieces of code that are contained in separate scripts inside sub procedures.

I'll have a more thorough look at your post and my scripts soon and if I have any other questions then I'll get back to you.

Thanks again,

Simon.

[Brad_Turpin · Accepted solution]

Hi Simon,

You are correct and I was frustratingly careless.  Unfortunately, I can no longer edit the contents of that post.  The first paragraph was about ScriptStart() and the remaining paragraphs were about ScriptInclude().  Grrr.

Brad Turpin

Principal Technical Support Engineer

NI

[Simon_Aldworth]

Hi Brad,

No matter. Shame you can't change it but them's the rules.

Thanks for helping me out.

Regards.