Variable scope with .wsf scripts

[Programmer1974]

Hello all!

If I have the following script:

<job id="Main">
<script language="VBScript">

OPTION EXPLICIT

Dim intTest

intTest = 1

MsgBox intTest

</script>
<script language="VBScript">

OPTION EXPLICIT

MsgBox intTest

</script>
</Job>

Is there a way to limit the scope of intTest so that the second set of code does not find the declaration in the first set, and therefore displays an error? I ask because if I include multiple scripts in a .wsf script using...

<script language="VBScript" src="C:\Test.vbs" />
<script language="VBScript" src="C:\Test2.vbs" />
<script language="VBScript" src="C:\Test3.vbs" />

...I do not want to worry about my variables conflicting with each other. I've tried declaring variables as private, but that has no effect. Thanks for your input!

 

[SeniorGuru]

If the include scripts have code encapsulated in procedures or functions then variable scope shouldn't be an issue.

In your example, the </script><script language="VBScript"> in the middle effectively isn't there. When you run the script you get two message boxes which is what you would expect to see.

Essentially what you want to do is:

<job id="Main">
<script language="VBScript">

OPTION EXPLICIT

SUB ThisThing
    Dim intTest

    intTest = 1
    MsgBox intTest
End Sub

MsgBox intTest

</script>
</Job>

 

[Programmer1974]

Thank you for the response SeniorGuru! However, what I want to do in my first example is actually cause the error. So, if C:\Test.vbs, C:\Test2.vbs, and C:\Test3.vbs all use a global variable that is the same name, then I want to make sure that they do not conflict. I understand that if I just make sure my variables are initialized correctly in each script I shouldn't have a problem. But another problem here is if I have a subroutine in more than one script that is named the same.

So, is there a way to isolate each included script?

Thanks for the responses!

 

[dilettante]

This should make it clearer: <job> Element.

Since variables are "declared" by executing statements such as [tt]Dim[/tt] (or those that stumble over using them when [tt]Option Explicit[/tt] is omitted) this gives you your answer:

Each script within a set of job tags is executed in sequence, from top to bottom.

It becomes clear then that you either want to encapsulate code in subroutines if all are to be executed without namespace collisions, or in separate <job>s if they are to be executed separately. The scoping rules are pretty straightforward for both data and procedures alike.

You can have a multi-job WSF and run multiple jobs though.